klibc - Jun 2006 - [klibc 00/43] klibc as a historyless patchset

As some people have requested, here is klibc as a historyless patchset
against 2.6.17.  The patchset consists of two parts: changes to the
main kernel code taken straight from the git history (as it is rather
few patches), and additions, grouped by rough divisions.

The majority of the patches are independent in the sense that they
should apply independently, but Makefile/Kbuild files may have to be
adjusted to build a partially patched tree.

This is also available as a git tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-klibc-clean.git

The full history klibc git tree is available at:
git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-klibc.git

The files from the patchset are also available at:
http://www.kernel.org/pub/linux/kernel/people/hpa/klibc-patchset/

This patchset corresponds to version 1.4.6 of the standalone klibc
distribution.

The following represent changes to the main kernel code:

01-add-klibckinit-to-maintainers-file.patch
02-remove-root-mounting-code-from-the-kernel-.patch
03-remove-parts-moved-to-kinit.patch
04-support-klibcarch-being-different-from-the-main-arch.patch
05-need-to-export-ranlib-from-the-top-makefile.patch
06-re-create-root-dev-too-many-architectures-need-it-.patch
07-eliminate-unnecessary-whitespace-delta-vs-linus-tree.patch
08-klibc-default-initramfs-content-stored-in-usrinitramfs-default.patch
09-kbuild-support-single-targets-for-klibc-and-klibc-programs.patch
10-remove-prototype-for-name-to-dev-t.patch
11-enable-klibc-errlist.patch
12-enable-config-klibc-zlib-now-required-to-build-kinit.patch
13-uml-the-klibc-architecture-is-the-underlying-architecture.patch
14-remove-in-kernel-nfsroot-code.patch
15-default-klibcarch--arch.patch
16-sparc64-transmit-arch-specific-options-to-kinit-via-arch-cmd.patch
17-sparc32-transfer-arch-specific-options-to-arch-cmd.patch
18-klibc-inkernel-merge-s390s390x-4.patch

The following represent klibc itself:

19-klibc-basic-build-infrastructure.patch
20-core-klibc-code.patch
21-alpha-support-for-klibc.patch
22-arm-support-for-klibc.patch
23-cris-support-for-klibc.patch
24-i386-support-for-klibc.patch
25-ia64-support-for-klibc.patch
26-m32r-support-for-klibc.patch
27-m68k-support-for-klibc.patch
28-mips-support-for-klibc.patch
29-mips64-support-for-klibc.patch
30-parisc-support-for-klibc.patch
31-ppc-support-for-klibc.patch
32-ppc64-support-for-klibc.patch
33-s390-support-for-klibc.patch
34-sh-support-for-klibc.patch
35-sparc-support-for-klibc.patch
36-sparc64-support-for-klibc.patch
37-x86-64-support-for-klibc.patch
38-simple-test-suite-for-klibc.patch
39-zlib-for-klibc.patch

This is kinit, which actually replaces the in-kernel root-mounting
code:

40-kinit-replacement-for-in-kernel-do-mount-ipconfig-nfsroot.patch

The following are optional utilites, for the convenience of people who
want to create their own custom initramfs, as well as for testing:

41-miscellaneous-utilities-for-klibc.patch
42-dash---a-small-posix-shell-for-klibc.patch
43-a-port-of-gzip-to-klibc.patch

Hi,

On Sun, 25 Jun 2006, H. Peter Anvin wrote:
> The majority of the patches are independent in the sense that they
> should apply independently, but Makefile/Kbuild files may have to be
> adjusted to build a partially patched tree.
I could now repeat all the concerns I already mentioned, why it shouldn't 
be merged as is (that doesn't mean it shouldn't be merged at all!), but 
they have been pretty much ignored anyway...

What I'm more interested in is basically answering the question and where 
I hope to provoke a bit broader discussion: "What's next?"

Until recently for most developers klibc was not much more than a cool 
idea, but now we have the first incarnation and now we have to do a 
reality check of how it solves our problems. To say it drastically the 
current patch set as it is does not solve a single real problem yet, it 
only moves them from the kernel to kinit, which may be the first step but 
where to?

So what problems are we going to solve now and how? The amount of 
discussion so far is not exactly encouraging. If nobody cares, then there 
don't seem to be any real problems, so why should it be merged at all? Are 
shiny new features more important than functionality?

So anyone who likes to see klibc merged, because it will solve some kind 
of problem for him, please speak up now. Without this information it's 
hard to judge whether we're going to solve the right problems.

Peter, it would really help if you describe your own plans, how you want 
to go forward with it, otherwise it leaves a huge amount of uncertainty 
and since this is a rather big change, I think it's a real good idea to 
reduce this uncertainty, so we know what to expect and everyone can better 
evaluate how these changes will effect him. Right now these patches are 
devoid of any documentation, which make it hard for everyone to judge them 
(and what is IMO the main reason for the current uncomfortable silence).

Feel free to flame me now for making it so difficult, but I'm convinced 
it's better for everyone to make this step (even if it's the right one) 
with more information than we have right now...

bye, Roman