> 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 mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
