Date: Wed, 25 Feb 2015 20:58:20 -0600 From: Mike Karels <mike@karels.net> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, Eric Joyner <ricera10@gmail.com>, 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: <201502260258.t1Q2wKNK054143@mail.karels.net> In-Reply-To: Your message of Thu, 26 Feb 2015 01:50:51 %2B0300. <20150225225051.GE17947@glebius.int.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Wed, Feb 25, 2015 at 02:42:16PM -0800, Eric Joyner wrote: > E> Tbh, I respect Gleb's approach, but developing such a thing would take a > E> while; the fix Mike proposed would be a fix now. > E> > E> I mean, I'd like to see a decoupling of media types and speeds from > E> "standard" names, and maybe have both an ability to query what modules a > E> device supports and what speeds it supports given its current module, > E> instead of relying on the clunky media type list now. And then it'd be nice > E> to set flow control from ifconfig, too, without having to couple those > E> modes to media types. I'm still all for having a new system in the future. > E> > E> But in changing the KPI so much, it'd be important to consider the "do we > E> need an ethtool-equivalent" discussion. > E> > E> And I think we've lost a bunch of people who were in the original > E> discussion from the to:/cc: list. > Actually the amount of code for my approach is approximately the same > as with Mike's. The only thing we must sit down and think without a hurry > are the required and spare fields for new if_media. We definitely need > input from Adrian on his net80211 requirements, and input from all involved > parties. I'm not sure what would be different about your approach; you mentioned "n" versions rather than "x" versions of the ioctls, but I don't know what you have in mind for encoding. Any compatible version would be limited to int. In terms of a "real" fix ("ripping the bandaid off"), I think that if_media is basically wrong, and widening it won't fix it. There should be a generic structure that reports the media type (e.g. Ethernet), perhaps the speed and some generic status ("active"). Then there should be media-specific structures that encode the appropriate things including attachment type. 802.11 apparently already has an extension, and Ethernet should have a similar extension. The KPI should be media-type-specific. I don't see something like this being designed soon, and certainly wouldn't be able to be MFC'd. Meanwhile, many of us need to support 40 Gb/s Ethernet on non-current (or non-future) systems. > I'm willing to code this if we all agree on the topic, so that you will > code all done and commited before 10.2-RELEASE. I'd be interested in a sketch or more extended description sometime before 10.2. Back on the subject of the review: the VFAST entries should be removed, and the other entries should be moved down. Mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201502260258.t1Q2wKNK054143>