On Wed, 16 Mar 2005, linux-os wrote: > Thought experiment: > Suppose you had a kernel-thread whos duty it was to handle the > shutdown and restarting of devices on such busses. Since it > is the only thing that would touch such code, wouldn't things > be a lot simpler and not subject to deadlocks? > > Code calls something that puts the stuff the kernel thread is > supposed to do, in a queue. The daemon handles it and wakes > up the caller when it's done, or it failed. > > Queues are easy and they don't deadlock.
While this might work, it has the disadvantage of funnelling everything through a single thread. Operations on different buses couldn't take place simultaneously the way they can even now. My proposal would allow even more parallelism than there is currently. Also there are more code regions that need protection against simultaneous device access than just the parts involved in registering and unregistering devices and drivers. So the semaphores would still be necessary, and with them comes the possibility of deadlocks. (Such semaphores already exist in the USB subsystem; a large part of my proposal involves moving them out to the entire driver model.) Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
