driver hacking tips (was Re: [PATCH] QStor SATA/RAID driver for 2.6.9-rc3)

From: Jeff Garzik (jgarzik_at_pobox.com)
Date: 10/12/04

  • Next message: Andrea Arcangeli: "Re: secure computing for 2.6.7" 
    Date:	Tue, 12 Oct 2004 14:25:13 -0400
To: Mark Lord <lkml@rtr.ca>

    [subject changed as this knowledge can benefit others as well]

    In addition to agreeing with James' most recently assessment of
    qs_process_sff_entry(), I wanted to interject a bit of more general
    discussion...

    Two main, but unrelated, driver-writing points:

    1) Putting almost all your in-irq code into a tasklet can be quite
    convenient, if your situation is amenable to that. The benefits are

    a) your irq handler is tiny,

            ack irqs
            tasklet_schedule()

    b) data can be synchronized without a lock, if the data is only used in
    the tasklet or in between tasklet_disable/tasklet_enable pairs.

    c) you can "call" your in-irq code from places other than your irq
    handler, and let the tasklet subsystem synchronize the tasklet schedule.
      no worries about disabling interrupts, they will just do (a) as
    described above.

    2) You want to avoid a model (like qs_process_sff_entry, alas) where you
    have one single, huge "event completion" path, called from various
    points in the driver. Instead, do your best to make sure event/action
    as fine-grained as possible.

    Storage drivers that want to handle long-running events, or events that
    need process context, typically want to either fire off events
    _asynchronously_ via schedule_work(), or have a long-running thread that
    does nothing but processes an internal driver event queue. It's really
    programmer's preference at that point, as having a single (or per-host)
    event queue thread can sometimes be more simple than async work queue code.

            Jeff

    -
    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: Andrea Arcangeli: "Re: secure computing for 2.6.7"

    Relevant Pages

    • Re: [PATCH] OMAP: Keypad driver
      ... I don't think the tasklet stopping code is correct. ... But the just-killed timer handler might have ... I will update the driver and submit the patch. ... May changelog needs URL entry like http://linux.omap.com _or_ ...
      (Linux-Kernel)
    • Re: Patterns in my project. Suggestion Needed Also.
      ... it will call under-layer driver. ... > callback in a certain period, Timer task will call time-out callback. ... And there are different kinds of resources. ... machine with an event queue manager. ...
      (comp.object)
    • Re: Patterns in my project. Suggestion Needed Also.
      ... >>machine with an event queue manager. ... is attached to Command, Resource, and Driver? ... >>envision a race condition unless Command keeps track of which Driver ...
      (comp.object)
    • [RFC] CONFIG_NET_DMA can hang the system if DMA engine driver uses tasklets
      ... With CONFIG_NET_DMA enabled the whole system hangs during network throughput testing. ... I've done some investigation and found that at some point we run out of descriptors and for some reason my tasklet is not executed. ... We can see that the network stack calls dma_memcpy_to_iovecfunction from the softirq context and it never returns in case of DMA driver runs out of descriptors and thus blocks the tasklet from being executed. ...
      (Linux-Kernel)
    • Re: [PATCH 06/13] DMAENGINE: driver for the ARM PL080/PL081 PrimeCells
      ... _very_ bad news if you want DMA engine drivers to behave the same. ... architecture-specific (dma driver / slave driver pairing) behaviour. ... the tasklet runs on a different CPU, ... spins on slave driver spinlock ...
      (Linux-Kernel)