Matt Thomas <matt@lkg.dec.com> writes:

> 
> I agrree with Chris that this should go into struct ifnet.
> if_media is fine with me.

Seems to me that `medium' would be more appropriate.

> Note that a SIOCGIFTYPE is also
> needed as well since the media definitions are interface type
> specific.  If you happen to get ifconfig to support this,
> ifconfig will need to be able to obtain the iftype.  Maybe a
> SIOC{GS]IFSPEED as well.

However, all three of these items are codependent, and need to be set
at the same time.  Otherwise you get into weird situations where
changing one causes the device to shut off until you change another,
or some wisecrack decides that `well, we only support this speed on
this medium, so if they change the medium, we'll change the speed
automatically', and you take a large tactical nuke to tPoLS.

> And SIOC[GS]MTU too.

I'm really not convinced that this is useful for most interfaces.

> What do you do about media with full-duplex support?  (Note
> that you can do full-duplex on FDDI too if you use the DEC
> FDDI adapters).

I don't see how this is relevant.  There is already a mechanism (using
IFF_SIMPLEX) to deal with it, and there's no reason to expose this
directly to the user.

> Another problem is that ifreq is too limiting and lead to a proliferation
> of ioctls.
>
> [...]
>
> You could then use value[0] as an option id and value[1] as the data:
> 
> #define	ifr_attr_id	ifr_ifru.ifru_values[0]
> #define	ifr_attr_value	ifr_ifru.ifru_values[2]

A switch table by another name is still a switch table.  Add the
annoyance of needing to emulate the old ioctl(2) calls, and it really
doesn't seem worthwhile.