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?



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



Home | Main Index | Thread Index | Old Index