Messages in this thread | | | Date | Sat, 08 Mar 2003 13:08:18 -0800 | From | "H. Peter Anvin" <> | Subject | Re: [BK PATCH] klibc for 2.5.64 - try 2 |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |