Re: [BK PATCH] klibc for 2.5.64 - try 2

["H. Peter Anvin" <hpa@zytor.com>]

Eric W. Biederman wrote:
> 
> I don't recall anything about the contents of initramfs being specified.
> What I was expecting to see was a good set of general purpose policies
> being included in the default kernel binary.  And just replacing
> /sbin/kinit if I wanted something dramatically different.  And that is
> what I remember Al Viro working on.
> 
> So I don't think building a very specific /sbin/kinit that
> only does what the kernel currently does right now is a problem.
> 

It does matter how the initramfs is built.  /bin/sh may or may not be 
necessary (but klibc /bin/sh is just over 50K on i386 -- 55K static, 
whereas glibcx /bin/bash is 600K plus the glibc binary), but one of the 
goals with initramfs is to at least make it feasible to give someone who 
comes and asks "I have a weird-ass site with 20000 hosts and we need X" 
a better answer then "well, go hack the kernel."

/sbin/kinit is a feasible way to do it, but it's important to keep the 
flexibility option open.

> So I think we should have a very small very specific /sbin/kinit
> that does in user space what the kernel does in kernel space right
> now.  Regardless of klibc the default /sbin/kinit should be gpl'd
> because we are moving code from code from the kernel into it, and we
> shouldn't need to double check the licenses to move code from the
> kernel into it.

Agreed (although it's harder than you think to move code from the kernel 
into it -- frequently it has been easier to just write code from 
scratch; it's cleaner that way, too.)

The reason I wanted to use BSD/MIT license only really applies to the 
library.

	-hpa