[klibc] Early-userspace development

[H. Peter Anvin]

Kevin P. Fleming wrote:
> H. Peter Anvin wrote:
> 
>>> - integrating the configuration and building of "standard" packages into
>>> the kernel build process so they can be part of the initramfs (packages
>>> like mdadm, lvm2, util-linux, busybox, etc.)
>>
>> I think this is not desirable; a lot of these tools are either too big
>> or requires too much library support.  They definitely shouldn't be part
>> of the kernel built.
> 
> I was thinking along the lines of userspace replacement of partition
> discovery, md autostart, etc. Are you suggesting that using the existing
> tools for those tasks (albeit modified to work in the klibc/initramfs
> environment) is not a goal any longer?
> 

Most of the tools you're listed are heavily bloated in order to work as
user tools.  This was never a desig goal of klibc/early userspace;
although you may be able to compile them against klibc (although hardly
busybox... it uses library functions like crazy) it is better to see if
we can perhaps share code or create more minimal implementations.
>>
>>> - modifying the existing kernel start-up code to either remove, or just
>>> disable, code that is being moved into userspace (partition reading, md
>>> startup, etc.)
>>
>> The first part is to actually create (small!) userspace equivalents.
>> Everyone seems to agree that the first thing to go should be
>> ipconfig/nfsroot.  We have some code for that already in the klibc
>> tarball (as opposed to Greg's integrated patch), but it needs to be
>> turned into a working binary which can use the ip= and nfsroot=
>> parameters passed to existing kernels to configure IP and mount the
>> nfsroot.
>>
>> It needs to be a "drop in" replacement before we can remove it from the
>> kernel.
> 
> That's certainly understandable. Unfortunately I haven't got the systems
> here to be able to test anything like that, so I can't really work on
> that side of things.

Bummer :(  That would have been useful.

>> This is definitely the #1 priority.
>  
> In spite of that, is there any reason not to proceed with working on
> things like /sbin/hotplug-based partition discovery (my first goal at
> this point)?

Not at all, go for it.  You may want to structure code so that it can be
compiled small with klibc (note you probably need to do O_LARGEFILE and
llseek() explicitly in klibc) or compiled against glibc for the full
userspace environment.

	-hpa