> 
> I'll go out on a limb here (since I don't have any experience yet with
> NetBSD's SMP kernel implementation)

Or any other SMP system?
I think I started writing SMP drivers in 1994!

> and say that since device drivers
> are merely subroutines called by the kernel at appropriate places that
> it should not be necessary to do anything to make them SMP compatible
> unless they reach back into bits of kernel storage that does have SMP
> interlock requirements.  I.e. if a driver is well behaved and just does
> hardware manipulation then it should be fine.

Er no - there is not necessarily anything to stop you driver
code being called at the same time on multiple CPUs (even for
the device).  Any data structures have to be locked - the effects
of getting it wrong are very difficult to pin down.

> Of course most drivers do
> need to call some kernel subroutines, and so those routines must be made
> SMP compatible (assuming they might manipulate shared storage).

To make the kernel SMP (rather than having one big lock - doesn't work
very well) you have to attack all the support routines first, then
start working your way in from the user interface through the
device drivers.

> Unfortunately I don't believe there's yet a well defined Device Driver
> Kernel Interface specification so it's hard to know whether all the
> necessary routines are SMP compatible and whether or not a given driver
> is DDK compliant (and thus implicitly SMP compatible or not).

In the end most things have to do the required locking for SMP.
For certain things (maybe simple device drivers) a DDK interface
can be used to tell the kernel that a particular driver isn't MP
clean - so the kernel can apply a global lock on the calls into that
driver.  However this will only work if the kernel knows where these
entry points are.

	David

-- 
David Laight: david@l8s.co.uk