> 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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
