Re: debian and UDEV
Gabor Gombas <gombasg@sztaki.hu> writes:
> On Wed, May 17, 2006 at 10:44:21AM +0200, Goswin von Brederlow wrote:
>
>> Which is still stupid not to have in the kernel API as feedback from
>> the event manager and have insmod optionaly block.
>
> For that to work you should make device discovery synchronous everywhere
> in the kernel. That would be a big change, and then people would start
> complaining that the boot process suddenly takes 10-20 minutes instead
> of 10-20 seconds (because the kernel now has to wait for time-out for
> non-existing devices which you never noticed before thanks to the
> asynchronous discovery).
What timeout? With feedback you would know exactly when it is done and
wouldn't have to poll.
If you mean the timeout of the actual device drivers themself then
that is what pre udev kernels have always done and I think kernels
still do anway. If you load a scsi driver module it will block to scan
the scsi bus, generate the hotplug events and only then go
asynchronous.
If you mean running the udev scripts then yes, that would get
linearised instead of running in parallel to other module loads. But
then again mknod should not take that long.
> And what do you want to do for hot-pluggable devices like USB or SATA?
> Should insmod block forever if there is a free SATA port just in case
> the sysadmin wants to plug in a disk later? And if not, why is this case
> different from insmod returning immediately and reporting all plugged-in
> disks later? You _must_ be able to handle the "disk-plugged-in-later"
> case and that should "just work" for the already-plugged-in disks as
> well...
Scan the USB bus, find all devices on it, run all udev scripts for
them, return.
Just like the kernel always did prior to udev.
> I think it is pointless to bitch about udev without a clean proposal how
> should Debian handle hotplug events (including cases like when the
> device containing the root file system is literally plugged in _after_
> the kernel/initrd has been loaded).
That is a different matter. That never ever worked by itself and udev
doesn't change anything there. But for already plugged in devices the
device node was always ready when the insmod was done. Even with
devfs. With udev the device node appears at some random time after
insmod has returned.
For all cases where you load a module to activate a certain device
(disk for initrd, mouse for X, ...) this is a serious step back.
> Gabor
MfG
Goswin
Reply to: