[klibc 00/43] klibc as a historyless patchset

[klibc 00/43] klibc as a historyless patchset

[H. Peter Anvin]

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

klibc and what's the next step?

[Roman Zippel]

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

Re: klibc and what's the next step?

[Jeff Garzik]

Roman Zippel wrote:
> 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?

Well, at least for me...  at boot time we run into various limitations 
from the current kernel approach of coding purely userspace activities 
in the kernel, simply because a vehicle for implementing early-boot 
userland operations did not exist.

This klibc patchkit removes stuff that does not need to be in the 
kernel, and provides a platform for improving IP autoconfig, NFS root, 
MD/DM root setup, and various other early-boot activities.

A lot of the larger distros have been moving in this direction anyway, 
by necessity.  They have been stuffing more and more [needed] logic into 
initrd [which is often really initramfs these days], to deal with 
complex boot and root-mounting scenarios like iSCSI and multi-path.

	Jeff

Re: [klibc] klibc and what's the next step?

[Greg KH]

On Tue, Jun 27, 2006 at 09:39:30AM -0400, Jeff Garzik wrote:
> Roman Zippel wrote:
> > 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?
> 
> Well, at least for me...  at boot time we run into various limitations 
> from the current kernel approach of coding purely userspace activities 
> in the kernel, simply because a vehicle for implementing early-boot 
> userland operations did not exist.
> 
> This klibc patchkit removes stuff that does not need to be in the 
> kernel, and provides a platform for improving IP autoconfig, NFS root, 
> MD/DM root setup, and various other early-boot activities.
> 
> A lot of the larger distros have been moving in this direction anyway, 
> by necessity.  They have been stuffing more and more [needed] logic into 
> initrd [which is often really initramfs these days], to deal with 
> complex boot and root-mounting scenarios like iSCSI and multi-path.

I second this statement, having a method of implementing early boot
userspace options is a very good thing to have, and one that the distros
really want (as they have already been doing it on their own in
different ways, some using klibc already, others using uclibc, and still
others using glibc.)  Standardizing on a method to implement this is
very much needed.

thanks,

greg k-h

Re: [klibc] klibc and what's the next step?

[Roman Zippel]

Hi,

On Tue, 27 Jun 2006, Greg KH wrote:

> On Tue, Jun 27, 2006 at 09:39:30AM -0400, Jeff Garzik wrote:
> > Roman Zippel wrote:
> > > 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?
> > 
> > Well, at least for me...  at boot time we run into various limitations 
> > from the current kernel approach of coding purely userspace activities 
> > in the kernel, simply because a vehicle for implementing early-boot 
> > userland operations did not exist.
> > 
> > This klibc patchkit removes stuff that does not need to be in the 
> > kernel, and provides a platform for improving IP autoconfig, NFS root, 
> > MD/DM root setup, and various other early-boot activities.
> > 
> > A lot of the larger distros have been moving in this direction anyway, 
> > by necessity.  They have been stuffing more and more [needed] logic into 
> > initrd [which is often really initramfs these days], to deal with 
> > complex boot and root-mounting scenarios like iSCSI and multi-path.
> 
> I second this statement, having a method of implementing early boot
> userspace options is a very good thing to have, and one that the distros
> really want (as they have already been doing it on their own in
> different ways, some using klibc already, others using uclibc, and still
> others using glibc.)  Standardizing on a method to implement this is
> very much needed.

I guess this describes pretty much describes the goal and I don't think 
anyone really disagrees.
The question is now how do we get there? The current klibc patches give no 
answer to that, there is no documentation or any prototype, which would 
give a good idea how to get this stuff into initramfs in a manageable way.
The current responses indicate that the primary (or at least initial) 
users would be distributions, but there is no hint how the current klibc 
stuff can be used by them, which IMO is a serious problem.
The problem here is that we are about to create a new kernel-userspace 
interface and considering our track record here, I think it's a really bad 
idea to go into this practically blind. How will distributions put their 
stuff into initramfs?

bye, Roman

Re: klibc and what's the next step?

[Andi Kleen]

Jeff Garzik <jeff@garzik.org> writes:
> 
> MD/DM root setup,

That would require pulling the tools for that into the kernel source right?
Not sure that's a good idea. Do you really want /usr/src/linux/liblvm ? 

-Andi

Re: klibc and what's the next step?

[H. Peter Anvin]

Andi Kleen wrote:
> Jeff Garzik <jeff@garzik.org> writes:
>> MD/DM root setup,
> 
> That would require pulling the tools for that into the kernel source right?
> Not sure that's a good idea. Do you really want /usr/src/linux/liblvm ? 
> 

Only enough to bring up the filesystem.  This is, of course, already the 
case for MD.  That code has (mostly) not yet been moved to userspace, 
but that is definitely on the road map going forward.

	-hpa

Re: klibc and what's the next step?

[Andi Kleen]

On Tuesday 27 June 2006 19:11, H. Peter Anvin wrote:
> Andi Kleen wrote:
> > Jeff Garzik <jeff@garzik.org> writes:
> >> MD/DM root setup,
> > 
> > That would require pulling the tools for that into the kernel source right?
> > Not sure that's a good idea. Do you really want /usr/src/linux/liblvm ? 
> > 
> 
> Only enough to bring up the filesystem.  This is, of course, already the 
> case for MD.  That code has (mostly) not yet been moved to userspace, 
> but that is definitely on the road map going forward.

But not for LVM where this can be fairly complex.

And next would be probably iSCSI. Maybe it's better to leave some stuff
in initramfs. 

-Andi

Re: klibc and what's the next step?

[H. Peter Anvin]

Andi Kleen wrote:
> 
> But not for LVM where this can be fairly complex.
> 
> And next would be probably iSCSI. Maybe it's better to leave some stuff
> in initramfs. 
> 

Of course, and even if it's built into the kernel tree it doesn't have 
to be monolithic (one binary.)  Current kinit is monolithic (although 
there are chunks available as standalone binaries, and I have gotten 
requests to break out more), but that's mostly because I've been 
concerned about bloating the overall size of the kernel image for 
embedded people.

	-hpa

Re: klibc and what's the next step?

[Joshua Hudson]

I currently use it as a replacement for initrd that uses approx 1/2
the RAM (maybe less when I get around to changing CONFIG_MINIX_FS to
module).

I couldn't care less about kinit right now as I run dash there, but it
could be useful if root= support is removed.

BTW, is there a kinit= kernel command line so I can spawn an
interactive shell rather than /init?  init= doesn't do it.

Re: klibc and what's the next step?

[H. Peter Anvin]

Followup to:  <bda6d13a0606271322x6f2d76f4wfdbc885062d9a145@mail.gmail.com>
By author:    "Joshua Hudson" <joshudson@gmail.com>
In newsgroup: linux.dev.kernel
> 
> BTW, is there a kinit= kernel command line so I can spawn an
> interactive shell rather than /init?  init= doesn't do it.
> 

Yes, it's called rdinit=.

	-hpa

Re: klibc and what's the next step?

[Roman Zippel]

Hi,

On Tue, 27 Jun 2006, H. Peter Anvin wrote:

> > But not for LVM where this can be fairly complex.
> > 
> > And next would be probably iSCSI. Maybe it's better to leave some stuff
> > in initramfs. 
> 
> Of course, and even if it's built into the kernel tree it doesn't have to be
> monolithic (one binary.)  Current kinit is monolithic (although there are
> chunks available as standalone binaries, and I have gotten requests to break
> out more), but that's mostly because I've been concerned about bloating the
> overall size of the kernel image for embedded people.

If you are concerned about this simply keep the whole thing optional. 
Embedded application usually know their boot device and they don't need no 
fancy initramfs.

bye, Roman

Re: klibc and what's the next step?

[Rob Landley]

On Wednesday 28 June 2006 8:04 pm, Roman Zippel wrote:
> If you are concerned about this simply keep the whole thing optional.
> Embedded application usually know their boot device and they don't need no
> fancy initramfs.

Actually, a lot of embedded applications like initramfs because it saves 
memory (a ram block device, a filesystem driver, and filesystem overhead.)  
Don't use embedded applications as a reason _not_ to do this!

BusyBox has had explicit support for initramfs (switch_root) for several 
versions now.  I pestered HPA about building a subset of BusyBox against 
klibc (and cross-compiling klibc for non-x86 platforms) at the Consumer 
Electronics Linux Forum, but haven't had time to follow up yet.

Rob
-- 
Never bet against the cheap plastic solution.

Re: [klibc] klibc and what's the next step?

[maximilian attems]

On Mon, Jul 03, 2006 at 02:30:45PM -0400, Rob Landley wrote:
> On Wednesday 28 June 2006 8:04 pm, Roman Zippel wrote:
> > If you are concerned about this simply keep the whole thing optional.
> > Embedded application usually know their boot device and they don't need no
> > fancy initramfs.
> 
> Actually, a lot of embedded applications like initramfs because it saves 
> memory (a ram block device, a filesystem driver, and filesystem overhead.)  
> Don't use embedded applications as a reason _not_ to do this!
> 
> BusyBox has had explicit support for initramfs (switch_root) for several 
> versions now.  I pestered HPA about building a subset of BusyBox against 
> klibc (and cross-compiling klibc for non-x86 platforms) at the Consumer 
> Electronics Linux Forum, but haven't had time to follow up yet.
> 
> Rob

well but busybox is big nowadays and generally compiled against glibc.
i'm quite eager to kick busybox out of default Debian initramfs-tools
to have an klibc only default initramfs. those tools are needed atm,
and there is not enough yet. afaik suse adds sed on klibc with a minimal
patch and we'd liked to have stat, kill and readlink on klibc-utils.

how about busybox on klibc?

--
maks

Re: [klibc] klibc and what's the next step?

[Jeff Bailey]

[-- Attachment #1: Type: text/plain, Size: 957 bytes --]

Le lundi 03 juillet 2006 à 20:46 +0200, maximilian attems a écrit :
> well but busybox is big nowadays and generally compiled against glibc.
> i'm quite eager to kick busybox out of default Debian initramfs-tools
> to have an klibc only default initramfs. those tools are needed atm,
> and there is not enough yet. afaik suse adds sed on klibc with a minimal
> patch and we'd liked to have stat, kill and readlink on klibc-utils.
> 
> how about busybox on klibc?

I made a brief attempt to do busybox on klibc before klcc was working
right for me.  I should try that again.  In Ubuntu, we already do a
separate build pass of busybox to get just the features that we want, it
would be easy to play with this.

I'll let you know.  It'll take me a couple days - between travelling and
the long weekend, I'm a bit behind.

Tks,
Jeff Bailey

-- 
* Canonical Ltd * Ubuntu Service and Support * +1 514 691 7221 *

Linux for Human Beings.

[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [klibc] klibc and what's the next step?

[H. Peter Anvin]

Jeff Bailey wrote:
> Le lundi 03 juillet 2006 à 20:46 +0200, maximilian attems a écrit :
>> well but busybox is big nowadays and generally compiled against glibc.
>> i'm quite eager to kick busybox out of default Debian initramfs-tools
>> to have an klibc only default initramfs. those tools are needed atm,
>> and there is not enough yet. afaik suse adds sed on klibc with a minimal
>> patch and we'd liked to have stat, kill and readlink on klibc-utils.
>>
>> how about busybox on klibc?
> 
> I made a brief attempt to do busybox on klibc before klcc was working
> right for me.  I should try that again.  In Ubuntu, we already do a
> separate build pass of busybox to get just the features that we want, it
> would be easy to play with this.
> 
> I'll let you know.  It'll take me a couple days - between travelling and
> the long weekend, I'm a bit behind.
> 

I think the main things that aren't in klibc are the userid and the 
network databases.  They should be reasonably easy to stub out.

	-hpa

Re: [klibc] klibc and what's the next step?

[Jon Smirl]

On 6/27/06, Jeff Garzik <jeff@garzik.org> wrote:
> Roman Zippel wrote:
> > What I'm more interested in is basically answering the question and where
> > I hope to provoke a bit broader discussion: "What's next?"

POSTing of secondary video cards at boot is a good application for it.
Another is setting an initial mode on undocumented video hardware
where the only documented interface is in user space.

POSTing needs emu86 so that it will work on all platforms, where
should emu86 go?

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [klibc] klibc and what's the next step?

[Jeff Bailey]

Le mardi 27 juin 2006 à 15:12 +0200, Roman Zippel a écrit :

> 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.

For Ubuntu, klibc could exist perfectly fine outside of the kernel -
We're using it already and have been for about a year now.

What merging will help us with is:

1) Making sure that klibc remains able to get the system running.  That
way some subtle mismatch between the kernel and klibc doesn't cause a
boot failure on a less-tested config.

2) Help us stay close to the best-practice for booting.  This is both
for making sure that people don't wind up with an unexpected experience
using Ubuntu, but also so that we can contribute back to the common
core.

3) Work towards removing the bootup pieces from the kernel that aren't
used anymore, reducing duplication, crufty in-kernel pieces, yada, yada,
yada...

I'd like to see klibc become the canonical way of booting the kernel
whether it's merged or not.  We already depend on outside tools to get
the system running (udev, module-init-tools), so adding klibc to this
doesn't seem that harmful.

Tks,
Jeff Bailey

Re: klibc and what's the next step?

[Milton Miller]

