>> 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 [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
