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

From: Alan Cox (alan_at_redhat.com)
Date: 08/17/04

  • Next message: George Anzinger: "Re: boot time, process start time, and NOW time" 
    Date:	Mon, 16 Aug 2004 21:05:33 -0400
To: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>

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

  • Next message: George Anzinger: "Re: boot time, process start time, and NOW time"

    Relevant Pages

    • Re: When KeEnterCriticalRegion ?
      ... File system drivers care about this, ... > APC path or synchronize at DISPATCH_LEVEL using a spin lock. ...
      (microsoft.public.development.device.drivers)
    • [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
      ... As showed by Eduardo Habkost some days ago, the spin lock 'lock' in the ... struct 'usb_serial_port' is being used by some USB serial drivers to protect ... the access to the 'write_urb_busy' member of the same struct. ... The following patch series does that. ...
      (Linux-Kernel)
    • (no subject)
      ... > a spin lock anyway. ... > third non-legacy IRQ needed to be shared? ... > at us dot ibm dot comm ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • RE: [RFC][2.6.12.3] IRQ compression/sharing patch
      ... > a spin lock anyway. ... > third non-legacy IRQ needed to be shared? ... > at us dot ibm dot comm ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [RFC][2.6.12.3] IRQ compression/sharing patch
      ... and assign IRQs+vectors fairly early in boot, ... it might be safer to use a spin lock anyway. ... at us dot ibm dot comm ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)