[I'm not on the list, apologies for dropping anyone from to:]

On Jun 27, 2006, at 8:11 AM, Roman Zippel wrote:
>
> 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...

I'm guessing these threads?

http://marc.theaimsgroup.com/?l=linux-kernel&m=114946240404001&w=2
http://marc.theaimsgroup.com/?l=linux-kernel&m=114967046318388&w=2


>
> 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?

Let me see if I can summarize:

* There is concern about how much is bloat, where do we draw the line 
for in-kernel

* There is concern about duplicating user space utilities.  We moved 
the kernel broken md assemble instead of getting the current one from 
mdadm, and that should be part of mdadm package.

* There is concern that distros won't want to use this anyways -- They 
need more features and use a bigger library than klibc provides.

* Let me propose one:  Even with kinit in the kernel, users will still 
be broken because they will use there existing external initramfs.  
This means we can't move stuff like opening /dev/console to kinit.

* Some distributions are already using klibc and have been.  They see 
the reason to merge is to have the canonical api with the kernel to 
avoid version mismatch.


Ok, now let me make a radical proposal:

1_  Create the utilities in klibc distribution.

2.  A new Kbuild (Makefile) variable, features-y, declares what initrd 
features are required because they were removed from the kernel but 
configured.

3.  Create a file containing the feature list of the initrd.  Maybe a 
directory of files so we don't get overwrite problems.

4.  Have the build system parse the built-in initramfs, extract the 
feature file(s), and fail if it does not contain the magic strings 
required as defined by the Makefiles.

5.  Require features being removed have the user space tested and 
checked into a release of the kinit distribution before merging the 
removal.

Distros would just create a feature file claiming what their initrd 
loaded initramfs build script will create and point 
CONFIG_INITRAMFS_SOURCE to include that.  The whole initramfs doesn't 
have to be put in the kernel, just the feature files.

Yes, i said kinit distribution.   While it needs to build against 
klibc, it may or may not be part of that package.


> 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.

I guess this would be a statement on maintaining kinit / klibc 
development.

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

The Kconfig variables for klibc have no help.

Was the Kbuild documetation updated to mention $(klibc)= ?

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

milton

Re: klibc and what's the next step?

[Roman Zippel]

Hi,

On Tue, 27 Jun 2006, Milton Miller wrote:

> > 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...
> 
> I'm guessing these threads?
> 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=114946240404001&w=2
> http://marc.theaimsgroup.com/?l=linux-kernel&m=114967046318388&w=2

Yes.

> Let me see if I can summarize:
> 
> * There is concern about how much is bloat, where do we draw the line 
> for in-kernel

That actually wouldn't be my initial concern. Otherwise I'm happy to point 
out kernel bloat, but here it's more important to prototype a mechanism. 
In this case bloat can still be fixed later, as it's rather isolated 
behind a standard API.

> * There is concern about duplicating user space utilities.  We moved 
> the kernel broken md assemble instead of getting the current one from 
> mdadm, and that should be part of mdadm package.

The problem here is twofold. First, duplication means extra maintenance 
overhead, various version of the copies have to be kept in sync. The 
temptation to fix only the kernel version without updating the normal 
version could be quite big, so that users might not realize they have 
broken tools until they e.g. try reconfigure the system.
Second, whatever we deliver with the kernel, might become part of kernel 
API (e.g. config files), which needs to be supported for a long time. 
Compatibility code can accumulate rather quickly.

> * Some distributions are already using klibc and have been.  They see 
> the reason to merge is to have the canonical api with the kernel to 
> avoid version mismatch.

klibc will continue as independent project anyway, so it should not be 
difficult to include from the kernel whatever the distribution provides. 
It would help avoiding possible problems with mixing binaries built from 
different libraries.

bye, Roman

Re: klibc and what's the next step?

[H. Peter Anvin]

Followup to:  <Pine.LNX.4.64.0606290117220.17704@scrub.home>
By author:    Roman Zippel <zippel@linux-m68k.org>
In newsgroup: linux.dev.kernel
> > 
> > * There is concern about how much is bloat, where do we draw the line 
> > for in-kernel
> 
> That actually wouldn't be my initial concern. Otherwise I'm happy to point 
> out kernel bloat, but here it's more important to prototype a mechanism. 
> In this case bloat can still be fixed later, as it's rather isolated 
> behind a standard API.
> 

First of all, I don't think there is any significant amount of bloat
(in the sense of a larger kernel image.)  I'm not saying kinit-based
kernel images are *smaller*, but they shouldn't be significantly
larger.

Additionally, you can trivially exclude it in entirety by overriding
initramfs_source.txt, if you are providing your own initramfs, which a
lot of people do nowadays.

> > * There is concern about duplicating user space utilities.  We moved 
> > the kernel broken md assemble instead of getting the current one from 
> > mdadm, and that should be part of mdadm package.
> 
> The problem here is twofold. First, duplication means extra maintenance 
> overhead, various version of the copies have to be kept in sync. The 
> temptation to fix only the kernel version without updating the normal 
> version could be quite big, so that users might not realize they have 
> broken tools until they e.g. try reconfigure the system.
> Second, whatever we deliver with the kernel, might become part of kernel 
> API (e.g. config files), which needs to be supported for a long time. 
> Compatibility code can accumulate rather quickly.

The code currently in kinit is trying to be as closely compatible with
the mainstream kernel as practical -- a drop-in replacement.  Thus, I
have actively avoided making radical changes, and have in fact jumped
through hoops trying to stay as close to the current model as humanly
possible unless incredibly obsolete (rdev on x86, everyone I've talked
to agrees it's not worth supporting; it would be trivial if it's ever
an issue.)

I definitely agree -- and I'm sure Neil does as well -- that the md
code should be rewritten, but as long as the whole thing is maintained
by me out of tree I want to minimize the delta.

The whole point of this exercise is that it gives us a platform by
which to reduce the maintenance of multiple different code bases.
Kernel programming is completely different than user-space
programming, it's poorly understood, and it is much more difficult.
With klibc, it's trivial to share code with even fairly large
userspace projects (e.g. udev); furthermore it is trivial to create
standalone components (e.g. nfsmount) which can not only be tested
standalone, but actually used by customized userspaces, thus
improving code reuse and reducing overall complexity.

> > * Some distributions are already using klibc and have been.  They see 
> > the reason to merge is to have the canonical api with the kernel to 
> > avoid version mismatch.
> 
> klibc will continue as independent project anyway, so it should not be 
> difficult to include from the kernel whatever the distribution provides. 
> It would help avoiding possible problems with mixing binaries built from 
> different libraries.

As long as klibc/kinit is not merged, the current code will have to be
maintained.  This means maintaining in-kernel ipconfig, nfsroot, and
it pretty much dooms the possibility of getting stuff like md detect
and partition discovery rewritten.

The utility of klibc is thus greatly diminished by not having it in
the mainline kernel tree.  Its performance in -mm so far has shown
that it works just fine.

Incidentally, there is one more reason for klibc which hasn't gotten
much mention, but it provides a prototype userspace for kernel
developers to:

  a) test new features (or at least a significant subset thereof), and
  b) document, in code, a recommended way for the more advanced libcs
     to make new features available to userspace, in the form of
     headers and the like.

	-hpa

Re: klibc and what's the next step?

[Roman Zippel]

Hi,

On Wed, 28 Jun 2006, H. Peter Anvin wrote:

> > > * There is concern about how much is bloat, where do we draw the line 
> > > for in-kernel
> > 
> > That actually wouldn't be my initial concern. Otherwise I'm happy to point 
> > out kernel bloat, but here it's more important to prototype a mechanism. 
> > In this case bloat can still be fixed later, as it's rather isolated 
> > behind a standard API.
> 
> First of all, I don't think there is any significant amount of bloat
> (in the sense of a larger kernel image.)  I'm not saying kinit-based
> kernel images are *smaller*, but they shouldn't be significantly
> larger.

As I said, IMO it's not an immediate issue.

> The code currently in kinit is trying to be as closely compatible with
> the mainstream kernel as practical -- a drop-in replacement.  Thus, I
> have actively avoided making radical changes,

The point is, this also makes it its largest problem - it adds no 
immediate value, you add a lot of infrastructure without a single user. 
There is practically nothing, where one could say "Yes, that looks like a 
good way to go forward."

As it looks like it's distribution which are mostly interested in this. 
Have you talked with any distribution maintainer to find out what they 
need and what they want to put initramfs? What are the exact problems 
which distributions have and how do you want to solve them?
Here it should be not that difficult to prototype any new mechanism and
whether it uses an initrd or initramfs is not important initially. From 
this it would be a lot easier to see what is required from the kernel. 

> I definitely agree -- and I'm sure Neil does as well -- that the md
> code should be rewritten, but as long as the whole thing is maintained
> by me out of tree I want to minimize the delta.

The question should rather be: how can Neil maintain it out of tree?
How do we avoid having to split all utils into a klibc version and the 
normal version?

> The whole point of this exercise is that it gives us a platform by
> which to reduce the maintenance of multiple different code bases.
> Kernel programming is completely different than user-space
> programming, it's poorly understood, and it is much more difficult.
> With klibc, it's trivial to share code with even fairly large
> userspace projects (e.g. udev); furthermore it is trivial to create
> standalone components (e.g. nfsmount) which can not only be tested
> standalone, but actually used by customized userspaces, thus
> improving code reuse and reducing overall complexity.

Nobody really disagrees with this, but _how_ do you want to do this?
Do you just expect that by throwing a lot of source into the kernel all of 
this will solve itself?

> > klibc will continue as independent project anyway, so it should not be 
> > difficult to include from the kernel whatever the distribution provides. 
> > It would help avoiding possible problems with mixing binaries built from 
> > different libraries.
> 
> As long as klibc/kinit is not merged, the current code will have to be
> maintained.  This means maintaining in-kernel ipconfig, nfsroot, and
> it pretty much dooms the possibility of getting stuff like md detect
> and partition discovery rewritten.

What has klibc to do with kinit? This rather suggest both are interrelated 
projects, why should one be dependent on the other?

> The utility of klibc is thus greatly diminished by not having it in
> the mainline kernel tree.  Its performance in -mm so far has shown
> that it works just fine.

That just says, it doesn't create new problems, but it still doesn't say 
anything about how you want to solve any of the existing problems without 
creating a whole bunch of new problems.

> Incidentally, there is one more reason for klibc which hasn't gotten
> much mention, but it provides a prototype userspace for kernel
> developers to:
> 
>   a) test new features (or at least a significant subset thereof), and
>   b) document, in code, a recommended way for the more advanced libcs
>      to make new features available to userspace, in the form of
>      headers and the like.

Why has this to be distributed with the kernel? It sounds like it can be 
nicely maintained independently.

bye, Roman

Re: klibc and what's the next step?

[Gerd Hoffmann]

  Hi,

> As it looks like it's distribution which are mostly interested in this. 
> Have you talked with any distribution maintainer to find out what they 
> need and what they want to put initramfs? What are the exact problems 
> which distributions have and how do you want to solve them?

Well, we already have an initramfs, and it can do quite some stuff the
current kernel doesn't do.  Here is a (probably incomplete) list:

  * load kernel modules needed to access and mount the root filesystem
    (block device driver, filesystem module, device mapper, ...)
  * raid/lvm2/evms setup.
  * iscsi setup.
  * fsck root filesystem before mounting it.
  * setup /dev in tmpfs (using udev).

> How do we avoid having to split all utils into a klibc version and the 
> normal version?

That is a big question.  Latest suse doesn't use klibc any more.  Older
versions had a bunch of static klibc-based binaries for some utilities,
i.e. insmod, udev, sh.  Sometimes you needed glibc because one of the
tools needed in initramfs had no klibc-version (rootfs-on-lvm case for
example).  After adding the "fsck rootfs" feature (I think) we had glibc
on the initramfs in almost all cases.  So if you end up with glibc in
initramfs anyway, what is the point of having klibc?

One advantage of merging klibc as-is is that it becomes much more
visible and receives more testing.  And it is probably easier to make
utility maintainers support building with klibc then (instead of forking
a klibc version of every utility).  That still leaves some maintaining
questions though, because we likely end up with some utilities coming
bundled with the kernel (sh, nfsmount, kinit, ...) and some not (lvm2, ...).

just my 2 cent,

  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>
http://www.suse.de/~kraxel/julika-dora.jpeg

Re: klibc and what's the next step?

[H. Peter Anvin]

Gerd Hoffmann wrote:
>   Hi,
> 
>> As it looks like it's distribution which are mostly interested in this. 
>> Have you talked with any distribution maintainer to find out what they 
>> need and what they want to put initramfs? What are the exact problems 
>> which distributions have and how do you want to solve them?
> 
> Well, we already have an initramfs, and it can do quite some stuff the
> current kernel doesn't do.  Here is a (probably incomplete) list:
> 
>   * load kernel modules needed to access and mount the root filesystem
>     (block device driver, filesystem module, device mapper, ...)
>   * raid/lvm2/evms setup.
>   * iscsi setup.
>   * fsck root filesystem before mounting it.
>   * setup /dev in tmpfs (using udev).
> 
>> How do we avoid having to split all utils into a klibc version and the 
>> normal version?
> 
> That is a big question.  Latest suse doesn't use klibc any more.  Older
> versions had a bunch of static klibc-based binaries for some utilities,
> i.e. insmod, udev, sh.  Sometimes you needed glibc because one of the
> tools needed in initramfs had no klibc-version (rootfs-on-lvm case for
> example).  After adding the "fsck rootfs" feature (I think) we had glibc
> on the initramfs in almost all cases.  So if you end up with glibc in
> initramfs anyway, what is the point of having klibc?
> 

For a "big" distribution that runs on modern kernels, then by all means, 
build something around glibc.  The additional disk space and memory is a 
proverbial drop in the bucket.

However, I don't think it's realistic for smaller systems.

> One advantage of merging klibc as-is is that it becomes much more
> visible and receives more testing.  And it is probably easier to make
> utility maintainers support building with klibc then (instead of forking
> a klibc version of every utility).  That still leaves some maintaining
> questions though, because we likely end up with some utilities coming
> bundled with the kernel (sh, nfsmount, kinit, ...) and some not (lvm2, ...).

The stuff that's bundled with the kernel are replacements for kernel 
functionality.  The purpose of bundling is that kernel functionality can 
be removed.  Obviously, utility developers can build with klibc; this is 
already supported by several out-of-tree utilities, including udev. 
Should udev be bundled with the kernel?  It could be debated; however, 
it doesn't really affect the situation at hand.

	-hpa

Re: klibc and what's the next step?

[Michael Tokarev]

H. Peter Anvin wrote:
> Gerd Hoffmann wrote:
>>   Hi,
>>
>>> As it looks like it's distribution which are mostly interested in
>>> this. Have you talked with any distribution maintainer to find out
>>> what they need and what they want to put initramfs? What are the
>>> exact problems which distributions have and how do you want to solve
>>> them?
>>
>> Well, we already have an initramfs, and it can do quite some stuff the
>> current kernel doesn't do.  Here is a (probably incomplete) list:
>>
>>   * load kernel modules needed to access and mount the root filesystem
>>     (block device driver, filesystem module, device mapper, ...)
>>   * raid/lvm2/evms setup.
>>   * iscsi setup.
>>   * fsck root filesystem before mounting it.
>>   * setup /dev in tmpfs (using udev).
>>
>>> How do we avoid having to split all utils into a klibc version and
>>> the normal version?
>>
>> That is a big question.  Latest suse doesn't use klibc any more.  Older
>> versions had a bunch of static klibc-based binaries for some utilities,
>> i.e. insmod, udev, sh.  Sometimes you needed glibc because one of the
>> tools needed in initramfs had no klibc-version (rootfs-on-lvm case for
>> example).  After adding the "fsck rootfs" feature (I think) we had glibc
>> on the initramfs in almost all cases.  So if you end up with glibc in
>> initramfs anyway, what is the point of having klibc?
> 
> For a "big" distribution that runs on modern kernels, then by all means,
> build something around glibc.  The additional disk space and memory is a
> proverbial drop in the bucket.
> 
> However, I don't think it's realistic for smaller systems.

