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,
	                 ifmedia_cb_t *cbf)

   vs
			error = ifmedia_ioctl(ifp, (struct ifreq *)data, 
			    &sc->xx_media, cmd);

  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
simple-queue.   

Any other comments?