lkml.org 
[lkml]   [2002]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subject[RFC] klibc requirements
Hi all,

First off, I do not want to fork off yet another tiny libc
implementation, unless it is determined that we really need to do it. I
posted the klibc implementation because I have found that in the past,
people can talk all they want, but the only way to actually get people
all riled up and start paying attention is to post code :)

Now that people are riled up, and want to talk about it, let's try to
describe the problem and see if any of the existing libc implementations
help solve them. Here's what I see as a list of requirements for a
klibc like library that can be used by initramfs programs (please,
everyone else jump in here with their requirements too):
- portable, runs on all platforms that the kernel currently
works on, but doesn't have to run on any non-Linux based OS.
- tiny. If we link statically it should be _small_. Both
dietLibc and uClibc are good examples of the size goal. We do
not need to support all of POSIX here, only what we really
need.
- If we end up having a lot of different programs in initramfs,
a dynamic version of the library should be available. This
shared library should be _small_ and only contain the symbols
that are needed by the programs to run. This should be able
to be determined at build time.
- It has to "not suck" :) This is a lovely relative feeling
about the quality of the code base, ease at building the
library, ease at understanding the code, and responsiveness of
the developers of the library.

I don't think either dietHotplug or uClibc or glibc or any other
existing libc implementation meets these goals right now, right?

I had asked the dietLibc authors about the ability of tweaking their
library into something that resembles the above, but didn't get a
response. Hence my post. I would love to work with the authors of an
existing libc to build such a library, as I have other things I would
rather work on than a libc :)

Comments from the various libc authors? Comments from other kernel
developers about requirements and goals they would like to see from such
a libc?

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:15    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site