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

H. Peter Anvin
2003-03-08T20:58:16Z

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