On Tue, 8 Mar 2005, Patrick Mochel wrote: > > Are you planning on using a spinlock to protect things like the list_head > > fields in struct device? Or some other semaphore instead? How will a > > driver be able to iterate through one of those lists safely (without > > things changing out from under it)? > > The device doesn't own all of those fields. Most of those list_heads are > representative of the lists that the device is on (e.g. its controlling > bus's list of devices), which are owned by someone else. The only list > that it does own is the ->children list. I would have said that ->children list is the only one for which the device is the root or origin; the others are lists it's on. But your point is clear. In fact ownership of these lists is sort of split between the driver-model core and the bus subsystem: The core handles modifications but only when the subsystem tells it to. If someone (like the PM core) wanted to iterate safely over these lists, or even just wanted to prevent driver bindings from changing, it would have to tell either the driver-model core or the bus not to change things for a while. Telling the bus is impractical because there are lots of bus subsystems, each with its own way of doing things. A new callback would be needed; it seems a lot easier to tell the core instead. How would you tell the core or a bus driver not to add/delete devices or bind/unbind drivers? The logical answer is by locking a semaphore or the equivalent. This would be tantamount to reintroducing the bus rwsem! Maybe a way can be found around this. The PM core doesn't actually iterate over the driver-model lists; it has its own list. Maybe nobody else really needs to do it either. Or at least, anyone who does only cares about the devices in a single subsystem, so they can coordinate with the subsystem driver rather than the core. Can anyone point out a place where the kernel has to iterate over the entire driver-model tree, other than the suspend/resume routines? > I think a spinlock is the right way to protect it, but iterating over it > is tricky if you want to be able to sleep during any of the iterations. > E.g. if you want to iteratte over the children to suspend or remove them, > you'll want to drop the lock for each node, which makes it a bit racy WRT > removal and insertion. Working around this is possible, but not quite > trivial. It's clear that the lists have to be protected somehow, and the protection has to extend over an entire subsystem since modifying a list involves changing several device structs at once. The only possibilities are a subsystem-wide semaphore like the current rwsem (okay, maybe a regular semaphore instead an rwsem) or a subsystem-wide spinlock. If Greg wants to eliminate the rwsem, a spinlock is the remaining choice. Alan Stern
