Mouse <mouse%Rodents-Montreal.ORG@localhost> writes: > 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. Yes, there is a giant lock. Some parts of the kernel need to have that lock to work correctly. I believe the parts are now the networking stack and some drivers. Making a driver MPSAFE entails adding fine-grained locking with the new mutex(9) rules, and then dropping the MPSAFE flags on interrupt registration and callbacks. Look at sys/src/dev/pci/if_bnx.c as an example of a non-MPSAFE driver and the history; you'll see an MPSAFE fix near the top. This driver is confusing because there are some mutexes. When there are enough then the MPSAFE flags can be added. Arguably each driver should havea comment, but the lack of MPSAFE in flags (and an easy-to-overlook 0 instead!) is how you can tell; that means that drivers written for the good old days of a (single) PDP-11 cpu still work safely. It's a fair point about memory barriers and mutexes; I had never thought of that. I would say that the mutex should ensure that no instructions From aother program post enter can issue until after the exit is called, but it then seems obvious that without memory barriers this isn't a useful guarantee. It would be nice if someone who really gets this added a line to the mutex man page, ideally referring to the memory barrier specs.
Attachment:
pgpCmFrEYUQfq.pgp
Description: PGP signature