Subject: Re: can't switch DE500 to 100Mbit
To: Matt Thomas <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 02/15/1997 15:44:05
OK, I've tried consing up a prototype implementation of the support
kernel routines, based on the supplied documentation. (If we can get
the BSDI code, that would be better still.)
The draft isn't sufficient to really spec out a portable
interface. (it's missing pieces and not internally consistent.)
* the document says
For SIOCSIFMEDIA, the ioctl routine masks the don't care
bits (from ifm_mask) then tries to find a matching ifmedia_entry
entry. If one is found the driver is called back with a pointer
to the current and new entries.
But that's not possible, with the given signature for the
ifm_change callback, and. Does ifm_change really get old and new,
or just new?
* What is the *name* of the object that ifm_cur points to?
The draft exposes the internal representation of the
list of supported media to individual drivers via the
`ifm_cur' pointer. When the media is changed via SIOCSIFMEDIA,
the driver-specific ifm_change callback function needs to change
the hardware to use the newly-set interface.
Exposing the internal list (via ifm_cur) means the structure
name used for the internal list of supported interfaces is exposed,
which in turn affects writing portable drivers.
If I were Matt Thomas, I'd prefer an in-kernel software interface which
keeps a *copy* of the currentlyselected media in 'struct if_media'.
That way, the internal implementation could change and the driver-specific
code need not care.
Otherwise, we'd want the name of that structure to be compatible
across the *BSD kernels
* Are the ifm_aux and ifm_data purely for convenience of the
device-specific callback function? I'm assuming they are.
* ifmedia_ioctl needs access to an interface's if_media structure.
(SIOCSIFMEDIA must iterate over the supported media to find
something supported). The documentation doesn't include
a `struct if_media' argument; and if one is added, the
callback-function argument is unecessary.
In fact the documentation Matt posted is self-contradictory:
ifmedia_ioctl(struct ifnet *ifp, struct ifreq *ifr, int cmd,
error = ifmedia_ioctl(ifp, (struct ifreq *)data,
I'll assume that ifmedia_ioctl takes an ifp, a struct ifmedia pointer,
and the ioctl cmd and data arguments. I like that order, but
is it compatible with what BSDI does?
I've consed up code that assumes an explicit list of supported `media
words' hanging off struct if_media, and an ifm_cur pointer that points
to the `selected' media-word struct. They should be redone as a
Any other comments?