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

[Jeff Garzik <jgarzik@pobox.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 
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