From owner-freebsd-net@FreeBSD.ORG Thu Feb 26 23:00:35 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D3FDB9F3; Thu, 26 Feb 2015 23:00:35 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5941F69D; Thu, 26 Feb 2015 23:00:34 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id t1QN0WMC031904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 Feb 2015 02:00:32 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id t1QN0Vxt031903; Fri, 27 Feb 2015 02:00:31 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 27 Feb 2015 02:00:31 +0300 From: Gleb Smirnoff To: Mike Karels Subject: Re: Adding new media types to if_media.h Message-ID: <20150226230031.GN17947@glebius.int.ru> References: <20150225225051.GE17947@glebius.int.ru> <201502260258.t1Q2wKNK054143@mail.karels.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201502260258.t1Q2wKNK054143@mail.karels.net> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-net@freebsd.org" , Eric Joyner , Jack Vogel , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 23:00:36 -0000 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.