Subject: Re: NIC driver interface to kernel.
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 12/13/2003 14:05:49
Some very minor nitpicks/additions to Matt's description:
>IFF_OACTIVE in if_flags is used as a primitive flow.
... flow control.
>if_stop isn't really used.
... Except perhaps when the watchdog (or other code) determines the
interface has gone insane, and needs to be re-initalized and head and
restarted. if_stop() is often used to make sure the chip is stopped
before banging it on the head.
>By the time the driver gets it out of if_snd, it is in wire format.
Except without a link-level CRC. The hardware almost always computes
that for you, for Tx. On Rx, you should ask the hardware to strip the
CRC before DMA, or (if for some reason it cant), subtract four bytes
of CRC from the length before passing the packet upward. If you
support VLAN tagging. be similary careful about VLAN tag length and
>But it may be less the minimum packet length and the driver/hardware
>is responsible for padding it out.
i.e,. if the hardware won't auto-pad, the driver should explicitly
pad. If the hardware doens't pad and you don't, the packet will
usually make it out onto the wire, padded with whatever followed your
mbuf chain. Potentially leaking kernel state like that is considere a
Very Bad Thing.
BTW, the red Daemon book has a very good intro to most of this, with
the notable exception of bus_dma. Even the black Daemon book has
useful info. nroff -ms /usr/src/share/doc/smm/18.net/?.t has much of
the same info, and comes free with NetBSD and other 4.4BSD-Lite-based OSes.
(I wish I could find the version with the pic diagrams).
Red daemon book == design and implementation of the 4.4BSD operating system
black " " == design and implementation of the 4.34BSD operating system