Messages in this thread | | | Date | Tue, 11 Jul 2006 12:38:28 -0700 | From | "H. Peter Anvin" <> | Subject | Re: [klibc] klibc and what's the next step? |
| |
Linus Torvalds wrote: > > On Tue, 11 Jul 2006, Olaf Hering wrote: >>> It's a proposal, and I personally think it makes sense. If done, it is >>> obviously very important that it doesn't change the overall operation of >>> the system. >> I think you can have that today, parted uses BLKPG to add and remoe >> things. No idea what the benefit would be, but thats not relavant for >> kinit or no kinit. > > The notion that the kernel itself should do no partition parsing at all > was advocated by Andries Brouwer. I violently disagree. Anything that the > lack of which makes a normal system basically unusable should go into the > kernel. >
Does that mean "in kernel space", "in the kernel distribution" or "in memory completely under the control by the kernel?" That is really what this is about.
There could be a klibc-build binary in rootfs, build at the time the kernel was built, that can be invoked by the kernel in parallel with /sbin/hotplug.
> Yes, the kernel rules are heuristics, but so would inevitably any > user-level rules be too, so I don't want to move partition detection to > initrd or similar.
The whole point of putting klibc in the kernel tree is so we can do this kind of stuff without breaking the stock kernel build as a self-contained entity. Without that objective, Olaf is right that it is not necessary.
-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/
| |