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