Small systems don't build regular tools with glibc (at least the ones which
are "very small" - something like uclibc or ...) -- so it's logical to use
that same uclibc for initramfs too -- maybe because it's very likely some
other tool will be needed for bootstrapping, or because it's illogical to
have different tools doing the same task, or just because when booting,
a device usually have enouth resources (mostly memory) to run that stuff
from initramfs - eg my d-link g604 router with 16mb ram - uclibc and all
the boot utils will fit perfectly into memory, wich (the memory) will later
be freed and used by real daemons).

I can say about "normal" but old/underpowered PCs - like several i486 boxes
we use here either as X-terms or small routers or whatever.  It's perfectly
ok to use glibc here when booting if the system uses glibc normally, or use
uclibc in initramfs if the system uses uclibc normally, or... whatever.
An initrd with bash(!!), ifconfig, module-init-tools, and some more utils
(yes yes I know about busybox! :), all linked with glibc (and ncurses etc)
is about 4megs in size.  Even with only 8 megs of ram it will boot, and
after mounting real root all that 4 megs will be freed anyway.

So... which smaller systems you're talking about?

Well yes. Ok. Embedded stuff still (like my d-link router).  Currently it's
running 2.4 kernel, and there's no initrd/initramfs there, -- it boots off
a directly-addressible flash memory, jffs.  If there will be no code to
mount root in the kernel, initramfs will be needed, and the smaller it is,
the better (because flas space is also limited, here it's only 4mb).  And
there, maybe very small set of utils linked with klibc or dietlibc will
help (hopefully it all will not be much larger than current in-kernel
code).  But this sort of devices is special (usually requires alot of 3rd
party kernel patches for custom hardware), and the amount of utils needed
is so small.. oh well.  I suspect initramfs will be custom-built in such
cases.

What I'm trying to say, and tried to say several times already, is:
once all that code is removed from kernel space, and initramfs (either
"internal" or "external", ie, built as part of kernel or elsewhere)
becomes mandatory, there's little reason to have all that stuff inside
the kernel sources.  Except one: backward compatibility, so someone who
did not use initramfs explicitly will not use it with new kernel too
(which I personally don't see as a big issue, since almost all major
kernel change requires some new tools/infrastructure anyway).

Ie, most distros are already using initrd/initramfs (and some already
don't use in-kernel code), and the fact that kernel now supplies something
similar does not matter anymore, because "our (distro) initramfs", which
already worked for quite some time, and our users are used to it etc,
already does all what we need (either with glibc or something else).
So there's no need for them to use libc provided inside kernel, it
only makes things worse.

Worse because.  As you mentioned, klibc keeps compatibility cruft
at minimum, ie, some more recent kernel will need different klibc,
which, in turn, will not work on another kernel.  So.. how many
copies of the same utility is to keep?  Or maybe require sources
of every utility used during boot time to be here when compiling
the kernel, to recompile it with the klibc which goes with this
kernel?  And bundle all mdadm, lvm, iscsi etc stuff into kernel
rpm/deb package (without an ability to have custom user-supplied
executables in initramfs) ??

Yes, it'd be nice to have somehow standartized boot process.  But
umm..  that will require half an operating system to go with kernel
(eg, mdadm with its config file, which is /etc/mdadm/mdadm.conf on
Debian and /etc/mdadm.conf on other systems; and I do prefer to have
mdadm instead of mdassemble because it's impossible to do anything
with the latter if something goes wrong).

Kernel provides good (simple and clean) infrastructure for booting.
cpio archive, you just build it, by adding all the tools you think
are needed there, create /init, and voila.  It's enouth.  Yes some
tools are needed to be there, like kinit and parts of it, but even
kinit isn't really necessary, because the other tools providing
the same functionality already exists - there's almost(*) nothing
special in initramfs compared with regular root.

So the whole thing, as I see it, is just for backwards compatibility
for people who do NOT use initrd/initramfs.  And all the discussions
so far made this my opinion stronger...  So now I'm even thinking
about kinit (and parts thereof) as a compatibility layer, not only
klibc as before (if included into kernel source, that is.  I'm not
at all arguing against them being separate projects).

(*) One tiny thing which always bothered me: logging.  I'd love to
have all the boot messages (from initramfs) logged somewhere.  klibc
implements syslog() as writing to kernel log buffer, which partially
solves this.  It'd be better IMHO to have whole console redirected
(or tee'd) into that log buffer instead, up to some explicit knob
is hit, or by using some daemon which grabs the console and is able
to return it all (and terminate) when requested.  It's not only
initramfs issue, but early "regular" boot procedure is also affected
(everything before syslogd is started).  Some distros solves this
prob (eg bootlogd (if memory serves me right) on RedHat), but quite
often in some.. klugy way.  But that's another story.

/mjt

Re: klibc and what's the next step?

[Pavel Machek]

On Tue 2006-06-27 15:12:53, Roman Zippel wrote:
> 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 

I'd like to eventually move swsusp out of kernel, and klibc means I
may be able to do that without affecting users. Being in kinit is good
enough, because I can actually share single source between kinit
version and suspend.sf.net version.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: klibc and what's the next step?

[Michael Tokarev]

Pavel Machek wrote:
[klibc/kinit in kernel]
> I'd like to eventually move swsusp out of kernel, and klibc means I
> may be able to do that without affecting users. Being in kinit is good
> enough, because I can actually share single source between kinit
> version and suspend.sf.net version.

Heh.  Take a look at anyone who's using real initramfs for their boot
process.  Not initrd, not kernel-without-any-preboot-fs, but real
initramfs.  For them, if kinit/klibc will be in kernel, nothing changes,
because their initramfs *replaces* in-kernel code and future supplied-
with-kernel-klibc-based-kinit.  So if you'll move swsusp into kinit,
it WILL break setups for those users!.. ;)

And with time, amount of such users increases.  Because everyone's
switching from initrd to initramfs; or because everyone's starting
using initramfs (not initrd as "obsolete") since their systems now
require some sort of custom stuff while mounting root (like firmware
loading, or device-mapper setup for sata pseudo-raids, or whatever).

Oh well.

/mjt

Re: klibc and what's the next step?

[H. Peter Anvin]

Michael Tokarev wrote:
> Pavel Machek wrote:
> [klibc/kinit in kernel]
>> I'd like to eventually move swsusp out of kernel, and klibc means I
>> may be able to do that without affecting users. Being in kinit is good
>> enough, because I can actually share single source between kinit
>> version and suspend.sf.net version.
> 
> Heh.  Take a look at anyone who's using real initramfs for their boot
> process.  Not initrd, not kernel-without-any-preboot-fs, but real
> initramfs.  For them, if kinit/klibc will be in kernel, nothing changes,
> because their initramfs *replaces* in-kernel code and future supplied-
> with-kernel-klibc-based-kinit.  So if you'll move swsusp into kinit,
> it WILL break setups for those users!.. ;)
> 

There are two ways to deal with this.

Either the kernel can unconditionally invoke /kinit, which then would 
invoke the users /init if present, or the swsusp can be a separate 
initramfs binary which the user's initramfs gets to invoke (the second 
is arguably neater, but requires minor changes to the users initramfs.)

Either way, it's a trivial problem to solve.

	-hpa

Re: [klibc] klibc and what's the next step?

[Jeff Bailey]

[-- Attachment #1: Type: text/plain, Size: 1748 bytes --]

Le vendredi 30 juin 2006 à 16:15 -0700, H. Peter Anvin a écrit :
> Michael Tokarev wrote:
> > Pavel Machek wrote:
> > [klibc/kinit in kernel]
> >> I'd like to eventually move swsusp out of kernel, and klibc means I
> >> may be able to do that without affecting users. Being in kinit is good
> >> enough, because I can actually share single source between kinit
> >> version and suspend.sf.net version.
> > 
> > Heh.  Take a look at anyone who's using real initramfs for their boot
> > process.  Not initrd, not kernel-without-any-preboot-fs, but real
> > initramfs.  For them, if kinit/klibc will be in kernel, nothing changes,
> > because their initramfs *replaces* in-kernel code and future supplied-
> > with-kernel-klibc-based-kinit.  So if you'll move swsusp into kinit,
> > it WILL break setups for those users!.. ;)
> Either the kernel can unconditionally invoke /kinit, which then would 
> invoke the users /init if present, or the swsusp can be a separate 
> initramfs binary which the user's initramfs gets to invoke (the second 
> is arguably neater, but requires minor changes to the users initramfs.)

The Ubuntu initramfs doesn't use kinit, and it would be nice if we
weren't forced to.  We do a number of things in our initramfs (like a
userspace bootsplace) which we need done before most of the things kinit
wants to do take place.

kinit is a nice default tool but longer term, I almost imagine it as a
busybox type of setup.  Either you say "go" and it brings up the system,
or you call it with an argument, change argv[0] or something to get just
the functionality asked for.

Tks,
Jeff Bailey

-- 
* Canonical Ltd * Ubuntu Service and Support * +1 514 691 7221 *

Linux for Human Beings.

[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [klibc] klibc and what's the next step?

[Theodore Tso]

On Sat, Jul 01, 2006 at 06:56:57AM -0400, Jeff Bailey wrote:
> 
> The Ubuntu initramfs doesn't use kinit, and it would be nice if we
> weren't forced to.  We do a number of things in our initramfs (like a
> userspace bootsplace) which we need done before most of the things kinit
> wants to do take place.
> 

This is going to be a problem given that people are hell-bent at
chucking functionality out of the kernel into userspace.  If various
distributions insist on having their own initramfs/initrd, we're going
to have a maintenance headache where future kernel versions won't work
on distro kernels, which is going to be painful for kernel developers
that want to stay on the bleeding edge.  We are already seeing the
beginnings of this, where the the fact that modern kernels expect the
distro initramfs will wait for the SCSI probe to finish after loading
modules and trying to mount the root filesystem has caused RHEL4
system to be incompatible with modern kernels.  

Fortunately there is a workaround by not building the MPT Fusion
device driver as a module, but if Pavel succeeds in ejecting software
suspend into userspace, and preventing suspend2 from getting merged,
*and* distro's insist on doing their own thing with initramfs, we are
going to be headed for a major trainwreck.

Personally, I would be happier with keeping things like suspend2 in
the kernel, since I don't think the hellish compatibility problems
with non-reviewed kernel functionality that has been ejected into
userspace is really worth it --- but if we *are* going to go down the
route pushing everything into userspace, it is going to be critical
that distro's buy into using a kernel initialization system which is
shipped with the kernel, and can be updated without being tied a
particular distro's non-standard "value add".  Maybe that means we
need to have hooks so that the distro's can add their non-standard
"value add" without breaking the ability for users to upgrade to newer
kernels.  But either way, we're going to have to decide which way
we're going to go, and if we're going to go down the blind
in-userspace-good-in-kernel-bad approach, the distro's are going to
have to cooperate or it's going to be a mess.

						- Ted

Re: [klibc] klibc and what's the next step?

[Linus Torvalds]

On Sat, 1 Jul 2006, Theodore Tso wrote:
> 
> This is going to be a problem given that people are hell-bent at
> chucking functionality out of the kernel into userspace.

Btw, I'm not necessarily one of those people.

There _are_ some things that can be better done in user space, but on the 
other hand, other things really are better off in the kernel.

The argument that user space is more debuggable has been shown to be 
largely a red herring. User space is only more debuggable if it does 
something independent, and we've seen that user space is _harder_ to debug 
than kernel space if we have events going back and forth.

For example, the old pcmcia layer in user space was crap, crap, crap, and 
at least I fount it was MUCH harder to debug than the all-in-kernel code.

			Linus

Re: [klibc] klibc and what's the next step?

[Al Viro]

On Sat, Jul 01, 2006 at 01:08:17PM -0700, Linus Torvalds wrote:
> 
> 
> On Sat, 1 Jul 2006, Theodore Tso wrote:
> > 
> > This is going to be a problem given that people are hell-bent at
> > chucking functionality out of the kernel into userspace.
> 
> Btw, I'm not necessarily one of those people.
> 
> There _are_ some things that can be better done in user space, but on the 
> other hand, other things really are better off in the kernel.
> 
> The argument that user space is more debuggable has been shown to be 
> largely a red herring. User space is only more debuggable if it does 
> something independent, and we've seen that user space is _harder_ to debug 
> than kernel space if we have events going back and forth.

True.  However, that depends on the interfaces being used.  Sure, when
a twit "moves things to userland" by marshalling stuff through sysfs,
the only thing it achieves is more sysfs crap *and* more internal kernel
APIs being cast in stone.

However, when the code really is a series of normal syscalls (on the level
of "all we call is sys_something()"), it makes a lot of sense to take the
damn thing to userland and leave it there...

Re: [klibc] klibc and what's the next step?

[H. Peter Anvin]

Linus Torvalds wrote:
> 
> On Sat, 1 Jul 2006, Theodore Tso wrote:
>> This is going to be a problem given that people are hell-bent at
>> chucking functionality out of the kernel into userspace.
> 
> Btw, I'm not necessarily one of those people.
> 
> There _are_ some things that can be better done in user space, but on the 
> other hand, other things really are better off in the kernel.
> 
> The argument that user space is more debuggable has been shown to be 
> largely a red herring. User space is only more debuggable if it does 
> something independent, and we've seen that user space is _harder_ to debug 
> than kernel space if we have events going back and forth.
>

Indeed.  The stuff that have been moved to userspace in the first cut of 
klibc are stuff which can largely be tested independently, usually just 
from the normal command line.  This is incredibly powerful, but it is 
not -- and shouldn't be -- universally applied just because it can; it 
should be applied if and when it makes sense.

> For example, the old pcmcia layer in user space was crap, crap, crap, and 
> at least I fount it was MUCH harder to debug than the all-in-kernel code.

I have my own share of debugging shared kernel space/user space 
applications, mainly autofs, and if done properly, it can be quite sane. 
  If done *improperly*, it's a nightmare.  Personally, I find that if 
one can:

- Run something as a separate component in userspace, and/or
- Can leverage strace(1) to get more insight

then one can usually get a lot of debugging help.  Otherwise, probably not.

	-hpa

Re: [klibc] klibc and what's the next step?

[Theodore Tso]

On Sat, Jul 01, 2006 at 01:08:17PM -0700, Linus Torvalds wrote:
> The argument that user space is more debuggable has been shown to be 
> largely a red herring. User space is only more debuggable if it does 
> something independent, and we've seen that user space is _harder_ to debug 
> than kernel space if we have events going back and forth.

Agreed, 100%.

