klibc - Oct 2004 - [Fwd: Re: kinit]

Gah, I meant to send this to the list ...

-------- Original Message --------
Subject: Re: [klibc] kinit
Date: Tue, 26 Oct 2004 21:05:47 +0200
From: Daniel Thaler <daniel@dthaler.de>
To: H. Peter Anvin <hpa@zytor.com>
References: <417DF200.5070105@zytor.com>

H. Peter Anvin wrote:
> I think the main bit of the puzzle that's missing for klibc integration
> at this point, other than the kbuild bits, is a kinit that's a true 
> replacement for prepare_namespace() and everything south of it in 
> init/main.c.  This means that it should be able to replace all that code 
> and any code that's removed from it, totalling about 6000 lines of 
> kernel code.
> 
> The kinit that's currently in the klibc tree is missing quite a bit of 
> functionality, such as proper handling of initrd (which the kernel dumps 
> as a file in the rootfs.)
> 
> So, it's quite a bit of code, but it's not particularly difficult
code.
>  It's just a mere matter of (somewhat intelligent) typing :)
> 
> I'm hoping to have a fully backwards-compatible kinit in a few weeks.
There is also no good way of finding out what was passed as root= on the
kernel command line. All other values are available to init as
environment variables, but root=bla is not.
Surely that is not intentional?

Currently I'm mounting proc, reading cmdline and unmounting it again.
That seems kind of ... inelegant.

Daniel Thaler

Daniel Thaler wrote:
> 
> There is also no good way of finding out what was passed as root= on the
> kernel command line. All other values are available to init as
> environment variables, but root=bla is not.
> Surely that is not intentional?
> 
That's incorrect, as far as I know; only parameters not understood by the 
kernel are exported into the environment.  Blah.
> Currently I'm mounting proc, reading cmdline and unmounting it again.
> That seems kind of ... inelegant.
It works, though, and has worked consistently for the last 9 years.

	-hpa