Network-related device drivers and MPSAFEty: status, and plans
for 7.0
Robert Watson
rwatson at FreeBSD.org
Tue Jul 19 09:22:26 GMT 2005
On Tue, 19 Jul 2005, Poul-Henning Kamp wrote:
> In message <42DCB694.7030007 at gneto.com>, Martin Nilsson writes:
>> Robert Watson wrote:
>>> if_el Ethernet driver for 3Com Etherlink 3C501 devices.
>>> Mutxes present and exercised, not marked MPSAFE.
>>
>> This is an 8-bit ISA card that was a piss-poor-performer even when it
>> was new. Please don't waste developer resources on things like this!
>
> It was on the other hand one of the very first ethernet cards you could
> get your and on, and some of us still keep mementoes like that around
> :-)
>
> But I agree, that driver should just be EOL'ed.
I think the right model is that we keep everyone updated on what drivers
have been fixed, and which haven't, and at some point the list of unfixed
drivers ceases to shrink. The remaining unfixed drivers become EOL'd.
That way everyone who cares about a driver has lots of time to fix it.
It's not all that hard to time-consuming to add a basic locking strategy
to most network device drivers. Generally, it's a question of adding a
sleep mutex to the driver softc, then holding that mutex around the
majority of activity of the driver, dropping it when entering the network
stack for the interface input routine or event calls (such as link
changes). More sophisticated strategies are available, such as separately
locking in-bound and out-bound paths if the hardware supports it (has
separate receive and transmit units), serializing the driver in a thread
around an event model, etc, but for most of the hardware we're talking
about (10mbps ISA cards) there's not likely to be a big benefit to doing
anything more than the most basic approach.
Some known hard bits that depend on device driver:
- Does the device driver have clean softc setup and tear-down paths?
Most new drivers do, but some old drivers had quite different attach
routines due to pccard support coming after ISA support, etc.
Sometimes they don't have detach routines, or only have them for some
busses. A simplification pass may be a good first step so that the
locks are initialized and destroyed in central locations, etc. I
believe Warner did a lot of this sort of thing for if_ed last year,
which should help a lot when it comes to locking.
- Does the driver have lots of special case code and handling for
different variations on support hardware? if_dc and if_de are classic
examples of this, where there is a large quantity of special case code,
making it difficult to read, and difficult to test thoroughly.
- Does the driver have lots of likely obsolete optimization and
instrumentation? Early 100mbps cards, such as those support by if_de,
required quite a bit of magic to achieve the performance they did on ISA
busses. A lot of that magic is ifdef'd and not used by default. A
simplification pass may be a good first step.
If you have a bit of experience with network device drivers, and the
hardware, it should take only a few hours to do a first pass at locking a
driver in the list.
Robert N M Watson
More information about the freebsd-arch
mailing list