In addition, userspace is debuggable only only if the initramfs has
enough debugging code in their (like a real live working shell,
strace, basic shell commands etc.)  Otherwise, it becomes even more
hellish to debug.  I wasted a huge amount of time trying to figure out
why the RHEL4 initramfs was incompatible with modern kernels using the
MPT Fusion SCSI driver, because I couldn't make it stop and break out
to a working shell; it had some busybox-like nash thing that wasn't
designed for user interaction, so all I could do was try to make tiny
changes to the initramfs, wait for the !@#@# very long boot cycle, and
watch the initial ramdisk fail to mount the root and crash, and
repeat, for hours on end.  RHEL4's userspace root mount system was
***not*** more debuggable, not in the last.  Adding printk's into a
kernel and recompiling would have been easier, and far less
frustrating.

Hopefully kinit will be better, but it's definitely not the case that
userpsace is easier to debug.  

						- Ted

Re: [klibc] klibc and what's the next step?

[H. Peter Anvin]

Theodore Tso wrote:
> On Sat, Jul 01, 2006 at 01:08:17PM -0700, Linus Torvalds wrote:
>> The argument that user space is more debuggable has been shown to be 
>> largely a red herring. User space is only more debuggable if it does 
>> something independent, and we've seen that user space is _harder_ to debug 
>> than kernel space if we have events going back and forth.
> 
> Agreed, 100%.
> 
> In addition, userspace is debuggable only only if the initramfs has
> enough debugging code in their (like a real live working shell,
> strace, basic shell commands etc.)  Otherwise, it becomes even more
> hellish to debug.  I wasted a huge amount of time trying to figure out
> why the RHEL4 initramfs was incompatible with modern kernels using the
> MPT Fusion SCSI driver, because I couldn't make it stop and break out
> to a working shell; it had some busybox-like nash thing that wasn't
> designed for user interaction, so all I could do was try to make tiny
> changes to the initramfs, wait for the !@#@# very long boot cycle, and
> watch the initial ramdisk fail to mount the root and crash, and
> repeat, for hours on end.  RHEL4's userspace root mount system was
> ***not*** more debuggable, not in the last.  Adding printk's into a
> kernel and recompiling would have been easier, and far less
> frustrating.
> 
> Hopefully kinit will be better, but it's definitely not the case that
> userpsace is easier to debug.  
> 

It isn't automatically easier, but it *can* be.

In your case above, with kinit, I would have added dash and strace (the 
latter would probably have to be statically linked against glibc; I 
haven't actually tried building strace under klibc myself) -- or even 
gdb -- to initramfs, and have /init drop into a shell.  From there one 
can run strace -f on kinit.

One of the criticisms I've gotten for klibc has been why I have included 
dash and a whole bunch of shell utilities when they're not used by the 
default kernel build.  It certainly hasn't been just to prove a point; 
as a matter of fact, getting dash to build correctly under Kbuild proved 
to be surprisingly difficult.  However, by making sure that one can 
*easily* pull together an interactive environment -- even if one didn't 
have one from the start -- one has more readily access to a debuggable 
environment.

Similarly, I try very hard to have small, individually testable modules. 
  I haven't taken that even as far as I'd like to have, in the end, but 
that's on my list of things to do.

	-hpa

Re: [klibc] klibc and what's the next step?

[Theodore Tso]

On Sat, Jul 01, 2006 at 05:17:17PM -0700, H. Peter Anvin wrote:
> One of the criticisms I've gotten for klibc has been why I have included 
> dash and a whole bunch of shell utilities when they're not used by the 
> default kernel build.  It certainly hasn't been just to prove a point; 
> as a matter of fact, getting dash to build correctly under Kbuild proved 
> to be surprisingly difficult.  However, by making sure that one can 
> *easily* pull together an interactive environment -- even if one didn't 
> have one from the start -- one has more readily access to a debuggable 
> environment.

Well, I wouldn't be one of those folks.  In fact, how big is dash and
some select set of shell utilities?  If they aren't that big, it might
make sense to include them all the time so that a simple command-line
option on boot is all that's necessary in order to break into a
pre-kinit interactive shell.  That would make the resulting system
more debuggable by definition.  Then all we will would have to do is
make sure the distro's use the kernel-supplied kinit solution, instead
of rolling their own non-standard version.

						- Ted

Re: [klibc] klibc and what's the next step?

[H. Peter Anvin]

Theodore Tso wrote:
> 
> Well, I wouldn't be one of those folks.  In fact, how big is dash and
> some select set of shell utilities?  If they aren't that big, it might
> make sense to include them all the time so that a simple command-line
> option on boot is all that's necessary in order to break into a
> pre-kinit interactive shell.  That would make the resulting system
> more debuggable by definition.  Then all we will would have to do is
> make sure the distro's use the kernel-supplied kinit solution, instead
> of rolling their own non-standard version.
> 

Shared binaries, x86-64 (i386 is about 20-25% smaller):

-rwxrwxr-x 1 hpa hpa 58544 Jul  1 11:41 usr/dash/sh.shared*
-rwxrwxr-x 1 hpa hpa  2760 Jul  1 11:41 cat*
-rwxrwxr-x 1 hpa hpa   888 Jul  1 11:41 chroot*
-rwxrwxr-x 1 hpa hpa  4000 Jul  1 11:41 dd*
-rwxrwxr-x 1 hpa hpa   680 Jul  1 11:41 false*
-rwxrwxr-x 3 hpa hpa  1072 Jul  1 11:41 halt*
-rwxrwxr-x 1 hpa hpa  1664 Jul  1 11:41 insmod*
-rwxrwxr-x 1 hpa hpa  1336 Jul  1 11:41 ln*
-rwxrwxr-x 1 hpa hpa  5000 Jul  1 11:41 minips*
-rwxrwxr-x 1 hpa hpa  1984 Jul  1 11:41 mkdir*
-rwxrwxr-x 1 hpa hpa  1704 Jul  1 11:41 mkfifo*
-rwxrwxr-x 1 hpa hpa  1712 Jul  1 11:41 mknod*
-rwxrwxr-x 1 hpa hpa  2184 Jul  1 11:41 mount
-rwxrwxr-x 1 hpa hpa  1320 Jul  1 11:41 nuke*
-rwxrwxr-x 1 hpa hpa   856 Jul  1 11:41 pivot_root*
-rwxrwxr-x 3 hpa hpa  1072 Jul  1 11:41 poweroff*
-rwxrwxr-x 3 hpa hpa  1072 Jul  1 11:41 reboot*
-rwxrwxr-x 1 hpa hpa   864 Jul  1 11:41 sleep*
-rwxrwxr-x 1 hpa hpa   672 Jul  1 11:41 true*
-rwxrwxr-x 1 hpa hpa  1056 Jul  1 11:41 umount*
-rwxrwxr-x 1 hpa hpa  1952 Jul  1 11:41 uname*
-rw-rw-r-- 2 hpa hpa 71016 Jul  1 11:40 
usr/klibc/klibc-Yy9wepARlc-x17pdZDwU1YCOiMQ.so
-rwxrwxr-x 1 hpa hpa 35664 Jul  1 17:48 usr/kinit/kinit.shared*

... totalling about 193K if you include everything.  For comparison, 
static kinit by itself is 67K (which includes ipconfig, nfsroot, etc.) 
For an "include everything" variant, it would probably make more sense 
to port busybox, and/or add more tools as dash builtins.

All of these are uncompressed sizes.

	-hpa

Re: [klibc] klibc and what's the next step?

[H. Peter Anvin]

Theodore Tso wrote:
> 
> Personally, I would be happier with keeping things like suspend2 in
> the kernel, since I don't think the hellish compatibility problems
> with non-reviewed kernel functionality that has been ejected into
> userspace is really worth it --- but if we *are* going to go down the
> route pushing everything into userspace, it is going to be critical
> that distro's buy into using a kernel initialization system which is
> shipped with the kernel, and can be updated without being tied a
> particular distro's non-standard "value add".  Maybe that means we
> need to have hooks so that the distro's can add their non-standard
> "value add" without breaking the ability for users to upgrade to newer
> kernels.

That would be my feeling.  The ability to overlay initramfs is essential 
for that.

 > But either way, we're going to have to decide which way
> we're going to go, and if we're going to go down the blind
> in-userspace-good-in-kernel-bad approach, the distro's are going to
> have to cooperate or it's going to be a mess.

Of course.

	-hpa

Re: [klibc] klibc and what's the next step?

[Gerd Hoffmann]

> particular distro's non-standard "value add".  Maybe that means we
> need to have hooks so that the distro's can add their non-standard
> "value add" without breaking the ability for users to upgrade to newer
> kernels.

Sure we need that.  Not only for distro's "value add", but basically for
everything which depends on utilities not shipped with the kernel
(rootfs-on-lvm for example, udev & /dev setup, ...).  It's probably also
very handy for users and hackers to have a standard way to add stuff to
the initramfs during normal kernel build, without having to build their own.

cheers,

  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>
http://www.suse.de/~kraxel/julika-dora.jpeg

Re: [klibc] klibc and what's the next step?

[Pavel Machek]

Hi!

> Fortunately there is a workaround by not building the MPT Fusion
> device driver as a module, but if Pavel succeeds in ejecting software
> suspend into userspace, and preventing suspend2 from getting merged,
> *and* distro's insist on doing their own thing with initramfs, we are
> going to be headed for a major trainwreck.

Well, uswsusp kernel <-> user interface should be stable (and is
already in 2.6.17)... So I'd in fact _like_ distros to use their own
versions of suspend/resume tools -- so they can get nice splash
screens, compression and encryption.

Version bundled with kernel will _not_ have those features... it
should be simple to get working, but will provide bare-bones
functionality.

(But as ABI is stable, there should be no problem).
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [klibc] klibc and what's the next step?

[H. Peter Anvin]

Jeff Bailey wrote:
>> Either the kernel can unconditionally invoke /kinit, which then would 
>> invoke the users /init if present, or the swsusp can be a separate 
>> initramfs binary which the user's initramfs gets to invoke (the second 
>> is arguably neater, but requires minor changes to the users initramfs.)
> 
> The Ubuntu initramfs doesn't use kinit, and it would be nice if we
> weren't forced to.  We do a number of things in our initramfs (like a
> userspace bootsplace) which we need done before most of the things kinit
> wants to do take place.
> 
> kinit is a nice default tool but longer term, I almost imagine it as a
> busybox type of setup.  Either you say "go" and it brings up the system,
> or you call it with an argument, change argv[0] or something to get just
> the functionality asked for.

Modularity is good; in general I think the busybox model of one 
overgrown binary is probably not the right idea, but it depends of 
course on the specifics of the problem.

	-hpa

Re: [klibc] klibc and what's the next step?

[Jeff Garzik]

Jeff Bailey wrote:
> The Ubuntu initramfs doesn't use kinit, and it would be nice if we
> weren't forced to.  We do a number of things in our initramfs (like a
> userspace bootsplace) which we need done before most of the things kinit
> wants to do take place.

You would be required to perform the same duties as kinit (is the list 
of steps documented?), but not strictly required to use hpa's 
incarnation of kinit+klibc.

	Jeff

Re: klibc and what's the next step?

[Pavel Machek]

On Sat 2006-07-01 03:04:55, Michael Tokarev wrote:
> Pavel Machek wrote:
> [klibc/kinit in kernel]
> > I'd like to eventually move swsusp out of kernel, and klibc means I
> > may be able to do that without affecting users. Being in kinit is good
> > enough, because I can actually share single source between kinit
> > version and suspend.sf.net version.
> 
> Heh.  Take a look at anyone who's using real initramfs for their boot
> process.  Not initrd, not kernel-without-any-preboot-fs, but real
> initramfs.  For them, if kinit/klibc will be in kernel, nothing changes,
> because their initramfs *replaces* in-kernel code and future supplied-
> with-kernel-klibc-based-kinit.  So if you'll move swsusp into kinit,
> it WILL break setups for those users!.. ;)

Distros will probably want to use "real" code from swsusp.sf.net, not
stripped down version, provided for back compatibility with kernel.

								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: klibc and what's the next step?

[Olaf Hering]

On Tue, Jun 27, 2006 at 03:12:53PM +0200, Roman Zippel wrote:

> 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.

