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

Rah. Some piece of concensus. Let us also assume consensus is
to extend ifru_flags to an int as long as we're changing things.
On to the debate:

> Note that a SIOCGIFTYPE is also needed as well since the media
> definitions are interface type specific.

Why? This seems to induce needless complexity for very little gain.
Why not maintain all media types as "interface type independant"?

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

Yuck, yuck, yuck...

> And SIOC[GS]MTU too.

Umm, we already have:

#define SIOCSIFMTU       _IOW('i', 127, struct ifreq)   /* set ifnet mtu */
#define SIOCGIFMTU      _IOWR('i', 126, struct ifreq)   /* get ifnet mtu */

are these inssufficient?

> 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).
> 
> Should that be a IFF_LINKx option?  (I hope not).  

I really think it should. After all, you can do full-duplex FDDI on
any sort of FDDI (mm, sm, stp), right? It certainly seems that
duplicity should be outside of media type (otherwise we double the
FDDI media types to 6 from 3...), whether as an IFF_LINK? or as
IFF_FDUPLEX (the latter seems not worth it at this point, given the
paucity of drivers which have this option).

> it would be very useful if struct ifreq was larger (so that you could
> use it with protocol whose sockaddr > 16 bytes long like IPv6).

Well, it sounds like you really just want a larger struct sockaddr, right?
"Not this problem".

I would punt on the "radical idea"...

As for dual attach FDDIs with multiple media, I guess Chris' (2) is
best. After all, they need to be able to do things like IFM_AUTOSENSE.

Boy this gets ugly -- haven't people tackled this problem on other
OSes? Anyone know what solutions have arisen?

--jhawk