> I agrree with Chris that this should go into struct ifnet.
> if_media is fine with me.  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.

A healthy can of worms...  8-)

More comments on these below...

> And SIOC[GS]MTU too.

Actually, from what I can tell, that is already there, though it
doesn't appear to be supported by many drivers (well, only if_ppp 8-),
and overloads ifr_metric field to contain the MTU data.  8-)


> The definitions (IFM_*) should really go in0 either
> <netinet/if_ether.h>, <net/if_fddi.h>, etc. since they are type
> specific or <net/if_medias.h> (ie. like <net/if_types.h>).

I think i prefer <net/if_medias.h>, if only because that allows you to
make life easy, and put an:

#ifdef IFM_TYPENAMES
char *ifm_typenames[] = {
	"unknown",			/* common types */
	"auto-sense",
	"string",			/* types for use with tin cans */
	"wire",
	"10base-T",			/* types for use with ethernet */
	"BNC",
	"ether",
	"AUI",
	...
}
#endif

For inclusion into netstat (or other programs that wanted it).

Of course, this does have the disadvantage that if you forget one and
want to add it later, you have to add it at the end.  (Unless you
include padding elements, which, now that I think about it, is
probably a good idea...  but even then, if you need enough, they have
to go at the end...)

Also, if you do one single list, SIOCGIFTYPE is unnecessary (at least
for this purpose).


re: SIOC.IFSPEED:

Why is this really necessary?  E.g. if you're going to count 4Mbps
token ring and 16Mbps token ring as seperate items, would not also,
say, OC3 (155Mbps) and OC12 (622Mbps) ATM be seperate?  What would
actually use it?


> What about things like dual attach FDDI controllers?  They could
> have two different medias in use.

Three ways that I can think of, to solve this:
	(1) punt 8-)
	(2) make the interface media type actually be an array
	    (say, 4 elements, to be on the safe side), and have a
	    value which indicates "this entry unused by this adapter"
	    (so that it wouldn't be printed, and which would be a safe
	    option for extra elements for 'set'), or
	(3) For adapter types which can support multiple media
	    at one time, expand them all, e.g. (using your
	    constant-naming conventions: IFM_MMF_SMF (multi-mode
	    on first attachment, single-mode on second),
	    IMF_SMF_MMF (single-mode, multi-mode), IMF_MMF_MMF
	    (multi-mode both)...

(1) has the advantage that it's easy to implement,
(2) has the advantage that it's pretty simple all around, and
    expandable, but is harder to implement in 'ifconfig,' and
    the 'valid argument' checking in drivers is more difficult
    as well.
(3) is relatively simple to implement (but can involve some hair
    in dual-attach drivers), but expands exponentially with
    number of possible single-device attachments...

I think i'd go for (2).


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

It seems that _this_ is orthogonal to media type, and might make its
own SIOC.IFDUPLEX ioctl, or something similar.


> BTW, at the same time we probably should increase if_flags from
> a short to an int.
>
> [ ... ]
> 
> Another problem is that ifreq is too limiting and lead to a proliferation
> of ioctls.

I think I like both of these (i'm not actually sure about liking the
latter, 'radical' idea 8-), but i think that they should both be
addressed seperately.

the if_flags short->int change causes binary incompatibility, since on
many architectures there's no guarantee as to what's going to be in
the other half of that short.  That can be worked around, but it's
still non-trivial.

I'm not quite as sure about the 'radical idea' bit.  doing that would
make the code that handles requests which use 'strict ifreq'
potentially a fair bit more complex.  At the very least, another layer
of 'switch' would have to be added, in ifioctl() _and_ in all of the
rest of the code that handles ifreq-passing ioctls.



chris