Re: PATCH: switch ide-proc to use the ide_key functionality

[Alan Cox]

BTW this may help if I document the locks and what they cover in case its
not obvious

drives_lock is the spin lock you must own to update the drive list

ide_cfg_sem is the semaphore you must own to walk or hold loose references
to the ide_hwif_t array and elements relating to adding/removing/busy status

ide_lock is taken when you want to write that array and deal with elements
that are interrupt walked by other devices. Notably this means the hwgroup
chains.

ide_settings_sem could be per drive but isnt, it is used when you are
processing the ioctl/proc objects attached to the driver either by walking
them or removing them.


drivers_lock is the spin lock you must own to update the drivers list
drivers_sem is the semaphore you must own to walk the list and while
holding loose references to drivers (ie when the busy/lists are not
consistent)

The lock order is

	ide_cfg_sem
	drivers_sem
	ide_settings_sem
	drivers_lock | drives_lock
	ide_lock


Which means my cunning plan from the previous mail doesn't actually work
unless we take ide_cfg_sem at the top of the proc code before setting_sem. 
Also looking over it I need to send you the bits to take the sems in each 
proc routine for that case.  

PS: what do you think about deprecating (but not yet removing) ide_write_config
and ide_read_config now we have sysfs ? Does anyone actually use its
"wait for non busy and then pci config write" - does anyone use it at all ?

Also while looking at proc it would clean up read_imodel and make it a ton
more useful to stick the string pointers into hwif->chipset_name or somesuch
so we can report the PCI ones in detail ?

Alan


-
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/