Re: udev is too slow creating devices

[Ihar 'Philips' Filipau]

> The fact that a static /dev keeps these race conditions from showing up
> as often as they really are there is no reason to keep trying to rely on
> old, undefined behaviour :)

  [ I'm late to discussion, and do not have much time at all.
  Just observation from aside by driver writer and OS builder. ]

  You really do not solve problem - problem as I see it - but just move 
it around.

  When I did first release of device driver for some obscure device, I 
used to wait in init script for "touch /dev/whatever" to be Ok. My 
device was ok with dumb open()/close() sequence.

  What I was really missing - is a way to tell user space that not only 
driver loaded Ok, but that device was found, diagnosed and upped Ok. 
Diagnostics was taking time - that's why I tryed to do it async. While 
device does some inernal spinning, I can load up other drivers.

  I haven't found any reasonable solution. module_init() is locking 
everything - I cannot load any other module, while one module is 
loading. But from user space point of view this is the only way to 
return error from device driver.

  IOW, mapping my experience to this discussion, we need to have a way 
for user space to wait for discover process to end. After all user space 
knows better than enyone in kernel what to expect from loaded driver.

  We are not talking about hot-plug and preloading of modules. We are 
talking more about the case where system cannot go on without requested 
device & its device node. We need a way for modprobe to be able to wait 
for driver initialization phases (we do not have them - make it sense to 
have them?): driver initialization, device discovery, device 
initialization, device node ready. So then user space will be able to 
wait for driver to reach any of given phases. If init script needs 
/dev/sda1 and after all phases completed Ok we failed to locate it - it 
can mean only one thing - /dev/sda1 is not here. Since modprobe will 
wait - it will mean that we will be able to return error, if any. IMHO 
that what need to be implemented. Polling is crappy solution: we do not 
need to poll for something we can reliably find out.

  We have all info in kernel in drivers - we need a way to give it back 
to user space for both play nice with each other.

  My 0.02 Euro.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/