Zac Medico wrote: > On 04/11/2012 07:13 AM, Steven J Long wrote: >> Zac Medico wrote: >> >>> On 04/10/2012 07:28 PM, Steven J Long wrote: >>>> I suppose you could script that, but again, it just seems like a lot of >>>> bother to implement an "alternative" that doesn't actually gain >>>> anything over the traditional setup (plus making sure that partitions >>>> are mounted before udev starts.) >>> >>> At least in the case of udev, we gain from not having to maintain a >>> fork. >>> >> "Making sure that partitions are mounted before udev starts" is a lot >> less of an ask than setting up an initramfs, and changing the way we've >> worked for years. It's what you proposed: an earlymounts init script, or >> patches to Gentoo initscripts to do the same thing. Neither involves any >> patches to udev proper, so no fork needs to be maintained. > > It's not generally practical to do mounts prior to starting udev, since > udev can may be needed to create the device nodes that are needed for > for performing the mounts. Maybe a subset of users can get away with it > by relying on devtmpfs and having the drivers built into the kernel, but > that won't work for everyone.
OFC not: the generic method is to use an initramfs. But many of us *do* have the drivers for the device nodes built-in: it's part of the initial setup in configuring a kernel (manually) and getting it to boot. I can't speak for others, but that level of control is why I, for one, chose Gentoo in the first place. I don't see the need for a source-based distro to include everything and the kitchen-sink: that principle applies via USE- flags, and it applies via having a lean kernel that doesn't contain modules for 15 PCI controllers my motherboard doesn't have, and never could have. The Council has voted that Gentoo continue to support that subset, without an initramfs. I'm glad you accept that we don't need to fork udev to do this, though, so there isn't that maintenance issue, beyond Gentoo initscripts (and if there should be in future, a Council member has already committed to overseeing that work.) -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
