Network-related device drivers and MPSAFEty: status, and plans for 7.0

[Robert Watson]

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