Date: Tue, 6 Jan 2015 16:09:24 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Eric Joyner <erj@erj.cc> Cc: mike@karels.net, Rui Paulo <rpaulo@me.com>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, John Baldwin <john@baldwin.cx>, Jack Vogel <jfvogel@gmail.com>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: Adding new media types to if_media.h Message-ID: <CAJ-Vmon9LjYTuP7ubiJ=UzmSFUaNPuAjDTbaf4QhJ58YqbfZRQ@mail.gmail.com> In-Reply-To: <CA%2Bb0zg9ZiGiVQvLyOmO40_8qwtLU1z3RPW4xjZ16qTQcXZAEPA@mail.gmail.com> References: <2116096.l1vR0RuKRU@ralph.baldwin.cx> <201412130106.sBD16tgl072730@mail.karels.net> <CA%2Bb0zg9ZiGiVQvLyOmO40_8qwtLU1z3RPW4xjZ16qTQcXZAEPA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 6 January 2015 at 14:50, Eric Joyner <erj@erj.cc> wrote: > 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. Well, my idea is that there's parts of ifmedia that's related to the interface state that we care about, and some of it is just presentation related stuff that's opaque to the stack and only relevant for userland and for the driver/phy bits. The tricky bit is breaking the ifmedia API. It's not included as a pointer inside things - it's embedded as an actual struct. It's embedded inside net80211, but other than that and if_lagg I think it's mostly done inside drivers. So maybe we want to turn its use into allocate/free rather than embedded inside the struct; maybe we don't. Second is how we split up the bits that are mediatype-dependent versus the bits that are related to the network stack. My idea is just to break out each ifmedia field into an int each: * if_media Options word: * Bits Use * ---- ------- * 0-4 Media variant * 5-7 Media type * 8-15 Type specific options * 16-18 Mode (for multi-mode devices) * 19 RFU * 20-27 Shared (global) options * 28-31 Instance .. because I think it'll be easier in the long run to just have uint32_t fields for each of these. The general network stack shouldn't care about type, options and mode. It'll be a lot of churn, but I think it's cleaner than trying to continue doing dirty bitmap things. So: * do we break ifmedia use up into a pointer / allocated thing, rather than an embedded struct, with all the driver churn that'll entail; * do we just add a new field for type/options and have a magic type that's "other", or do we just go for breaking each option out into a field in a struct and have accessor methods to get access to things. What do people think? -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmon9LjYTuP7ubiJ=UzmSFUaNPuAjDTbaf4QhJ58YqbfZRQ>