> That is a lot of variation and ifconfig's link0, link1, link2 is just
> not enough anymore.

Well, we've had not unreasonable service from a hack made of unused bits
that were already there :-)

> Also, being able to the dot3 mib counters would be benificial.  It beats
> writing messages to /dev/console.
> The question is where do these go.
> 
> One could expand ifconfig.  One could also put these thing under sysctl.
> Both have advantages and I don't have much of preference.

Shouldn't it be 'ifconfig, and thus sysctl' ?   It seems odd that there
isn't already a sysctl (CTL_NET/PF_LINK maybe?) to expose the ifnet
structures.  But I guess that's just asking for the old
kmem/kernfs/sysctl debate all over again ;-)

The RFC1573 media type (ether, fddi, etc) is already in
ifnet.if_data.ifi_type.  But that's generic across interface types.
The physical media option should really go together with the RFC 1650
dot3 counters, if anywhere (since it's specific), and they can't just
sit in ifnet.if_data directly since it varies.  I see where your
problem is :-)

It doesn't make sense to expose the media specific stuff via sysctl or
whatever if the generic stuff isn't similarly exposed -- so doing
it separately that way is IMHO not a good choice.  Having a media specific
if_data sub-structure pointed to from if_data is a right mess, as we would
then lose the advantage of ifnet being monolithic.  However, it can't be
a union since its media specific, and we'd not have the irrelevant
media header definitions available everywhere.

Nope, I don't see a good choice.  If we just want a single media
PHY integer, then it should go together with the MAC type in if_data.

If we want to have a media specific MIB, then we'd have to lose the
monolithic nature of ifnet, and split out the the media specifics.

For convenience, I'd put the media PHY selector into if_data directly,
and add a pointer to a separate dot3 mib structure.  That means that
we still have a monolithic ifnet for the compulsory bits but additional
stats requires an indirection.  That's a kludge, but I can't think of
anything better.

Now, what to name the media PHY selector ?  ifi_type is already the
MAC selector, and we don't really want to subclass it into
ifi_type.mac and ifi_type.phy :-) so I suggest renaming ifi_type to
ifi_mactype, and adding an ifi_phytype, retaining a #define ifi_type
for compatibility.

One question I have is how closely do we want to track the standards
track mibs?  The mibs in *bsd haven't really had a lot of work put
into them to track anything.  And we don't even have an SNMP agent in
the standard distribution :-)

-- 
Ronald Khoo <ronald@demon.net> Voice: <+44 181 371 1000> Fax: <+44 181 371 1150>