driver hacking tips (was Re: [PATCH] QStor SATA/RAID driver for 2.6.9-rc3)
From: Jeff Garzik (jgarzik_at_pobox.com)
Date: Tue, 12 Oct 2004 14:25:13 -0400 To: Mark Lord <email@example.com>
[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
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,
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
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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/