Re: What's an "MPSAFE" driver need to do?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> Okay.  I don't think I can rely on that, though, because the things
>> I'm porting that have led me to care about locking are not just
>> device drivers.
> You make it sound like a difficult task.

It is, mostly because getting it wrong doesn't produce an obvious,
immediate, repeatable failure.  Instead, it produces occasional subtle
problems - and perhaps not even them, if the issue in question can't
actually cause trouble on my test machine for one reason or another
(maybe it never reorders stores in ways that could show up the issue,
for example), leading me to think I've got it right, only to get bitten
when I try to use it on another architecture which does exhibit the
behaviour which will show up my mistake.

> As I see it, making a normal/simple device driver MP-safe shouldn't
> be that hard for a kernel programmer.

Neither of the two things I have is a normal/simple device driver.

> Actually, I see no real differences to general programming besidds
> the interrupt levels (which should be more clearly documented).

The major difference I see is that there are a lot of interfaces which
are totally undocumented.  For example, when does my AF-specific code
need to lock sockets a la solock()?  As far as I can tell, the only way
to determine this is to read other code and look for places that assume
the socket in question is locked (fortunately, many of them are marked
with KASSERT...) or simply clone an existing AF and keep its locking
while changing the rest.  Neither is really satisfactory.

Of course, userland is not immune to the undocumented-interface problem
either.  But I haven't seen it nearly as much there.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B