Adding new media types to if_media.h
George Neville-Neil
gnn at neville-neil.com
Mon Feb 9 21:08:48 UTC 2015
On 8 Feb 2015, at 22:41, Mike Karels wrote:
> Sorry to reply to a thread after such a long delay, but I think it is
> unresolved, and needs more discussion. I'd like to elaborate a bit on
> my goals and proposal. I believe Adrian has newer thoughts than have
> been
> circulated here as well.
>
> The last message(s) have gone to freebsd-arch and freebsd-net. If
> someone
> wants to pick one, we could consolidate, but this seems relevant to
> both.
>
> I'm going to top-post to try to summarize and extend the discussion,
> but the
> preceding emails follow for reference.
>
> To recap: the existing if_media interface is running out of steam, at
> least
> in that the "Media variant" field, with 5 bits, is going to be
> insufficient
> to express existing 40 Gb/s variants. The if_media media type is a
> 32-bit
> int with a bunch of sub-fields for type (e.g. Ethernet),
> subtype/variant
> (e.g. 10baseT, 10base5, 1000baseT, etc), flags, and some MII-related
> fields.
>
> I made a proposal to extend the interface in a small way, specifically
> to
> replace the "media word" with a 64-bit int that is mostly the same,
> but
> has a new, larger variant/subtype field. The main reason for this
> proposal
> is to maintain the driver KPI (glimpse showed me 240 inclusions of
> if_media.h
> in the kernel in 8.2). That interface includes an initialization
> using a
> scalar value of fields ORed with each other. It would also be easy to
> preserve a 32-bit user-level API/ABI that can express most of the
> current
> state, with a subtype/variant field value reserved for "other" (there
> is
> already one for "unknown", but that is not quite the same). fwiw, I
> found 45 references to this user-level API in our tree, including both
> base and "ports"-type software, which includes libpcap, snmpd,
> dhclient,
> quagga, xorp, atm, devd, and rtsold, which argues for a
> backward-compatible
> API/ABI as well as a more-complete current interface for ifconfig at
> least.
>
> More generally, I see two problems with the existing if_media
> interface:
>
> 1. It doesn't have enough bits for all the fields, in particular,
> variant/
> subtype for Ethernet. That is the immediate issue.
>
> 2. The interface is not sufficiently generic; it was designed around
> Ethernet
> including MII, token ring, FDDI, and a few other interface types.
> Some of
> the fields like "instance" are primarily for MII as far as I know, and
> are
> basically unused. It is definitely not sufficient for 802.11, which
> has
> rolled its own interfaces.
>
> To solve the second problem, I think the right approach would be to
> reduce
> this interface to a truly generic one, such as media type (e.g.
> Ethernet),
> generic flags, and perhaps generic status. Then there should be a
> separate
> media-specific interface for each type, such as Ethernet and 802.11.
> To a
> small extent, we already have that. Solving the second, more general
> problem,
> requires a whole new driver KPI that will require surgery to every
> driver,
> which is not an exercise that I would consider.
>
> Using a separate int for each existing field, as proposed, would break
> the
> driver KPI, but would not really make the interface generic. Trying
> to
> make a single interface with the union of all network interface
> requirements
> seems like a bad idea to me (we failed last time; the "we" is BSDi,
> where
> I was the architect when this interface was first designed). (No, I
> didn't
> design this interface.)
>
> Solving the first problem only, I think it is preferable to preserve a
> compatible driver KPI, which means using a scalar value encoding what
> is
> necessary. Although that interface is rather Ethernet-centric, that
> is
> really what it is used for.
>
> An additional, selfish goal is to make it easy to back-port drivers
> using
> the new interface to older versions (which I am quite likely to do).
> Preserving the KPI and general user API will be highly useful there.
> I'd be likely to do a 11-style version of ifconfig personally, but it
> might not be difficult to do in a more general way.
>
> I am willing to do a prototype for -current for evaluation.
>
> Comments, alternatives, ?
I agree with your statements above and I'd like to see the prototype.
Best,
George
>
> Mike
>
>> From: Eric Joyner <erj at erj.cc>
>> Date: January 6, 2015 4:50:28 PM CST
>> To: mike at karels.net
>> Cc: Adrian Chadd <adrian at freebsd.org>, Rui Paulo <rpaulo at me.com>,
>> "freebsd-net at freebsd.org" <freebsd-net at freebsd.org>, Eric Joyner
>> <erj at erj.cc>, John Baldwin <john at baldwin.cx>, Jack Vogel
>> <jfvogel at gmail.com>, "freebsd-arch at freebsd.org"
>> <freebsd-arch at freebsd.org>
>> Subject: Re: Adding new media types to if_media.h
>>
>> Then going with what Mike says about leaving backwards compatibility,
>> I
>> suppose we should do something like what Adrian suggested, and add a
>> separate struct. We can indicate that the separate struct exists by
>> setting
>> the media type value in the if_media word to 0xc0, since that's the
>> last
>> unused value. Then existing programs won't have to support any new
>> features
>> if they don't want to.
>>
>> Adrian -- where can I look for more information on what net80211 does
>> for
>> media types? Do you mean what it does with MCS values, or something
>> more;
>> I've looked at it a bit, but I don't know very much about how Wi-Fi
>> works.
>>
>> - Eric
>>
>> On Fri, Dec 12, 2014 at 5:06 PM, Mike Karels <mike at karels.net> wrote:
>>
>>>> On Friday, December 12, 2014 12:26:24 PM Jack Vogel wrote:
>>>>> I think I'd go along with Mike, keeping it simpler seems like a
>>>>> good
>>> idea.
>>>>>
>>>>> Jack
>>>
>>>> If the userland ABI impact isn't too broad I think this is fine.
>>>> Mike,
>>> do you
>>>> know off hand how many user-facing things would be affected?
>>>
>>> I didn't know off hand, but I have a glimpse index at $WORK (it's
>>> for
>>> McAfee
>>> Firewall Enterprise, aka Sidewinder, based on 8.2). I found 45
>>> references
>>> to
>>> if_media.h at user level, including "ports" that we use, and
>>> excluding our
>>> own software. The list includes libpcap, snmpd, dhclient, quagga,
>>> xorp,
>>> atm, devd, and rtsold. fwiw, I found about 260 inclusions of
>>> if_media.h
>>> in the kernel.
>>>
>>> This suggests that we should preserve a backward-compatible user
>>> API, even
>>> if it has limits. Unfortunately, the media word I mentioned is a
>>> plain
>>> int,
>>> not a typedef. I would propose a similar API that is not limited,
>>> but easy
>>> to convert (e.g. using a new typedef). I'd be willing to sketch out
>>> something
>>> like that.
>>>
>>>>> On Fri, Dec 12, 2014 at 6:39 AM, Mike Karels <mike at karels.net>
>>>>> wrote:
>>>>>>> Any other thoughts, or should I start looking at seeing what I
>>>>>>> can
>>> take
>>>>>>> copy from net80211?
>>>>>>>
>>>>>>> Also adding -net, since this is pretty relevant.
>>>>>>
>>>>>> I had the same reaction as Adrian initially, as an int with
>>>>>> numerous
>>>>>> fields
>>>>>> seems really messy. However, I don't think we have the
>>>>>> challenges of
>>>>>> 802.11,
>>>>>> and the only real problem is that the subtype field has run out
>>>>>> of
>>> bits.
>>>>>> And both ifconfig and the drivers are cast in the form of a
>>>>>> scalar
>>> "media
>>>>>> word", with parameters to ifmedia_add like IFM_ETHER | IFM_1000_T
>>>>>> |
>>>>>> IFM_FDX
>>>>>> (assuming that all the bits are in a scalar).
>>>>>>
>>>>>> Instead, I would propose that we simply change the media word
>>>>>> from
>>> 32 bits
>>>>>> to 64, and move the subtype from its current location to a new
>>>>>> field
>>> (e.g.
>>>>>> 16 bits) in the new space. I believe this can be KPI compatible,
>>> and it
>>>>>> is relatively easy to provide a backward-compatible ABI. There
>>> should be
>>>>>> a reserved subtype for "other" that can be encoded in the
>>>>>> existing
>>> field
>>>>>> for use when the subtype can't fit in the old field. This seems
>>>>>> much
>>>>>> easier,
>>>>>> can be KPI compatible, and will make it much easier to backport
>>> drivers.
>>>>>> A backport could simply define the new subtypes as "other", and
>>>>>> the
>>> KPI
>>>>>> would still be compatible.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> Mike
>>>
>>>> --
>>>> John Baldwin
>>>
>>> Mike
>>>
>> _______________________________________________
>> freebsd-net at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to
>> "freebsd-net-unsubscribe at freebsd.org"
>
>
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to
> "freebsd-arch-unsubscribe at freebsd.org"
More information about the freebsd-arch
mailing list