tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



> The way to write a driver to be mpsafe is to use the mutex(9) calls
> for locking exclusively.

Well, assuming rwlock(9) is considered a subset of mutex(9) for the
purposes of that sentence, I then have to ask, what else is there?
spl(9), the traditional way, specifically calls out that those routines
work on only the CPU they're executed on (which is what I'd expect,
given what they have traditionally done - but, I gather from the
manpage, no longer do).

This then leads me to wonder how a driver can _not_ be MPSAFE, since
the old way doesn't/can't actually work and the new way is MPSAFE.

dholland says that a driver is MPSAFE "if it does not require
kernel_lock to work correctly".  What's kernel_lock?  man -k turns up
nothing; some grepping leads me to think it's what I've seen called on
the lists a `giantlock', which is what I thought all this new locking
stuff was supposed to be getting away from.

So now I'm puzzled.  I've clearly either missed something or
misunderstood something, possibly both....

Also a bit disturbing is that I see memory barriers in various places,
in particular some parts of the mutex implementation, but the
documentation is completely silent on whether clients of the mutex
interface may assume anything memory-barrier-ish.

While not directly related, I also note some issues in the memory
barrier descriptions:

- membar_enter and membar_exit speak of loads "reach[ing] global
   visibility", which makes no sense to me.  What does it mean for a
   load to reach global visibility?

- membar_consumer is described with "All loads preceding the memory
   barrier will complete before any loads after the memory barrier
   complete".  That last "complete" needs to be "start" for this to be
   a useful guarantee.

- membar_sync has each of the above issues (mutatis mutandis).

/~\ 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


Home | Main Index | Thread Index | Old Index