On Thursday, September 15, 2011 10:57:27 AM Canek Peláez Valdés wrote: <snipped to keep only the email from Canek>
> Let me throw my own guess of how they came out with the corrent > proposed solution. I repeat: is my own guess: I am not the one calling > the shots, so maybe I'm completely wrong. Ok and I do actually think you are correct with your guess as to why the developer came up with his solution. > As many of you guys said, there are ways of solving the problem > without requiring an initramfs. Note that if you decide to use an > initramfs, every use case works: You can have a practically empty /, > throw everything in /usr, and have /usr in another partition, maybe > even an encrypted remote NFS share. With an initramfs you can have a > separate /var, you can even have a separated /etc, mounted even by NFS > too. You can do pretty much whatever you want, because you have a full > userspace *the moment you boot*. Bluetooth, network, LVM, > crypto-filesystems: Everything is available from the instant zero. For these specific custom environments, yes, I agree. An initramfs is mandatory. > From that perspective, the problem then is trying to support the > initramfs-less setups. Putting myself in the shoes of the developers, > the smart solution is to simply force an initramfs. KISS is to force > an initramfs, because it solves everything. The Gentoo devs are > working in a minimal initramfs that works for most "normal" usecases. > Everything else will be handled by dracut or genkernel. Initramfs is already supported. so is initramfs-less. > An initramfs is not an initrd. And is not a binary blob coming who > knows from where; with dracut, your initramfs is simply a subset of > your normal installation, and can be as simple (just mount /usr) or as > complicated (LVM+crypto+network+NFS+whatever) as you want. I haven't looked at dracut yet, but as far as I understand, it does create an initramfs with the script(s), libraries and binaries needed to start whatever is needed to get to the stage where udev is happy. > Of course you can solve it differently, for example splitting udev as > Joost proposes. But then is more code to maintain, and the number of > possible setups is suddenly the double it was before. It. Is. Not. > KISS. Depends on your definition of Simple. > It's a lot like the CUPS/lprng situation we discussed before. CUPS can > do anything that lprng does, so it makes no sense to keep support for > lprng. It's the same: with an initramfs you will be able to do > anything, so it will make no sense to keep supporting initramfs-less > systems. The situation with Cups and lprng is different. If either of these fail, the system will still boot and then you can spend the time to fix the problem. If this change continues, an initramfs failure, will mean the system will not boot correctly. And when all the tools needed to fix the system are moved to /usr, what options are there to actually analyse and solve the problem? In my opinion, the simplest solution will be to make the tool(s) do what they're supposed to do. udev should, in my opinion, create the devices in userspace. That it also allows for programs/scripts to be executed when a device is created is a nice thing to have. Unfortunately, this leads to chicken-and-egg style problems when the scripts are on a filesystem that hasn't been mounted yet. There are 3 solutions for this: 1) The easy way out: the whole user-space must be available before udev 2) udev actually includes correct error-handling for this and retries 3) udev splits this into 2 seperate tools Option 1 is what is currenty proposed and what you appear to be in favour off. Except, what is the point of having "udev" when the entire user-space already exists before it starts? You yourself said it's nice to have everything already available from the beginning. But isn't the problem that udev can't start bluetoothd because /usr/bin/bluetoothd can't be found when /usr doesn't exist yet? How would udev handle a situation where I have /usr on my mobile phone which shares the filesystem over bluetooth? Option 2 has been suggested and rejected. And I happen to agree with this as it would make udev, a vital part of the system, bigger and will increase the chances of problems/bugs. Option 3, which I have proposed, would actually make the first part smaller and simpler. The action-handling can then be run at a later stage, when /usr is available and could then easier implement a retry-queue. With this being a seperate tool, not needed for the /dev-tree creation, failure on this should not lead to an unusable system. -- Joost
