Messages in this thread | | | From | Kay Sievers <> | Date | Thu, 15 Dec 2011 19:11:46 +0100 | Subject | Re: Subject:[PATCH 1:1] boot paramer "root=" gets a list of devices |
| |
On Thu, Dec 15, 2011 at 16:22, H. Peter Anvin <hpa@zytor.com> wrote: > On 12/15/2011 07:19 AM, Raz Ben Yehuda wrote: >>> >>> To which point I have to ask, once again, at which point we stop putting >>> this stuff in the kernel to "bypass the need for initramfs"... >> >> because there are times where we cannot use initramfs. is this a problem >> with way i phrase or with with the whole idea ?
I don't see why stuff needs to search a hard-coded list of stuff. That logic seems pretty much backwards to me. You either use the GPT stuff that allows to flag the right partition to boot from a set of partitions, or you go as far as make the kernel parse the filesystem UUID of partitions. But hard-coding search lists on the commandline, I really don't understand.
> There are problems with the whole concept of "cannot use initramfs". We > allow the initramfs to be integrated with the kernel image for a reason, for > example. > > I'm obviously ranting on this in part to make people think about what they > are doing, and partly to remind that the more complex the in-kernel > root-mounting code get, the more it might be worth reconsidering klibc in > the kernel build tree.
I think the whole picture of klibc is confusing and I very much don't want to see that busybox-style hacking in the kernel sources.
Distros can not afford to support 2 libcs at bootup, and the distro initramfss gets so complicated today, that a klibc-only solution does not really work. So we end up with 2 libcs in the same initramfs image, which makes zero sense. Leave alone the fact, that the klibc tools duplicate all the stuff that already works in the real root in a completely different and mostly insufficient and sometimes scary way.
The thing is, if the setup is that simple that klibc works, it is very likely that the current in-kernel mount code is simple, well tested and sufficient enough. If a distro-style intramfs is needed, klibc is not usable (see above). The big distros will very unlikely ever pick it up. The the remaining use-cases will stay a niche, that, I think, does not justify the kernel inclusion of klibc.
If the whole klibc approach, if not entirely rethought, I doubt it will ever go anywhere. In my opinion, with all what I've seen the last years, we either work on a full libc in the kernel tree, that can be used by normal userspace too, or we leave the tiny stuff to busybox and one of the existing tiny libcs.
Kay -- 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/
| |