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]):
> 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
On Tue, 08 Jan 2002, Felix von Leitner wrote:
> 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.
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