Re: Locking changes to the driver-model core

[Alan Stern]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/