[lkml]   [2002]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] klibc requirements, round 2
On Thu, Jan 10, 2002 at 05:50:52PM -0800, Torrey Hoffman wrote:
> Tom Rini wrote:
> > On Thu, Jan 10, 2002 at 03:18:49PM -0800, Greg KH wrote:
> ...
> > > - image viewer
> > > - mkreiserfs
> >
> > I think these are examples of misunderstanding what initramfs _can do_
> > with what we (might) need a klibc to do.
> ...
> > These programs _might_ compile with a klibc, but I wouldn't
> > worry about
> > it. uClibc is what should be used for many of these custom
> > applications
> Well, as the person who first mentioned mkreiserfs and the like,
> I agree with you. For the majority of systems out there which
> aren't using initrd now, a minimal klibc for an unmodified
> initramfs makes sense.


> My concern is with the minority who are using initrd, and in
> some cases a very customized initrd.

Right. And moving that very customized initrd over to an initramfs
should be painless, once the kinks/bugs are worked out of the yet-to-be
created programs that exist in the kernel now.

> The important thing, I think, is that it should be easy for
> less-than-guru level hackers to add programs to the initramfs,
> even if the program they want can't be linked with klibc.
> This really comes down to: What will the build process be for
> these initramfs images?

It's a cpio archive, occording to the draft spec hpa posted.

> By the way, is initramfs intended to supercede initrd, or will
> they co-exist?

I _think_ co-exist.

Tom Rini (TR1265)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:15    [W:0.048 / U:9.944 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site