Bryan Kadzban wrote: > Bruce Dubbs wrote: >> 5. Updated udev_retry to handle the /run directory for events that >> occur between starting udevd and mounting / read/write. > > Good, it's using the same thing the rule_generator.functions file is > using (see choose_rules_file): "udevadm info --run". > > Though it looks a little strange to be searching $PATH for udevadm > there, yet be specifying /sbin/udevadm through the rest of the script. > Consistency might be good.
Good point. I added the path. > It actually probably makes sense to pull this out into its own change? > We'll need it with newer udev versions no matter what happens to the > rest (and maybe current udev versions; I'm not sure). Up to you though. I'm not sure what you mean. >> Actually this script may need to be reviewed in more detail, because >> /run is always mounted r/w before udevd is started. > > Hmm, not sure this why this matters? :-) > > /run is mounted read-write, yes -- that's the only reason these rules > files would have been successfully written there. This whole setup is > here to catch the case where the rules are generated before the *root* > FS is mounted read-write (so /etc/udev/rules.d is not writable). And > AFAIK the root FS can't be mounted read-write before udevadm trigger > happens, unless I'm missing something. (Because the root FS's device > node is not present.) One purpose of the /run directory is to allow (eventually) / to be able to remain read only. Things like mtab, blkid.tab, etc will migrate to /run. I'd think dynamic udev rules would move there too. I don't know why any rules would have to be delayed and that would mean that udev_retry would be unnecessary. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
