I leave the project

Ian Molton spyro at f2s.com
Thu Jul 8 13:48:30 PDT 2004

On Thu, 8 Jul 2004 19:47:48 +0100
Matthew Burgess <matthew at linuxfromscratch.org> wrote:

> This is a pretty damn big problem when it happens (although from what
> I understand it's a fairly uncommon situation). 

Actually its quite common. I've hit it twice here.

one time on my canon lide20 scanner which would appear on the USB bus
but not be available until later, which was solved by using the proper
udev methods for the purpose, and once on my new NFS/LVM2 box, which
takes long enough creating the LVM2 device nodes that a *2 second* delay
was not adequate.

This really requires a paradigm shift, and this time, its in a good way.

You see, my naieve devfs bootscripts would do this:

modprobe usb_blah
chmod <nicer perms> usb_scanner_node

This was, of course, fine under devfs as once modprobe returned, there
was a garauntee that ALL the device nodes were present.

Under udev, the modprobe succeeds, having created zero or more of the
devices. unfortunately, by the time my script reached the chmod, the USB
devices were still enumerating and thus I never had the permissions set
right. (this is a bad problem for a newbie who would not know that chmod
worked fine, just didnt have anything to chmod)

The solution (or rather, the quick fix) was to make the script wait a
second before running chmod.

*A* correct solution is to make all scripts wait for the resources they
need before proceeding (similar idea to the above, althoguh without


One complaint levelled at linux fairly often is that bootup is slow.
Well, perhaps it is. If could certainly be faster.
Take my example above, for example... in my 'fixed' script, the script
takes *at least* a second to run, despite the fact that it probably does
under a tenth of a second of actual work (on top of that second).

What would be nice would be if the script didnt wait. just did the
modprobe and exited. one nice, fast, sub-tenth-of-a-second script. TEN
TIMES faster.

the neat bit is to use udev / hotplug to run the chmod command *only
once* the device node is actually available.

The catch is probably obvious - what if the next script uses the device
node that should have been chmoded but possibly doesnt exist yet?

well, theres two solutions - either we go for fully hierarchical
asynchronous, event driven bootscripts (way cool, but perhaps an LFS 7.0
thing) or we go for bootscripts that at least test for, wait for, and
perhaps time out waiting for, the resources they need.

I think this sums up the entire situation (please feel free to add

Suffice to say, the way bootscripts work now is NOT adequate in a
dynamic devices / event driven hotplug world, and we need to fix this
*BEFORE* LFS 7.0 unstable gets branched.

More information about the lfs-dev mailing list