Messages in this thread | | | Subject | Re: [BK PATCH] klibc for 2.5.64 - try 2 | From | (Eric W. Biederman) | Date | 07 Mar 2003 19:06:42 -0700 |
| |
Russell King <rmk@arm.linux.org.uk> writes:
> On Fri, Mar 07, 2003 at 03:05:32PM -0800, Linus Torvalds wrote: > > However, I also have to say that klibc is pretty late in the game, and as > > long as it doesn't add any direct value to the kernel build the whole > > thing ends up being pretty moot right now. It might be different if we > > actually had code that needed it (ie ACPI in user space or whatever). > > Alan was recently trying to convince people that ipconfig.c should be > deleted from the 2.5 kernel today. That was until I pointed out that > people do download kernels via xmodem to embedded boards (because that's > what the boot loader supports) and they want to be able to use root-NFS. > I think Alan is reasonably happy for it to stay now, although I haven't > had any hard positive confirmation of that fact.
There is another reason ipconfig.c should die. Except in simple setups it does the wrong thing. I have had it get a DHCP reply off of the wrong NIC. Having the wrong policy in the kernel is a problem. Especially when people think about fixing it...
> As long as we don't have equivalent functionality present which replaces > ipconfig.c and nfsroot.c without adding stupidly sized initrd images to > the kernel, I will continue to resist the removal of both of these > features.
I agree ipconfig.c works well for development. Last time I played with something like this it should not be hard to get the entire initrd binary down to 30K-40K. I think you can probably do it in 16K but...
As far as equivalent functionality there is already a dhcp client and a mount client in busybox. So in the worst case someone it will take just a bit of glue to put these things together.
> klibc provided a way, but if that isn't going to be merged and this stuff > made to work for 2.6, then I think we must keep ipconfig.c and > nfsroot.c.
Either klibc or alternative user space implementation. There is no reason that magic has to happen in the kernel. The only thing has to be implemented is a way to smush a kernel and an initrd together.
Eric - 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/
| |