[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