Re: [ANNOUNCE] klibc 0.1 release

[Felix von Leitner <felix-dietlibc@fefe.de>]

Thus spake Greg KH (greg@kroah.com):
> As many people have recently realized, it looks like we need to have
> some kind of klibc library for the initramfs programs due to problems
> with the existing libc implementations (if people disagree with this,
> please feel free to speak up.)

> With this in mind, I took the work that I did to merge dietLibc into the
> dietHotplug build process, and created a first snapshot of a klibc
> project.  I have successfully used it to build a version of dietHotplug,
> but that's probably about all that will build against the library at
> this time :)

I wonder if it is wise to fork the project.
The diet libc does not yet work for all platforms; work is underway but
as yet incomplete on S/390, and no sh-linux and no ia64-linux at all.

I understand that's OK for diet hotplug, so it's OK to take just enough
code to make your project work.  The important question probably is
whether diet hotplug will be part of the kernel distribution or not.
If not, I don't think it makes much sense to not just reference the diet
libc.  Maybe we can put the diet libc distribution on ftp.kernel.org to
show the affinity better (and make it more widely mirrored).

But forking means you will have to watch our CVS and port stuff from
here to there every now and then.

Compared to the kernel sources, the diet libc tarball is two orders of
magnitude smaller, so I am not sure I understand the need to make it
even smaller.

Felix