On Friday, March 06 2009, Victor Lowther said: > On Fri, 2009-03-06 at 15:39 -0500, Bill Nottingham wrote: > > Victor Lowther (victor.lowther@xxxxxxxxx) said: > > > > > http://git.surfsite.org/dracut.git > > > > > git://surfsite.org/pub/git/dracut.git > > > > > > > > Wasn't the entire point to make the initramfs generic? > > > > > > No, to make the initramfs generator generic. A subtle but important > > > distinction. > > > > Nope. The plan was (quoting earlier mails to the list, from the > > creators...): > > > > ... > > [I]nstead of scripts hard-coded to do various things, we depend on > > udev to create device nodes for us and then when we have the > > rootfs's device node, we mount and carry on > > We do this just fine. Udev is the engine that drives everything in a > dracut-generated initramfs -- the additional scripts are there in the > initramfs to handle things that udev does not handle gracefully. If you > see some functionality currently handles in a script that udev could > handle better, please implement it. The problem is the direction seems to be "hm, udev can't do this, guess we'll make a hook" rather than "fix udev and the underlying tools". Yes, it means it's harder. And yes it means that distros have to get updates for everything to work. But otherwise, we remain in the past with piles of scripts doing most things. [snip] > > - handle various device types through shell snippets, not udev > > (raid, crypt, etc.) > > We use shell snippets where udev is not flexible enough or where there > are other limitations we have to work around. The entire process on the > initramfs is still udev driven, however. Honestly, I really wouldn't say that "the entire process is still udev driven". The rootfs *NEEDS* to be being mounted from a udev rule -- otherwise, we're not being driven by events. We're having events to do some things and scripts for others/more Jeremy -- To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
