klibc 0.1 release

Hi all,

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 :)

It can be found at:
http://www.kernel.org/pub/linux/kernel/people/gregkh/klibc/klibc-0.1.tar.gz

I'll be working on getting the project hosted on some public CVS site soon.

Yes, I know this first cut is _very_ ugly, but it's someplace to start with, and it works for me :)

Here's the README:
-----------------------
This is the start of the klibc project.

Initially it is based on dietLibc <http://www.fefe.de/dietlibc/> but will probably grow to look quite different from that package.

Goals:
To provide a small libc that can be used to build userspace binaries that will run in the initramfs portion of the kernel boot process.

Only library calls that are _needed_ will be added to klibc. Right now only the calls needed to build and run dietHotplug are present. Any functions that are must have a real need (i.e. some program needs them.) We aren't going for POSIX compliance here.

Right now a static library, klibc.a will be built. If a dynamic library is found to be needed that functionality will be added.

For this first release, I quickly hacked up what I had done for the dietHotplug project. It probably does not build on other architectures, and is probably missing some functions that you want/need. Please let me know any problems that you find, and patches are gladly accepted.
----------------------

thanks,

greg k-h

Thus spake Greg KH ([email protected]):

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

More importantly, the dietlibc compilation units are tiny, so even linking against dietlibc itself is probably not much different in outcome than a spinoff.

Matthias Andree

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."         Benjamin Franklin