I do not want to see kinit merged.
It (the merge into linux-2.6.XY) doesnt solve any real problem in the long term.
Instead, make a kinit distribution. Let it install itself into an obvious
location on the development box (/usr/lib/kinit/* or whatever), remove all
code behind prepare_namespace() and put a disclaimer into the Linux 2.6.XY
releasenote stating where to grab and build a kinit binary:
make && sudo make install
It can even provide its own CONFIG_INITRAMFS_SOURCE file, so that would
be the only required change to the used .config.

The rationale is that there are essentially 2 kind of consumers:

One is the kind that builds static kernels and uses no initrd of any kind.
For those people, the code and interfaces behind prepare_namespace() has
not changed in a long time.
They will install that kinit binary once and it will continue to work with
kernels from 2.6.6 and later, when "/init" support was merged. Or rather
from 2.6.1x when CONFIG_INITRAMFS_SOURCE was introduced.

The other group is the one that uses some sort of initrd (loop mount or cpio),
created with tools from their distribution.
Again, they should install that kinit binary as well because kinit emulates
the loop mount handling of /initrd.image. This is for older distributions
that still create a loop mounted initrd.
A distribution that uses a cpio archive (SuSE does that since 2.6.5 in SLES9,
and since 2.6.13 in 10.0) has no need for the kinit. mkinitrd creates a
suitable cpio archive and the contained "/init" executable does all the 
hard work (as stated in the comment in init/main.c:init())


In earlier mails you stated that having kinit/klibc in the kernel sources
would make it easier to keep up with interface changes.
What interface changes did you have in mind, and can you name any relevant
interface changes that were made after 2.6.0 which would break an external
kinit?

24-klibc-basic-build-infrastructure.patch forces the klibc build, even for
setups where it is not required. CONFIG_KLIBC, if it ever gets merged, should
be optional. usr/initramfs.default as example has a hard requirement.
If CONFIG_KLIBC is off, only /dev, /dev/console and /root should be part of
the cpio archive in the .init.ramfs ELF section. The exectuables come from
the cpio initrd.
I once looked briefly for a patch that would introduce something like 
CONFIG_OBSOLETE_PREPARE_NAMESPACE which will make all code behind
prepare_namespace() optional. For SuSE, this dead code just wastes build time,
and it increases the vmlinux file size. While looking for ROOT_DEV users,
it wasnt obvious to me what requirements mtd has, so I postponed that attempt.
I'm sure ROOT_DEV can go as well in your patch named
29-remove-in-kernel-root-mounting-code.patch
All can be done outside the kernel code, and there is the root= cmdline option.


As others have stated in this thread, the code behind prepare_namespace() is 
very simple. It doesnt know anything abould lvm etc, nor about mount by
filesystem UUID/LABEL nor does it know how to deal with properly with new
technologies like iSCSI, evms, persistant storage device names, usb-storage,
sbp2 or async device probing.
Should all that knowledge end up in the kernel source on day?
An external kinit for such features sounds more logical.
If there are no plans to add these features, that just means that kinit
is real static functionality-wise. So having it as external binary makes
even more sense, given the amount of build time to spent for every new kernel.

Not really related to kinit per se:
There is also not much distribution specific inside initramfs (beside the file
locations to actually create a suitable cpio archive). There is still the
boundary between "/init" and the real init on the final root filesystem.
Otherwise static kernels would not be usable on these distributions.
I'm sure a mkinitrd that works for every distribution out there is possible.

Re: klibc and what's the next step?

[Michael Tokarev]

Olaf Hering wrote:
> On Tue, Jun 27, 2006 at 03:12:53PM +0200, Roman Zippel wrote:
> 
>> 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.
> 
> I do not want to see kinit merged.
> It (the merge into linux-2.6.XY) doesnt solve any real problem in the long term.
> Instead, make a kinit distribution. Let it install itself into an obvious
> location on the development box (/usr/lib/kinit/* or whatever), remove all
> code behind prepare_namespace() and put a disclaimer into the Linux 2.6.XY
> releasenote stating where to grab and build a kinit binary:

kinit SHOULD go with kernel. To stay compatible, to be able to move some more
stuff to it from kernelspace with time, and so on.

The question was about klibc, not kinit.

> The rationale is that there are essentially 2 kind of consumers:
> 
> One is the kind that builds static kernels and uses no initrd of any kind.
> For those people, the code and interfaces behind prepare_namespace() has
> not changed in a long time.
> They will install that kinit binary once and it will continue to work with
> kernels from 2.6.6 and later, when "/init" support was merged. Or rather
> from 2.6.1x when CONFIG_INITRAMFS_SOURCE was introduced.

And stuff will break on them after eg uswsusp move into kinit etc.

> The other group is the one that uses some sort of initrd (loop mount or cpio),
> created with tools from their distribution.
> Again, they should install that kinit binary as well because kinit emulates
> the loop mount handling of /initrd.image. This is for older distributions
> that still create a loop mounted initrd.

There's no need for loop-mounting of any initrd.images.  Initramfs (cpio image,
possible gzipped) works just fine, and it will NOT go away because something
should do the unpacking/loading of that image so that kinit &Co will run.
There's no need for old initrd+pivot_root at all.  Only the ones who are,
for some reason, didn't switch to initramfs yet.  And I personally see no
reasons not to switch - initramfs (rootfs) concept is much more clean and
easy to handle and gives more possibilities than initrd.

> A distribution that uses a cpio archive (SuSE does that since 2.6.5 in SLES9,
> and since 2.6.13 in 10.0) has no need for the kinit. mkinitrd creates a
> suitable cpio archive and the contained "/init" executable does all the 
> hard work (as stated in the comment in init/main.c:init())

It does need that.  At least partially.  Or, it should provide compatible
replacement for the next kernel you compile -- See above, with more stuff
moved from kernel to kinit (or utils based on it), the more tricky it will
be to maintain such a beast outside of the kernel.

> In earlier mails you stated that having kinit/klibc in the kernel sources
> would make it easier to keep up with interface changes.
> What interface changes did you have in mind, and can you name any relevant
> interface changes that were made after 2.6.0 which would break an external
> kinit?

Ok.  To be fair, except of swsusp (which i don't use anyway, as it does not
work on VIA C3-based boxes), I can't think of anything more.  The rest (like
dhcp (kernel-level IP autoconfig), etc) is already in kinit, and it should
be compatible with future kernels.

So hmm.  Maybe my arguments above are wrong.

Once that same swsusp is moved to kinit, the latter should be updated --
that's basically all.

> 24-klibc-basic-build-infrastructure.patch forces the klibc build, even for
> setups where it is not required. CONFIG_KLIBC, if it ever gets merged, should
> be optional. usr/initramfs.default as example has a hard requirement.
> If CONFIG_KLIBC is off, only /dev, /dev/console and /root should be part of
> the cpio archive in the .init.ramfs ELF section. The exectuables come from
> the cpio initrd.

Agreed 100%.

> I once looked briefly for a patch that would introduce something like 
> CONFIG_OBSOLETE_PREPARE_NAMESPACE which will make all code behind
> prepare_namespace() optional. For SuSE, this dead code just wastes build time,
> and it increases the vmlinux file size. While looking for ROOT_DEV users,
> it wasnt obvious to me what requirements mtd has, so I postponed that attempt.
> I'm sure ROOT_DEV can go as well in your patch named
> 29-remove-in-kernel-root-mounting-code.patch
> All can be done outside the kernel code, and there is the root= cmdline option.
> 
> 
> As others have stated in this thread, the code behind prepare_namespace() is 
> very simple. It doesnt know anything abould lvm etc, nor about mount by
> filesystem UUID/LABEL nor does it know how to deal with properly with new
> technologies like iSCSI, evms, persistant storage device names, usb-storage,
> sbp2 or async device probing.
> Should all that knowledge end up in the kernel source on day?
> An external kinit for such features sounds more logical.
> If there are no plans to add these features, that just means that kinit
> is real static functionality-wise. So having it as external binary makes
> even more sense, given the amount of build time to spent for every new kernel.

Nod.

/mjt

> Not really related to kinit per se:
> There is also not much distribution specific inside initramfs (beside the file
> locations to actually create a suitable cpio archive). There is still the
> boundary between "/init" and the real init on the final root filesystem.
> Otherwise static kernels would not be usable on these distributions.
> I'm sure a mkinitrd that works for every distribution out there is possible.

Re: [klibc] klibc and what's the next step?

[Olaf Hering]

 On Tue, Jul 11, Michael Tokarev wrote:

> kinit SHOULD go with kernel. To stay compatible, to be able to move some more
> stuff to it from kernelspace with time, and so on.

compatible with what? What changes do you expect that will break kinit
as we have it right now?

> The question was about klibc, not kinit.

klibc without user is really pointless.

> > The rationale is that there are essentially 2 kind of consumers:
> > 
> > One is the kind that builds static kernels and uses no initrd of any kind.
> > For those people, the code and interfaces behind prepare_namespace() has
> > not changed in a long time.
> > They will install that kinit binary once and it will continue to work with
> > kernels from 2.6.6 and later, when "/init" support was merged. Or rather
> > from 2.6.1x when CONFIG_INITRAMFS_SOURCE was introduced.
> 
> And stuff will break on them after eg uswsusp move into kinit etc.

Why? If they want that new feature:
download kinit-2.0, make && make install. That concept is not new.
kinit-2.0 will surely be compatible with what is required for last years
kernel because its not maintained by the-average-udev-developer kind of
people.

> > The other group is the one that uses some sort of initrd (loop mount or cpio),
> > created with tools from their distribution.
> > Again, they should install that kinit binary as well because kinit emulates
> > the loop mount handling of /initrd.image. This is for older distributions
> > that still create a loop mounted initrd.
> 
> There's no need for loop-mounting of any initrd.images.  Initramfs (cpio image,
> possible gzipped) works just fine, and it will NOT go away because something
> should do the unpacking/loading of that image so that kinit &Co will run.
> There's no need for old initrd+pivot_root at all.  Only the ones who are,
> for some reason, didn't switch to initramfs yet.  And I personally see no
> reasons not to switch - initramfs (rootfs) concept is much more clean and
> easy to handle and gives more possibilities than initrd.

Are you saying that everyone now suddenly is forced to use a cpio image?
Why did hpa add the loop mount code to kinit?
So if you force people who build kernels to use newer tools, one more
external binary will surely not hurt.

Re: [klibc] klibc and what's the next step?

[H. Peter Anvin]

Olaf Hering wrote:
> 
>>> The other group is the one that uses some sort of initrd (loop mount or cpio),
>>> created with tools from their distribution.
>>> Again, they should install that kinit binary as well because kinit emulates
>>> the loop mount handling of /initrd.image. This is for older distributions
>>> that still create a loop mounted initrd.
>> There's no need for loop-mounting of any initrd.images.  Initramfs (cpio image,
>> possible gzipped) works just fine, and it will NOT go away because something
>> should do the unpacking/loading of that image so that kinit &Co will run.
>> There's no need for old initrd+pivot_root at all.  Only the ones who are,
>> for some reason, didn't switch to initramfs yet.  And I personally see no
>> reasons not to switch - initramfs (rootfs) concept is much more clean and
>> easy to handle and gives more possibilities than initrd.
> 
> Are you saying that everyone now suddenly is forced to use a cpio image?
> Why did hpa add the loop mount code to kinit?
> So if you force people who build kernels to use newer tools, one more
> external binary will surely not hurt.

When you say "loop mount code" I presume you mean legacy initrd support 
(which doesn't use loop mounting.)  Legacy initrd support is provided to 
be as compatible as possible, obviously.

And yes, it should be a configurable.  Chopping kinit into configurable 
pieces is on my short list.

	-hpa

Re: [klibc] klibc and what's the next step?

[Olaf Hering]

 On Tue, Jul 11, H. Peter Anvin wrote:

> When you say "loop mount code" I presume you mean legacy initrd support 
> (which doesn't use loop mounting.)  Legacy initrd support is provided to 
> be as compatible as possible, obviously.

Yes.
To create the initrd you needed a loop file, at least for ext2, minix etc.

But so far, the arguments are not convincing that kinit has to be in the
kernel tree.

Re: [klibc] klibc and what's the next step?

[Jeff Garzik]

Olaf Hering wrote:
>  On Tue, Jul 11, H. Peter Anvin wrote:
> 
>> When you say "loop mount code" I presume you mean legacy initrd support 
>> (which doesn't use loop mounting.)  Legacy initrd support is provided to 
>> be as compatible as possible, obviously.
> 
> Yes.
> To create the initrd you needed a loop file, at least for ext2, minix etc.
> 
> But so far, the arguments are not convincing that kinit has to be in the
> kernel tree.

Two are IMO fairly plain:

* Makes sure you can boot the kernel you just built.

* Makes it easier to move stuff between kernel and userspace.

Re: [klibc] klibc and what's the next step?

[Olaf Hering]

 On Tue, Jul 11, Jeff Garzik wrote:

> Two are IMO fairly plain:
> 
> * Makes sure you can boot the kernel you just built.

There is always some sort of prereq when new features get added.
Documentation/Changes has a long list. Some setup need more updates,
some need fewer updates. No idea what your experience is.
Old klibc was trivial to build (modulo that kernel header mess), and I
expect that kinit handles old kernels.

> * Makes it easier to move stuff between kernel and userspace.

What do you have in mind here?
Once prepare_namespace is gone, there is no userspace code left.

Re: [klibc] klibc and what's the next step?

[H. Peter Anvin]

Olaf Hering wrote:
>  On Tue, Jul 11, Jeff Garzik wrote:
> 
>> Two are IMO fairly plain:
>>
>> * Makes sure you can boot the kernel you just built.
> 
> There is always some sort of prereq when new features get added.
> Documentation/Changes has a long list. Some setup need more updates,
> some need fewer updates. No idea what your experience is.
> Old klibc was trivial to build (modulo that kernel header mess), and I
> expect that kinit handles old kernels.
> 

"Old klibc" still exists and is the same code out of the same source tree.

>> * Makes it easier to move stuff between kernel and userspace.
> 
> What do you have in mind here?
> Once prepare_namespace is gone, there is no userspace code left.

Things that have been bandied about, for example:

	- suspend/resume
	- partition discovery

I'm sure there is more.

	-hpa

Re: [klibc] klibc and what's the next step?

[Olaf Hering]

 On Tue, Jul 11, H. Peter Anvin wrote:

> "Old klibc" still exists and is the same code out of the same source tree.

I meant more the "easy to build" part.

> >>* Makes it easier to move stuff between kernel and userspace.
> >
> >What do you have in mind here?
> >Once prepare_namespace is gone, there is no userspace code left.
> 
> Things that have been bandied about, for example:
> 
> 	- suspend/resume
> 	- partition discovery
> 
> I'm sure there is more.

Do you plan to share source files betweek kernel and kinit? Or how is it
harder for external kinit to handle that?

Re: [klibc] klibc and what's the next step?

[H. Peter Anvin]

Olaf Hering wrote:
>  On Tue, Jul 11, H. Peter Anvin wrote:
> 
>> "Old klibc" still exists and is the same code out of the same source tree.
> 
> I meant more the "easy to build" part.
> 
>>>> * Makes it easier to move stuff between kernel and userspace.
>>> What do you have in mind here?
>>> Once prepare_namespace is gone, there is no userspace code left.
>> Things that have been bandied about, for example:
>>
>> 	- suspend/resume
>> 	- partition discovery
>>
>> I'm sure there is more.
> 
> Do you plan to share source files betweek kernel and kinit? Or how is it
> harder for external kinit to handle that?

It's a deployment problem, arguably especially for people who 
cross-compile.  You have two major pieces of code (kernel and klibc) 
which have to be changed at the same time, with different maintainers 
and reviewers.

	-hpa

Re: [klibc] klibc and what's the next step?

[Olaf Hering]

 On Tue, Jul 11, H. Peter Anvin wrote:

> It's a deployment problem, arguably especially for people who 
> cross-compile.  You have two major pieces of code (kernel and klibc) 
> which have to be changed at the same time, with different maintainers 
> and reviewers.

Why is that a problem? You cant rip code from the kernel before the main
kinit has support for that removed feature. Thats obvious.
I dont use suspend, so I dont know how the existing in-kernel code has to
look in kinit.
But for the partition discovery (the ROOT_DEV users) its likely less than
100 lines of code. And after all, root= exists. Probably not a big loss if
that code just disappears.

I dont get your point.

Re: [klibc] klibc and what's the next step?

[H. Peter Anvin]

Olaf Hering wrote:
> But for the partition discovery (the ROOT_DEV users) its likely less than
> 100 lines of code. And after all, root= exists. Probably not a big loss if
> that code just disappears.

Partition discovery is not "the ROOT_DEV users".  It's the mapping of 
certain chunks of disk to partitions.

	-hpa

Re: [klibc] klibc and what's the next step?

[Olaf Hering]

 On Tue, Jul 11, H. Peter Anvin wrote:

> Olaf Hering wrote:
> >But for the partition discovery (the ROOT_DEV users) its likely less than
> >100 lines of code. And after all, root= exists. Probably not a big loss if
> >that code just disappears.
> 
> Partition discovery is not "the ROOT_DEV users".  It's the mapping of 
> certain chunks of disk to partitions.

Now I'm confused.
Is the kernel partition code supposed to go at some point?
Some people suggested that, but Linus was not convinced.

If you mean just 'interpreting the partition table', thats not hard
either. I just poked at such code in yaboot a few weeks ago.

Re: [klibc] klibc and what's the next step?

[H. Peter Anvin]

Olaf Hering wrote:
> Now I'm confused.
> Is the kernel partition code supposed to go at some point?
> Some people suggested that, but Linus was not convinced.

It's a proposal, and I personally think it makes sense.  If done, it is 
obviously very important that it doesn't change the overall operation of 
the system.

> If you mean just 'interpreting the partition table', thats not hard
> either. I just poked at such code in yaboot a few weeks ago.

It's not hard; any of the partition table stuff, but we have quite a 
proliferation of them.  It'd be even easier in userspace.

	-hpa

Re: [klibc] klibc and what's the next step?

[Olaf Hering]

 On Tue, Jul 11, H. Peter Anvin wrote:

> Olaf Hering wrote:
> >Now I'm confused.
> >Is the kernel partition code supposed to go at some point?
> >Some people suggested that, but Linus was not convinced.
> 
> It's a proposal, and I personally think it makes sense.  If done, it is 
> obviously very important that it doesn't change the overall operation of 
> the system.

I think you can have that today, parted uses BLKPG to add and remoe
things. No idea what the benefit would be, but thats not relavant for
kinit or no kinit.

Re: [klibc] klibc and what's the next step?

[Linus Torvalds]

On Tue, 11 Jul 2006, Olaf Hering wrote:
> > 
> > It's a proposal, and I personally think it makes sense.  If done, it is 
> > obviously very important that it doesn't change the overall operation of 
> > the system.
> 
> I think you can have that today, parted uses BLKPG to add and remoe
> things. No idea what the benefit would be, but thats not relavant for
> kinit or no kinit.

The notion that the kernel itself should do no partition parsing at all 
was advocated by Andries Brouwer. I violently disagree. Anything that the 
lack of which makes a normal system basically unusable should go into the 
kernel.

Yes, the kernel rules are heuristics, but so would inevitably any 
user-level rules be too, so I don't want to move partition detection to 
initrd or similar.

		Linus

Re: [klibc] klibc and what's the next step?

[H. Peter Anvin]

Linus Torvalds wrote:
> 
> On Tue, 11 Jul 2006, Olaf Hering wrote:
>>> It's a proposal, and I personally think it makes sense.  If done, it is 
>>> obviously very important that it doesn't change the overall operation of 
>>> the system.
>> I think you can have that today, parted uses BLKPG to add and remoe
>> things. No idea what the benefit would be, but thats not relavant for
>> kinit or no kinit.
> 
> The notion that the kernel itself should do no partition parsing at all 
> was advocated by Andries Brouwer. I violently disagree. Anything that the 
> lack of which makes a normal system basically unusable should go into the 
> kernel.
> 

Does that mean "in kernel space", "in the kernel distribution" or "in 
memory completely under the control by the kernel?"  That is really what 
this is about.

There could be a klibc-build binary in rootfs, build at the time the 
kernel was built, that can be invoked by the kernel in parallel with 
/sbin/hotplug.

> Yes, the kernel rules are heuristics, but so would inevitably any 
> user-level rules be too, so I don't want to move partition detection to 
> initrd or similar.

The whole point of putting klibc in the kernel tree is so we can do this 
kind of stuff without breaking the stock kernel build as a 
self-contained entity.  Without that objective, Olaf is right that it is 
not necessary.

	-hpa

Re: [klibc] klibc and what's the next step?

[Linus Torvalds]

On Tue, 11 Jul 2006, H. Peter Anvin wrote:
> 
> Does that mean "in kernel space", "in the kernel distribution" or "in memory
> completely under the control by the kernel?"  That is really what this is
> about.

I think it's all about kernel space.

Moving the default parsing to user space would add exactly _zero_ 
advantage, and would add totally unnecessary complexity (ie now we need to 
make sure that hotplug does it right - and the hotplug routines suddenly 
change between the boot phase and the actual install).

		Linus

Re: [klibc] klibc and what's the next step?

[Jeff Garzik]

Linus Torvalds wrote:
> 
> On Tue, 11 Jul 2006, H. Peter Anvin wrote:
>> Does that mean "in kernel space", "in the kernel distribution" or "in memory
>> completely under the control by the kernel?"  That is really what this is
>> about.
> 
> I think it's all about kernel space.
> 
> Moving the default parsing to user space would add exactly _zero_ 
> advantage, and would add totally unnecessary complexity (ie now we need to 
> make sure that hotplug does it right - and the hotplug routines suddenly 
> change between the boot phase and the actual install).

With LVM (default RHEL and Fedora installs encourage you in that 
direction) and EVMS (device mapper), these issues already exist.

Today's default install has "partition" parsing in both the kernel and 
userspace...  talk about complexity :)

	Jeff

Re: [klibc] klibc and what's the next step?

[Theodore Tso]

On Tue, Jul 11, 2006 at 12:51:31PM -0700, Linus Torvalds wrote:
> On Tue, 11 Jul 2006, H. Peter Anvin wrote:
> > 
> > Does that mean "in kernel space", "in the kernel distribution" or "in memory
> > completely under the control by the kernel?"  That is really what this is
> > about.
> 
> I think it's all about kernel space.
> 
> Moving the default parsing to user space would add exactly _zero_ 
> advantage, and would add totally unnecessary complexity (ie now we need to 
> make sure that hotplug does it right - and the hotplug routines suddenly 
> change between the boot phase and the actual install).

While you're at it, do you think you'd be willing to opine about doing
whether it makes sense to chuck out the guts of suspend-to-disk so
that it must be done in userspace?  

						- Ted

Re: [klibc] klibc and what's the next step?

[Olaf Hering]

 On Tue, Jul 11, Linus Torvalds wrote:

> 
> 
> On Tue, 11 Jul 2006, H. Peter Anvin wrote:
> > 
> > Does that mean "in kernel space", "in the kernel distribution" or "in memory
> > completely under the control by the kernel?"  That is really what this is
> > about.
> 
> I think it's all about kernel space.
> 
> Moving the default parsing to user space would add exactly _zero_ 
> advantage, and would add totally unnecessary complexity (ie now we need to 
> make sure that hotplug does it right - and the hotplug routines suddenly 
> change between the boot phase and the actual install).

It depends what the benefit for such a change is. I cant come up with a
good guess. Maybe someone should write a paper and present it at OLS.

Re: [klibc] klibc and what's the next step?

[H. Peter Anvin]

Linus Torvalds wrote:
> 
> On Tue, 11 Jul 2006, H. Peter Anvin wrote:
>> Does that mean "in kernel space", "in the kernel distribution" or "in memory
>> completely under the control by the kernel?"  That is really what this is
>> about.
> 
> I think it's all about kernel space.
> 
> Moving the default parsing to user space would add exactly _zero_ 
> advantage, and would add totally unnecessary complexity (ie now we need to 
> make sure that hotplug does it right - and the hotplug routines suddenly 
> change between the boot phase and the actual install).
> 

There is no reason the hotplug routines should change between the boot 
phase and actual install.  Please note that I didn't say "instead of 
/sbin/hotplug", I said in rootfs in addition to /sbin/hotplug.

If it adds complexity, it's The Wrong Thing.  However, it seems very 
strange to me to draw the boundary at the kernel-space boundary.

	-hpa

Re: [klibc] klibc and what's the next step?

[H. Peter Anvin]

Olaf Hering wrote:
> 
> There is always some sort of prereq when new features get added.
> Documentation/Changes has a long list. Some setup need more updates,
> some need fewer updates. No idea what your experience is.
> Old klibc was trivial to build (modulo that kernel header mess), and I
> expect that kinit handles old kernels.
> 

One more thing on this subject... "modulo that kernel header mess" is 
just as much a reflection of the fact that the Linux ABI really isn't 
particularly stable.  glibc contains a huge amount of code to deal with 
different kernel versions.  klibc will not be doing this; in general old 
klibcs should continue to work (but may not compile against a newer 
kernel), but a newer klibc may not work on an older kernel.

	-hpa

Re: [klibc] klibc and what's the next step?

[Michael Tokarev]

H. Peter Anvin wrote:
> Olaf Hering wrote:
[]
> [...] in general old
> klibcs should continue to work (but may not compile against a newer
> kernel), but a newer klibc may not work on an older kernel.

Heh.  Olaf says about "basic backwards compatibilty", referring to
the klingon dictionary...

(please don't treat this as an offense - just.. funny)

/mjt

Re: [klibc] klibc and what's the next step?

[Olaf Hering]

 On Tue, Jul 11, H. Peter Anvin wrote:

> Olaf Hering wrote:
> >
> >There is always some sort of prereq when new features get added.
> >Documentation/Changes has a long list. Some setup need more updates,
> >some need fewer updates. No idea what your experience is.
> >Old klibc was trivial to build (modulo that kernel header mess), and I
> >expect that kinit handles old kernels.
> >
> 
> One more thing on this subject... "modulo that kernel header mess" is 
> just as much a reflection of the fact that the Linux ABI really isn't 
> particularly stable.  glibc contains a huge amount of code to deal with 
> different kernel versions.  klibc will not be doing this; in general old 
> klibcs should continue to work (but may not compile against a newer 
> kernel), but a newer klibc may not work on an older kernel.

"It would be nice if ..." someone can build a list of things that
changed over time. Say from 2.0.0 to 2.6.18. Just struct layouts and defines.

I havent tried it, but one would hope that the /bin/ls from SuSE 5.3 still
works today.  Guess its time for me to actually try that the next days.

Re: [klibc] klibc and what's the next step?

[H. Peter Anvin]

Olaf Hering wrote:
> "It would be nice if ..." someone can build a list of things that
> changed over time. Say from 2.0.0 to 2.6.18. Just struct layouts and defines.
> 
> I havent tried it, but one would hope that the /bin/ls from SuSE 5.3 still
> works today.  Guess its time for me to actually try that the next days.

You know how much code there is in glibc to make your /bin/ls still work?

That being said, it in general isn't a problem to continue to use the 
same exact sets of system calls, but that also means skipping any new 
functionality.  In recent memory that includes things like 64-bit file 
offsets and high signals, even more recently it means things like 
openat() and splice().  A full-blown libc also has to deal with 
LinuxThreads version NPTL.  Etc.

Again, I fully expect that klibc-0.1 still works on the current kernels, 
but current klibc wouldn't work on 2.4 kernels.

	-hpa

Re: [klibc] klibc and what's the next step?

[Alan Cox]

Ar Maw, 2006-07-11 am 11:22 -0700, ysgrifennodd H. Peter Anvin:
> You know how much code there is in glibc to make your /bin/ls still work?

A static linked pre libc 2.2 (thats libc not glibc) ls works fine today,
as does a 0.98.5 era built rogue binary

Re: [klibc] klibc and what's the next step?

[H. Peter Anvin]

Alan Cox wrote:
> Ar Maw, 2006-07-11 am 11:22 -0700, ysgrifennodd H. Peter Anvin:
>> You know how much code there is in glibc to make your /bin/ls still work?
> 
> A static linked pre libc 2.2 (thats libc not glibc) ls works fine today,
> as does a 0.98.5 era built rogue binary

Didn't work when I tried it, although that was a shared binary (and yes, 
I had the library there.)  I assumed mostly that ZMAGIC support had 
bitrotted -- even back in '95 there was a lot of problems with ZMAGIC 
binaries when ext2 block size was > 1K.

	-hpa

Re: [klibc] klibc and what's the next step?

[Olaf Hering]

 On Tue, Jul 11, H. Peter Anvin wrote:

> Olaf Hering wrote:
> >"It would be nice if ..." someone can build a list of things that
> >changed over time. Say from 2.0.0 to 2.6.18. Just struct layouts and 
> >defines.
> >
> >I havent tried it, but one would hope that the /bin/ls from SuSE 5.3 still
> >works today.  Guess its time for me to actually try that the next days.
> 
> You know how much code there is in glibc to make your /bin/ls still work?

I heard about that, but did never inspect that code.

My point is:
I see all day that people use some fixed distro for kernel development,
thats their stable base. In my case, 2.4.19 based SLES8 for 2.6
development. 2.6.5 based SLES9 for todays kernel. In a few weeks, they
will move on to 2.6.16 based SLES10. Same thing with other distros.

This means their tools continue to work, eventually they have to upgrade
a few things to test newly added features. Thats what everyone on this
list does all day. It means also that regression testing is possible.
One can even boot a 2.4 kernel in SLES9 to try things out, despite the
fact that many boot scripts rely on sysfs. So I dont see why a kinit
that knows about a range of kernels should not be possible. No idea how
hairy device-mapper, lvm or evms support is, the "standard" tools
appearently cope with interface changes.
If you decide to drop support for 2.6.16 in 3 years, thats ok. But not
in 3 months please.

And to give a negative example for great regression test opportunities:
You guessed it, SLES10 has a udev that cant handle kernels before 2.6.15.
Great job. I could slap them all day...

Re: [klibc] klibc and what's the next step?

[Olaf Hering]

 On Tue, Jul 11, Olaf Hering wrote:

> My point is:

Of course thats not the only one.
If nothing changes in userspace, it still has to be build with every new
kernel no matter how many other kernel changes were just added.
I remember it took some time to build klibc-0.123.
And if klibc really depends on kernel headers, and I do git-bisect on a
slower box, thats a waste of time. That really asks for an external
binary. Or CONFIG_KLIBC=n, if thats not convincing.

Re: [klibc] klibc and what's the next step?

[Greg KH]

On Tue, Jul 11, 2006 at 10:06:40PM +0200, Olaf Hering wrote:
> And to give a negative example for great regression test opportunities:
> You guessed it, SLES10 has a udev that cant handle kernels before 2.6.15.
> Great job. I could slap them all day...

Just to be specific, the udev in SLES10 can handle older kernels than
2.6.15 just fine, it's just the boot scripts around it are not written
to do so.

Other distros happily run newer udev versions on older kernels just
fine, so don't try blaming the main udev program on this please...

thanks,

greg k-h

Re: [klibc] klibc and what's the next step?

[Olaf Hering]

 On Tue, Jul 11, Greg KH wrote:

> On Tue, Jul 11, 2006 at 10:06:40PM +0200, Olaf Hering wrote:
> > And to give a negative example for great regression test opportunities:
> > You guessed it, SLES10 has a udev that cant handle kernels before 2.6.15.
> > Great job. I could slap them all day...
> 
> Just to be specific, the udev in SLES10 can handle older kernels than
> 2.6.15 just fine, it's just the boot scripts around it are not written
> to do so.

What difference does that make exactly? "It doesnt work."

Re: [klibc] klibc and what's the next step?

[Arjan van de Ven]

On Wed, 2006-07-12 at 18:54 +0200, Olaf Hering wrote:
>  On Tue, Jul 11, Greg KH wrote:
> 
> > On Tue, Jul 11, 2006 at 10:06:40PM +0200, Olaf Hering wrote:
> > > And to give a negative example for great regression test opportunities:
> > > You guessed it, SLES10 has a udev that cant handle kernels before 2.6.15.
> > > Great job. I could slap them all day...
> > 
> > Just to be specific, the udev in SLES10 can handle older kernels than
> > 2.6.15 just fine, it's just the boot scripts around it are not written
> > to do so.
> 
> What difference does that make exactly? "It doesnt work."
> -

who cares?

You're talking about compatibility in the wrong direction. You don't
expect to be able to run a 2.2 kernel on SLES10 either. A distro
expecting the kernel to be at least of the version that comes with it
imo is entirely justified and even required to use new features in an
integrated way without overbloating the distro with never used and
undertested compatibility junk.

Running a NEWER kernel.. that's where people have a point.
Now, arguably some of the enterprise distros are not designed with that
in mind (unlike most community distributions), but it's not entirely
unreasonable to expect to be able to do this at least for a while.

Greetings,
   Arjan van de Ven

Re: [klibc] klibc and what's the next step?

[Olaf Hering]

 On Wed, Jul 12, Arjan van de Ven wrote:

> On Wed, 2006-07-12 at 18:54 +0200, Olaf Hering wrote:
> >  On Tue, Jul 11, Greg KH wrote:
> > 
> > > On Tue, Jul 11, 2006 at 10:06:40PM +0200, Olaf Hering wrote:
> > > > And to give a negative example for great regression test opportunities:
> > > > You guessed it, SLES10 has a udev that cant handle kernels before 2.6.15.
> > > > Great job. I could slap them all day...
> > > 
> > > Just to be specific, the udev in SLES10 can handle older kernels than
> > > 2.6.15 just fine, it's just the boot scripts around it are not written
> > > to do so.
> > 
> > What difference does that make exactly? "It doesnt work."
> > -
> 
> who cares?

I do damnit. Its just a udevstart away...
Anyway, offtopic.

Re: [klibc] klibc and what's the next step?

[Greg KH]

On Wed, Jul 12, 2006 at 06:54:23PM +0200, Olaf Hering wrote:
>  On Tue, Jul 11, Greg KH wrote:
> 
> > On Tue, Jul 11, 2006 at 10:06:40PM +0200, Olaf Hering wrote:
> > > And to give a negative example for great regression test opportunities:
> > > You guessed it, SLES10 has a udev that cant handle kernels before 2.6.15.
> > > Great job. I could slap them all day...
> > 
> > Just to be specific, the udev in SLES10 can handle older kernels than
> > 2.6.15 just fine, it's just the boot scripts around it are not written
> > to do so.
> 
> What difference does that make exactly? "It doesnt work."

Then say "the boot scripts are causing older kernels not to work", not
"udev can't handle kernels before 2.6.15", which is not true.

pedantically,

greg k-h

Re: [klibc] klibc and what's the next step?

[Michael Tokarev]

Jeff Garzik wrote:
[]
>> But so far, the arguments are not convincing that kinit has to be in the
>> kernel tree.
> 
> Two are IMO fairly plain:
> 
> * Makes sure you can boot the kernel you just built.

Nowadays, less and less setups will Just Work without additional
help.  softraid/lvm (yes I know about raid-autodetect, which should
DIE better sooner than later, due to its brokeness), firmware loading,
DSDT table updates, iSCSI and what not.

So, by just moving stuff to kinit and providing it with kernel
solves nothing in this area.

Yes, there's a very tiny difference between in-kernel kinit and
external kinit: I mean, external kinit has a >< bit more chances
to be incompatible with new kernel than kernel-supplied one.
But so are other tools and libraries, listed in Documentation/Changes.

> * Makes it easier to move stuff between kernel and userspace.

Again, not an argument to have kinit to be supplied by kernel.
Or, rarther, not strong argument.

It'd be much easier to "test" some stuff and to shuffle things
between kernel and user spaces if kinit is a part of kernel.
Like, move things to kinit, discover it does not quite work,
move some stuff back, etc.  With external kinit that will not
be easy, and kinit will grow indefinitely, accumulating all
the various compatibility/testing cruft.

But that's not how things should be done IMHO.  Testing/planning,
that is...

And again, how much stuff it's possible to shuffle this way?
How many new concepts *can* be moved from kernel to kinit,
anyway?  Uswsusp has been mentioned.  Anything else?

/mjt

Re: [klibc] klibc and what's the next step?

[Michael Tokarev]

Olaf Hering wrote:
[]
> To create the initrd you needed a loop file, at least for ext2, minix etc.

It's just damn trivial to pack your files into cpio archive and gzip it.
No need for any filesystem code in kernel, be it ext2, minix or other.

initrd => initramfs conversion (what you said I "force" on users) is
to switch from loop+whatever-fs-du-jur to plain dirrectory and cpio,
and to add the final mount+run_init into the initrd script.  And after
that's done, everything becomes good... ;)

> But so far, the arguments are not convincing that kinit has to be in the
> kernel tree.

Here, I agree.

/mjt

Re: [klibc] klibc and what's the next step?

[Olaf Hering]

 On Tue, Jul 11, Michael Tokarev wrote:

> Olaf Hering wrote:
> []
> > To create the initrd you needed a loop file, at least for ext2, minix etc.
> 
> It's just damn trivial to pack your files into cpio archive and gzip it.

The point is not how trivial it is. The point is how much has to change
that you can run 2.6.42 on an 42 year old installation with the tools
that were available at that time.
Obiviously you cant be bothered to install newer packages, like kinit.rpm.
Basic backwards compatibilty. Its not a term from the klingon dictionary.

Btw, kinit is already taken, some kerberos thing.

Re: [klibc] klibc and what's the next step?

[Michael Tokarev]

Olaf Hering wrote:
>  On Tue, Jul 11, Michael Tokarev wrote:
> 
>> Olaf Hering wrote:
>> []
>>> To create the initrd you needed a loop file, at least for ext2, minix etc.
>> It's just damn trivial to pack your files into cpio archive and gzip it.
> 
> The point is not how trivial it is. The point is how much has to change
> that you can run 2.6.42 on an 42 year old installation with the tools
> that were available at that time.

I'd say you've ZERO chance to run just new kernel.  You will need more
recent glibc, never softraid tools, you will discover that /dev/hdXX are
all gone, and so on.

> Obiviously you cant be bothered to install newer packages, like kinit.rpm.
> Basic backwards compatibilty. Its not a term from the klingon dictionary.

Well.  I'd say it's not that obvious.  For example, I can't boot redhat-6.0
system with current 2.6 kernel (I once tried that, probably with 2.6.9 or
something - there were quite.. some problems.  Upgrading several packages,
including glibc compiled against 2.6 kernel, solved that. Some stuff was
still broken, but I didn't try hard).  BTW, devfs is just one example...
try to boot a one-year-old gentoo distro (not 42, but 1) with current
2.6 without devfs... ;)

Another point is: why the heck you want to boot such 42-years-old system
with current "best, grestest" kernel, anyway?

> Btw, kinit is already taken, some kerberos thing.

Heh. Yes it is.

/mjt

Re: [klibc] klibc and what's the next step?

[Sam Ravnborg]

On Tue, Jul 11, 2006 at 06:48:34AM +0200, Olaf Hering wrote:
> 
> 24-klibc-basic-build-infrastructure.patch forces the klibc build, even for
> setups where it is not required. CONFIG_KLIBC, if it ever gets merged, should
> be optional.

Thats a 10 linier to usr/Kconfig - not a big deal to fix.
And agreed it shall not be compiled if not used/necessary.

So this part is more of a 'we shall fix' issue, and has nothing to do
with the direction of the future.

	Sam

Re: klibc and what's the next step?

[Theodore Tso]

On Tue, Jul 11, 2006 at 06:48:34AM +0200, Olaf Hering wrote:
> One is the kind that builds static kernels and uses no initrd of any kind.
> For those people, the code and interfaces behind prepare_namespace() has
> not changed in a long time.
> They will install that kinit binary once and it will continue to work with
> kernels from 2.6.6 and later, when "/init" support was merged. Or rather
> from 2.6.1x when CONFIG_INITRAMFS_SOURCE was introduced.
> 
> The other group is the one that uses some sort of initrd (loop mount or cpio),
> created with tools from their distribution.
> Again, they should install that kinit binary as well because kinit emulates
> the loop mount handling of /initrd.image. This is for older distributions
> that still create a loop mounted initrd.

Kinit SHOULD be merged into the kernel, and the responsibility of
creating the initrd/initramfs image should be moved from the
distribution into the kernel build process.  There can and should be a
way for distro's to add their own "value add specials" into the
initrd/initramfs image, but we have to take over creating the base
initial userspace environment.  It's not just uswsusp (still not
convinced it's a good idea, but if we're going to do it we have to
wrest control of the initramfs away from the distro's), but finding
and mounting iSCSI disks, LVM setup, etc.

> In earlier mails you stated that having kinit/klibc in the kernel sources
> would make it easier to keep up with interface changes.
> What interface changes did you have in mind, and can you name any relevant
> interface changes that were made after 2.6.0 which would break an external
> kinit?

When you load a SCSI driver (the one that bit me was the MPT Fusion
driver), it no longer waits for SCSI bus probe to finish before
returning.  So the RHEL4 initrd fails to find the root filesystem, and
bombs out.  This change was definitely made after 2.6.0, and is an
example of the sort of change which wouldn't have happened if kinit
was under the kernel sources and not supplied by the distro.

> As others have stated in this thread, the code behind prepare_namespace() is 
> very simple. It doesnt know anything abould lvm etc, nor about mount by
> filesystem UUID/LABEL nor does it know how to deal with properly with new
> technologies like iSCSI, evms, persistant storage device names, usb-storage,
> sbp2 or async device probing.
> Should all that knowledge end up in the kernel source on day?

Some of this will probably need to be farmed out into files provided
by external packages, but I **hope** that they are true upstream
external packages, and not distro-specific specials, which is one of
the reasons why the current initrd/initramfs situation is
so.... unsatisfactory.  Clearly some kernel-mandated interface for
other packages to insert scripts and binaries during the early-boot
process would be a good thing; but the core initramfs functionality
should IMHO belong to the kernel.

						- Ted

Re: klibc and what's the next step?

[Michael Tokarev]

Theodore Tso wrote:
> On Tue, Jul 11, 2006 at 06:48:34AM +0200, Olaf Hering wrote:
[]
> Kinit SHOULD be merged into the kernel, and the responsibility of
> creating the initrd/initramfs image should be moved from the
> distribution into the kernel build process.  There can and should be a

Hmm.

> way for distro's to add their own "value add specials" into the
> initrd/initramfs image, but we have to take over creating the base
> initial userspace environment.  It's not just uswsusp (still not
> convinced it's a good idea, but if we're going to do it we have to
> wrest control of the initramfs away from the distro's), but finding
> and mounting iSCSI disks, LVM setup, etc.
> 
>> In earlier mails you stated that having kinit/klibc in the kernel sources
>> would make it easier to keep up with interface changes.
>> What interface changes did you have in mind, and can you name any relevant
>> interface changes that were made after 2.6.0 which would break an external
>> kinit?
> 
> When you load a SCSI driver (the one that bit me was the MPT Fusion
> driver), it no longer waits for SCSI bus probe to finish before
> returning.  So the RHEL4 initrd fails to find the root filesystem, and
> bombs out.  This change was definitely made after 2.6.0, and is an
> example of the sort of change which wouldn't have happened if kinit
> was under the kernel sources and not supplied by the distro.

How kinit is involved in loading drivers, and how it will know
that it should wait for certain things after doing something?

Nowadays, udev+modprobe are responsible for loading drivers, not kinit.
If you suggesting kinit should do that, well.. it becomes bigger at
least.

And oh, determining which modules to include into initramfs...
it's definitely NOT part of kernel BUILD process, but, so to say,
kernel package install process (note I for one often build initramfses
for OTHER machines - something most mkinitrd solutions are unable to
do - by specifying eg alternative root filesystem, or different set
of modules etc).

[]
> Some of this will probably need to be farmed out into files provided
> by external packages, but I **hope** that they are true upstream
> external packages, and not distro-specific specials, which is one of
> the reasons why the current initrd/initramfs situation is
> so.... unsatisfactory.  Clearly some kernel-mandated interface for
> other packages to insert scripts and binaries during the early-boot
> process would be a good thing; but the core initramfs functionality
> should IMHO belong to the kernel.

The main reason why the situation is so unsatisfactory (yes it definitely
is), IMHO, is that it's at least difficult to discover which stuff should
be included into early userspace (initramfs).  For example, having a list
of drivers and their modaliases, I'd like to be able to get a list of
modules in *new* kernel for those devices (based on whatever currently
running kernel sees in PCI etc).  Another examples include stuff like
already mentioned softraid, lvm and iSCSI - that things should be provided
by upstream packages (mdadm, lvmtools etc), as hooks to initramfs creation
(as, for example, Debian and Ubunto currently tries to do, for their
home-grown initramfs-tools package).

I can give another example.  Somewhere between 2.6.11 and 2.6.14,
softraid module has been renamed from md.ko to md-mod.ko.  So my
home-grown (yes, yet another :) mkinitramfs broke.  So now it
contains something like
  if included "md-mod|md" CONFIG_RAID then
     ...
and later,
  modprobe md-mod || modprobe md
for root-on-md-device.  But the same should be done in mdadm
initscript as well so.. kinit does not help here again.
Ditto for various ide-mod, ide-generic/generic renames
(including distro-specific mods), and especially for - seems
to be upcoming - ide=>pata conversion (which has quite alot
of other side effects, since all sdXX devices will move and
hdXX will gone).

But that's all beyong the point really.  I mean, there's really nothing
which requires kinit to be in kernel.  The argument above - about waiting
for mptfusion to settle - is moot just because kinit does not (currently
anyway) provide that functionality.

(And oh... I really dislike udev being in initramfs... just like the whole
udev stuff in the first place... but that's entirely different topic ;)

/mjt

Re: [klibc] klibc and what's the next step?

[Olaf Hering]

 On Tue, Jul 11, Theodore Tso wrote:

> > In earlier mails you stated that having kinit/klibc in the kernel sources
> > would make it easier to keep up with interface changes.
> > What interface changes did you have in mind, and can you name any relevant
> > interface changes that were made after 2.6.0 which would break an external
> > kinit?
> 
> When you load a SCSI driver (the one that bit me was the MPT Fusion
> driver), it no longer waits for SCSI bus probe to finish before
> returning.  So the RHEL4 initrd fails to find the root filesystem, and
> bombs out.  This change was definitely made after 2.6.0, and is an
> example of the sort of change which wouldn't have happened if kinit
> was under the kernel sources and not supplied by the distro.

Was RHEL4 designed for 2.6?

Re: [klibc] klibc and what's the next step?

[Adrian Bunk]

On Tue, Jul 11, 2006 at 05:13:47PM +0200, Olaf Hering wrote:
>  On Tue, Jul 11, Theodore Tso wrote:
> 
> > > In earlier mails you stated that having kinit/klibc in the kernel sources
> > > would make it easier to keep up with interface changes.
> > > What interface changes did you have in mind, and can you name any relevant
> > > interface changes that were made after 2.6.0 which would break an external
> > > kinit?
> > 
> > When you load a SCSI driver (the one that bit me was the MPT Fusion
> > driver), it no longer waits for SCSI bus probe to finish before
> > returning.  So the RHEL4 initrd fails to find the root filesystem, and
> > bombs out.  This change was definitely made after 2.6.0, and is an
> > example of the sort of change which wouldn't have happened if kinit
> > was under the kernel sources and not supplied by the distro.
> 
> Was RHEL4 designed for 2.6?

Yes (it uses 2.6.9).

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [klibc] klibc and what's the next step?

[Olaf Hering]

 On Tue, Jul 11, Adrian Bunk wrote:

> On Tue, Jul 11, 2006 at 05:13:47PM +0200, Olaf Hering wrote:
> >  On Tue, Jul 11, Theodore Tso wrote:
> > 
> > > > In earlier mails you stated that having kinit/klibc in the kernel sources
> > > > would make it easier to keep up with interface changes.
> > > > What interface changes did you have in mind, and can you name any relevant
> > > > interface changes that were made after 2.6.0 which would break an external
> > > > kinit?
> > > 
> > > When you load a SCSI driver (the one that bit me was the MPT Fusion
> > > driver), it no longer waits for SCSI bus probe to finish before
> > > returning.  So the RHEL4 initrd fails to find the root filesystem, and
> > > bombs out.  This change was definitely made after 2.6.0, and is an
> > > example of the sort of change which wouldn't have happened if kinit
> > > was under the kernel sources and not supplied by the distro.
> > 
> > Was RHEL4 designed for 2.6?
> 
> Yes (it uses 2.6.9).

Ok, I suspect RHEL9 doesnt work with root on usb-storage or sbp2 either?
If so, not a big deal. in-kernel kinit wouldnt work any better if it lacks
support for async probing. But I dont know the details about the mpt failure.

Re: [klibc] klibc and what's the next step?

[Alan Cox]

Ar Maw, 2006-07-11 am 17:13 +0200, ysgrifennodd Olaf Hering:
>  On Tue, Jul 11, Theodore Tso wrote:
> 
> Was RHEL4 designed for 2.6?

RHEL4 is 2.6.9 based, with a lot of bugs then fixed.

Re: [klibc] klibc and what's the next step?

[Rene Herman]

Olaf Hering wrote:

 > I do not want to see kinit merged.

For what it's worth -- I as a user am violently opposed to kinit not 
being in the source tree, if _anything_ is merged.

Given that's it's intended to take over kernel functionality, kinit 
would be a tightly coupled piece of software and a number of problems 
2.6 has seen are with tightly coupled software (udev, alsa-lib) getting 
out of sync with the kernel. I believe someone from redhat complained 
about it last. Adding another tightly coupled external app to the mix is 
just going to worsen the situation. Please don't do that.

And yes, then there's the issue of keeping distributions all using the 
same thing which I saw someone else remark on as well. If klibc/kinit is 
the way forward, please make sure kinit is in the kernel source tree.

Rene.

Re: [klibc] klibc and what's the next step?

[David Lang]

On Tue, 11 Jul 2006, Rene Herman wrote:

> Olaf Hering wrote:
>
>> I do not want to see kinit merged.
>
> For what it's worth -- I as a user am violently opposed to kinit not being in 
> the source tree, if _anything_ is merged.
>
> Given that's it's intended to take over kernel functionality, kinit would be 
> a tightly coupled piece of software and a number of problems 2.6 has seen are 
> with tightly coupled software (udev, alsa-lib) getting out of sync with the 
> kernel. I believe someone from redhat complained about it last. Adding 
> another tightly coupled external app to the mix is just going to worsen the 
> situation. Please don't do that.
>
> And yes, then there's the issue of keeping distributions all using the same 
> thing which I saw someone else remark on as well. If klibc/kinit is the way 
> forward, please make sure kinit is in the kernel source tree.

I first started useing linux in the 0.88 days, and have been useing it heavily 
for the last 10 years (with custom kernels throughout, first due to the need, 
later for other reasons). During all of that time I have avoided useing 
initramfs or initrd on the several hundred machines I have managed over that 
time.

I personally don't like the idea of booting stuff out of the kernel into a 
userspace 'thing' that needs to be built and maintained in addition to the 
kernel (for that matter I have almost entirely avoided the use of modules as 
well).

however, if kinit/klibc are included with the kernel and a make && make install 
(or similar) will end up createing a blob that will boot, I won't care if the 
blob is entirely kernel or is kernel+initrd with some functionality in 
userspace.

Ted makes a good point that distros will want to further tweak the boot process 
and that the right way is to give them hooks to add their custom stuff. we don't 
want every distro to throw out the thing that the kernel compiles to put in 
their own.

David Lang

Re: klibc and what's the next step?

[Pavel Machek]

Hi!
> > 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.
> 
> I do not want to see kinit merged.
> It (the merge into linux-2.6.XY) doesnt solve any real problem in the long term.
> Instead, make a kinit distribution. Let it install itself into an obvious
> location on the development box (/usr/lib/kinit/* or whatever), remove all
> code behind prepare_namespace() and put a disclaimer into the Linux 2.6.XY
> releasenote stating where to grab and build a kinit binary:
> make && sudo make install
> It can even provide its own CONFIG_INITRAMFS_SOURCE file, so that would
> be the only required change to the used .config.
> 
> The rationale is that there are essentially 2 kind of consumers:
> 
> One is the kind that builds static kernels and uses no initrd of any kind.
> For those people, the code and interfaces behind prepare_namespace() has
> not changed in a long time.
> They will install that kinit binary once and it will continue to work with

That is the problem... kernel did not use to depend on kinit, and this
is considered stable series. So if kernel wants to depend on kinit, it
needs to ship it itself.
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [klibc 00/43] klibc as a historyless patchset

[Milton Miller]

As a historyless patchset, this gets the merge all wrong.

If the reason to put this in tree is to keep the kernel just working
then there is a great big hole of 40 patches for git bisect to find.

On Jun 25, 2006, at 8:10 PM, H. Peter Anvin wrote:

> changes to the
> main kernel code taken straight from the git history (as it is rather
> few patches), and additions, grouped by rough divisions.

If they are in the wrong order then that is not good enough.
The patch names and descriptions are wrong because the are from
the klibc git tree.

> 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
This looks to be 04-powerpc-set-klibc-arch

> 05-need-to-export-ranlib-from-the-top-makefile.patch
> 06-re-create-root-dev-too-many-architectures-need-it-.patch
Make the "move stuff i need" and make it first

> 07-eliminate-unnecessary-whitespace-delta-vs-linus-tree.patch

I didn't look, this corrects whitespace before patching? ok early

> 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
What does this do?  No Help, no description, and doesn't trigger
anything in this patch.

> 12-enable-config-klibc-zlib-now-required-to-build-kinit.patch
What does this do?  No Help, no description, and doesn't do anything
in the curreent 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
	where is x86 and x86_64 ?
	oh you deleted and did not put that back

> 18-klibc-inkernel-merge-s390s390x-4.patch
	This patchname is meaningless.
	The description in the patch is worse.
	It looks like it should be 18-s390-set-klibcarch

Hmm... i didn't find the patch removig usr/Makefile, just adding
usr/Kbuild.   usr/Kbuild should be a diff against the existing
usr/Makefile, whcih can be renamed.

As a guess here would be my order and renames:

07-eliminate-unnecessary-whitespace-delta-vs-linus-tree.patch
	This should be making the delta the right way
06-re-create-root-dev-too-many-architectures-need-it-.patch
	nee do-mounts-is-goiing-move-root-dev
	I think initramfs.c might be a temporary home
16-sparc64-transmit-arch-specific-options-to-kinit-via-arch-cmd.patch
17-sparc32-transfer-arch-specific-options-to-arch-cmd.patch
	keep the global varables, make the arch_initcall global, and keep
	the code in x86 and x86-64 setup.c
	"export-arch-set-ramdiskflags-to-early-userspace"
08-klibc-default-initramfs-content-stored-in-usrinitramfs-default.patch

05-need-to-export-ranlib-from-the-top-makefile.patch
15-default-klibcarch--arch.patch
04-support-klibcarch-being-different-from-the-main-arch.patch
	powerpc-set-klibcarch
18-klibc-inkernel-merge-s390s390x-4.patch
	s390-set-klibcarch
13-uml-the-klibc-architecture-is-the-underlying-architecture.patch
xx-rename-usr-Makefile-usr-Kbuild	

19-klibc-basic-build-infrastructure.patch
09-kbuild-support-single-targets-for-klibc-and-klibc-programs.patch

01-add-klibckinit-to-maintainers-file.patch
20-37,39
11-enable-klibc-errlist.patch
12-enable-config-klibc-zlib-now-required-to-build-kinit.patch
40,38,41-43

02-remove-root-mounting-code-from-the-kernel-.patch
	minus the x86 setup stuff
03-remove-parts-moved-to-kinit.patch
	remove-power-disk.c-resume-parts-moved ...
10-remove-prototype-for-name-to-dev-t.patch
14-remove-in-kernel-nfsroot-code.patch

Re: [klibc 00/43] klibc as a historyless patchset

[H. Peter Anvin]

Milton Miller wrote:
> As a historyless patchset, this gets the merge all wrong.
> 
> If the reason to put this in tree is to keep the kernel just working
> then there is a great big hole of 40 patches for git bisect to find.
> 
> On Jun 25, 2006, at 8:10 PM, H. Peter Anvin wrote:
> 
>> changes to the
>> main kernel code taken straight from the git history (as it is rather
>> few patches), and additions, grouped by rough divisions.
> 
> If they are in the wrong order then that is not good enough.
> The patch names and descriptions are wrong because the are from
> the klibc git tree.
> 
>> 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
> This looks to be 04-powerpc-set-klibc-arch
> 
>> 05-need-to-export-ranlib-from-the-top-makefile.patch
>> 06-re-create-root-dev-too-many-architectures-need-it-.patch
> Make the "move stuff i need" and make it first
> 
>> 07-eliminate-unnecessary-whitespace-delta-vs-linus-tree.patch
> 
> I didn't look, this corrects whitespace before patching? ok early
> 
>> 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
> What does this do?  No Help, no description, and doesn't trigger
> anything in this patch.
> 
>> 12-enable-config-klibc-zlib-now-required-to-build-kinit.patch
> What does this do?  No Help, no description, and doesn't do anything
> in the curreent patch

usr/klibc/Kbuild:

libc-$(CONFIG_KLIBC_ZLIB)    += \
         zlib/adler32.o zlib/compress.o zlib/crc32.o zlib/gzio.o \
         zlib/uncompr.o zlib/deflate.o zlib/trees.o zlib/zutil.o \
         zlib/inflate.o zlib/infback.o zlib/inftrees.o zlib/inffast.o

At this point, this is required by kinit, which is why it is not 
possible to disable.

>> 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
>     where is x86 and x86_64 ?
>     oh you deleted and did not put that back

That's correct; I went around and talked to both x86 and sparc people, 
and the x86 people uniformly announced rdev support as being obsolete; 
the sparc people, however, continue to rely on being able to get data 
from openprom.


>> 18-klibc-inkernel-merge-s390s390x-4.patch
>     This patchname is meaningless.
>     The description in the patch is worse.
>     It looks like it should be 18-s390-set-klibcarch
> 
> Hmm... i didn't find the patch removig usr/Makefile, just adding
> usr/Kbuild.   usr/Kbuild should be a diff against the existing
> usr/Makefile, whcih can be renamed.

True.  Git could work this out.

I have been reluctant to spend too much time on packaging, because I've 
still had the issue of continue to maintain the out-of-tree distribution 
(which includes usr/Kbuild) indefinitely.  I need to spend some more 
time scripting.

	-hpa

Re: [klibc 00/43] klibc as a historyless patchset

[Milton Miller]

On Jun 27, 2006, at 2:12 PM, H. Peter Anvin wrote:

> Milton Miller wrote:
>>> 12-enable-config-klibc-zlib-now-required-to-build-kinit.patch
>> What does this do?  No Help, no description, and doesn't do anything
>> in the curreent patch
>
> usr/klibc/Kbuild:
>
> libc-$(CONFIG_KLIBC_ZLIB)    += \
>         zlib/adler32.o zlib/compress.o zlib/crc32.o zlib/gzio.o \
>         zlib/uncompr.o zlib/deflate.o zlib/trees.o zlib/zutil.o \
>         zlib/inflate.o zlib/infback.o zlib/inftrees.o zlib/inffast.o
>
> At this point, this is required by kinit, which is why it is not 
> possible to disable.

But that file is in 19-, so at this point in the sequence it still
does nothing, and has no help.

Oh, and the files don't exist until 39, so the build breaks from
19 to 39.  If you don't want to split the makefile, put that after
39.

>
>>> 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
>>     where is x86 and x86_64 ?
>>     oh you deleted and did not put that back
>
> That's correct; I went around and talked to both x86 and sparc people, 
> and the x86 people uniformly announced rdev support as being obsolete; 
> the sparc people, however, continue to rely on being able to get data 
> from openprom.

Then it should be a seprate patch, and go though feature-removal or
not on its own merits.

>>> 18-klibc-inkernel-merge-s390s390x-4.patch
>>     This patchname is meaningless.
>>     The description in the patch is worse.
>>     It looks like it should be 18-s390-set-klibcarch
>> Hmm... i didn't find the patch removig usr/Makefile, just adding
>> usr/Kbuild.   usr/Kbuild should be a diff against the existing
>> usr/Makefile, whcih can be renamed.
>
> True.  Git could work this out.
>
> I have been reluctant to spend too much time on packaging, because 
> I've still had the issue of continue to maintain the out-of-tree 
> distribution (which includes usr/Kbuild) indefinitely.  I need to 
> spend some more time scripting.

Because the out-of-tree is trying to be buildable in-tree?  Or because
the out-of-tree and in-tree both need to build the same tools?

milton