Re: debian and UDEV
Hendrik Sattler <debian@hendrik-sattler.de> writes:
> Am Donnerstag, 18. Mai 2006 21:53 schrieb Goswin von Brederlow:
>> Hendrik Sattler <debian@hendrik-sattler.de> writes:
>> > Am Donnerstag, 18. Mai 2006 19:22 schrieb Goswin von Brederlow:
>> >> Because the only _solution_ with current userspace is to kill the
>> >> kernels hotplug design and go back to synchronous handling.
>> >
>> > Another solution might be to dynamically attach to udev events. This is
>> > how in-kernel async device discovery is handled and correctly done, this
>> > is without race conditions:
>> > * register a function/program for new devices of your choice
>> > * load the proper module
>> > * your previously registers function will be run
>>
>> But how do you detect when there is no device to be found to call the
>> function?
>
> That's of absolutely no interest because in this case, you cannot go on,
> having synchronous events or not. However, you might have alternatives for a
> root partition that are fulfilled with another function call.
> The point is that to keep the goal in mind: you want to achieve something e.g.
> by probing many different possibilities.
> Lets say you want to find a scanner: you probe SCSI busses, spawn a thread
> that test the parallel bus and another one for USB and whatever else. You
> only want to find one. You don't synchronize on any of those specific events
> but on the result: that a scanner is found.
> Sure, you need a timeout, but it is unrelated to a specific probing method
So you mean you register a function for "block device found" and then
scan all the ide, sata, scsi, usb, ... drivers from the initrd and for
every disk and partition the function gets called. When it gets called
with the partition with the right signature (label or uuid for
example) it mounts / and continues.
Not a function for "scsi disk ID 0 on scsi0 (3ware) found".
I see what you mean. Keeping the function abstract enough allows
removing a disk and plug it in somewhere else, e.g. change the scsi
ID.
>> Say you have a scsi controler with no harddisks attached. You boot,
>> you register a "continue booting" function for the scsi disks, load
>> the scsi modules and then you hang. Bugger.
>>
>> So you have to add a timeout again which means a race condition or
>> too long delay.
>
> Just because you need synchronisation points does not mean that you have to do
> everything synchronously.
> The situation in userspace is completely the same as in kernel-space and also
> the solutions are the same.
>
>> You end up with polling and displaying "waiting for /" in a loop.
>
> Yes. Why not. In fact, that's what your are interested in. You are NOT
> interested in finding all SCSI disks on the bus but only the device with the
> root partition. This is found at some time, but the bus scan might not be
> over, yet. And since you have your / now, you can go on without waiting for
> the bus scan to be finished.
>
>> People are saying this is a good thing because then you can hotplug
>> your scsi disk or usb stick that has your / on it and it will continue
>> booting.
>
> But you only wait for the real goal. It is not a specific device file, that
> you are interested in but the root file system in a mounted state.
>
> This discussion is like explaining the principles of parallelism with threads
> and object oriented programming to a PASCAL programmer.
>
> HS
Yeah, sorry. I wasn't thinking abstract enough.
MfG
Goswin
Reply to: