From: Greg KH <greg@kroah.com>
To: linux-kernel@vger.kernel.org, felix-dietlibc@fefe.de,
andersen@codepoet.org
Subject: [RFC] klibc requirements
Date: Tue, 8 Jan 2002 11:24:50 -0800 [thread overview]
Message-ID: <20020108192450.GA14734@kroah.com> (raw)
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
next reply other threads:[~2002-01-08 19:27 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-08 19:24 Greg KH [this message]
2002-01-08 20:37 ` [RFC] klibc requirements Erik Andersen
2002-01-09 4:23 ` Felix von Leitner
2002-01-09 4:34 ` initramfs programs (was [RFC] klibc requirements) Greg KH
2002-01-09 6:10 ` Greg KH
2002-01-09 7:23 ` H. Peter Anvin
2002-01-09 9:33 ` Kai Germaschewski
2002-01-09 10:00 ` Erik Andersen
2002-01-09 4:51 ` [RFC] klibc requirements Greg KH
2002-01-09 5:01 ` H. Peter Anvin
2002-01-09 6:09 ` Greg KH
2002-01-09 7:26 ` H. Peter Anvin
2002-01-10 6:30 ` Rusty Russell
2002-01-10 18:41 ` H. Peter Anvin
2002-01-10 15:24 ` Matthias Kilian
2002-01-10 17:13 ` H. Peter Anvin
2002-01-09 14:15 ` Felix von Leitner
2002-01-09 14:30 ` Lars Brinkhoff
2002-01-09 14:51 ` Erik Andersen
2002-01-09 10:38 ` initramfs programs (was [RFC] klibc requirements) Anton Altaparmakov
2002-01-09 15:56 ` Pavel Machek
2002-01-09 16:04 ` Patrick Mochel
2002-01-09 16:26 ` Greg KH
2002-01-09 16:29 ` Pavel Machek
2002-01-09 16:48 ` Andreas Ferber
2002-01-09 21:15 ` Alex Bligh - linux-kernel
2002-01-09 21:34 ` Anton Altaparmakov
2002-01-09 21:40 ` Greg KH
2002-01-09 21:55 ` Anton Altaparmakov
2002-01-09 22:15 ` Andreas Ferber
2002-01-10 0:25 ` Tom Rini
2002-01-10 0:38 ` Andreas Ferber
2002-01-10 2:42 ` Tom Rini
2002-01-10 14:09 ` Rob Landley
2002-01-10 22:24 ` Tom Rini
2002-01-11 0:15 ` H. Peter Anvin
2002-01-09 22:12 ` Alex Bligh - linux-kernel
2002-01-09 13:23 ` [RFC] klibc requirements Juan Quintela
2002-01-09 14:57 ` Erik Andersen
2002-01-15 3:08 ` Albert D. Cahalan
2002-01-15 11:55 ` Felix von Leitner
2002-01-15 14:54 ` David Lang
2002-01-15 16:15 ` Doug McNaught
2002-01-15 18:06 ` David Lang
2002-01-15 18:36 ` Doug McNaught
2002-01-16 18:36 ` Erik Andersen
2002-01-16 7:50 ` Albert D. Cahalan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020108192450.GA14734@kroah.com \
--to=greg@kroah.com \
--cc=andersen@codepoet.org \
--cc=felix-dietlibc@fefe.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox