lkml.org 
[lkml]   [2005]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Locking changes to the driver-model core
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:11    [W:0.054 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site