On Wed, 9 Mar 2005 17:07:38 -0500 (EST), Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Wed, 9 Mar 2005, Dmitry Torokhov wrote: > > > > Here's the idea: Only one process is allowed to use those lists at a time. > > > Maintenance of the lists is synchronized by means of a subsystem spinlock. > > > If a process needs to update or traverse the lists while they are already > > > in use, it will instead queue a request to be handled later. When a > > > process finishes using the lists, it will check the queue for outstanding > > > requests and fulfill them. > > > > Why don't ve add a version to list, instead of a queue. Every time > > list is modified (element is added or removed) version is incremented. > > If lenghty operation is needed the traversing process drops the lock > > and after performing the operation compares current version with > > saved. If they differ traversal is restarted from the beginning. At > > least for bus' device and driver lists this should work fine and will > > not require holding a lock/semaphore for extended periods of time. > > This would work too, and it would be simpler. It won't even suffer from > too many restarts -- not unless a lot of similar devices are registered or > unregistered all at once, in parallel. Presumably that doesn't happen > much. (Although it just might be common on mainframes...) > > What do you think about the problem of requiring callers to lock the > parent device when during device_add/del? If the new device is discovered > while probing the parent bridge device then this requirement will be > fulfilled automatically. Hotpluggable buses would require some changes, > though. > I am not sure. Is it only one level? Within the same bus? Across several buses? Some devices probably do not care being actively locked, some probably require that only one operation is performed at a time (well, i guess it is locked then). I guess I need to re-read carefully the whole discussion, so far I was omsewhat causal observer. -- Dmitry
