From owner-svn-src-head@FreeBSD.ORG Wed Jan 5 23:27:21 2011 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22FF51065670; Wed, 5 Jan 2011 23:27:21 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 6F2D68FC0C; Wed, 5 Jan 2011 23:27:20 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p05NRJAG098966; Thu, 6 Jan 2011 00:27:19 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p05NRJ5Z098965; Thu, 6 Jan 2011 00:27:19 +0100 (CET) (envelope-from marius) Date: Thu, 6 Jan 2011 00:27:18 +0100 From: Marius Strobl To: "Bjoern A. Zeeb" Message-ID: <20110105232718.GB97101@alchemy.franken.de> References: <201101051528.p05FSVPL082696@svn.freebsd.org> <20110105153107.X14966@maildrop.int.zabbadoz.net> <20110105155513.GA97101@alchemy.franken.de> <20110105185451.W14966@maildrop.int.zabbadoz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110105185451.W14966@maildrop.int.zabbadoz.net> User-Agent: Mutt/1.4.2.3i Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r217013 - in head: sbin/ifconfig sys/net X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 23:27:21 -0000 On Wed, Jan 05, 2011 at 07:09:10PM +0000, Bjoern A. Zeeb wrote: > On Wed, 5 Jan 2011, Marius Strobl wrote: > > >On Wed, Jan 05, 2011 at 03:34:30PM +0000, Bjoern A. Zeeb wrote: > >>On Wed, 5 Jan 2011, Marius Strobl wrote: > >> > >>>Author: marius > >>>Date: Wed Jan 5 15:28:30 2011 > >>>New Revision: 217013 > >>>URL: http://svn.freebsd.org/changeset/base/217013 > >>> > >>>Log: > >>>Teach ifconfig(8) the handy shared option shortcut aliases the NetBSD > >>>counterpart also takes, i.e. "fdx" for "full-duplex", "flow" for > >>>"flowcontrol", "hdx" for "half-duplex" as well as "loop" and "loopback" > >>>for "hw-loopback". > >> > >>I am not sure this is a good idea. Unless this is really really > >>useful for compatibility with scripts (which I doubt) it'll sooner or > >>later cause headaches, especially given some of the (new) names could > >>be very well used for different things as well. > > > >Could you please elaborate on what different use you have in mind? > >Generally it seems a bad idea to me if the existing options and the > >new names as implemented would trigger different things as you suggest > >given the latter are rather common abbreviations as well as diverging > >from the user interface of the other BSDs seems like a bad idea (i.e. > >not only not supporting the same names they do but also controlling > >different things with a given one). Also the concept of aliases taken > >by ifconfig(8) isn't new, we support several including f.e. "auto" for > >"autoselect" for quite some time. > > "flow" is a term used at other layers as well and really different to > flow control. We are not only seeing discussions about flowid usage > in IPv6 but also people trying to control "ULP flows" on NICs (RSS). > > loop and loopback sound bad as well, especially as I could only see > one man page in man4 (tl.4) that actually references it. If you grep for IFM_LOOP in sys/dev you'll see that several MAC and PHY drivers support it an that the man pages of MAC drivers that use mii(4) like f.e. tl(4) does are actually the wrong place to document this given that the media is primarily handled by the PHY drivers in that case (hence no match in sys/dev/tl). > > My worries are just that people will confuse those things with other > options outside of media-opts. IMO that risk is rather low as long as the verb is tied to an option like f.e. "mode" or in this case "mediaopt". > > I guess I have no problem with fdx and hdx but you will see a mix > other either showing up then in scripts and man pages and that'll give > an incosistent view to users and confuse them as well (especially > since those options are all descriped with the driver's man pages > rather than having a global list [if needed with aliases] in ifconfig > then refering to the driver man pages to see which of those a driver > actually supports). Yes, actually we are very bad at documenting the media and media options; several of the man pages of MAC drivers using mii(4) are outdated and as outlined above technically it makes no sense to document these there. Even if we had man pages for the PHY drivers it would be next to impossible to document the media and media options there correctly as PHY drivers generally determine these dynamically an there are f.e. low-cost variants of MACs supported by bge(4) but limited to Fast Ethernet equipped with Gigabit PHYs. So what I would prefer instead would be one central place similar to the NetBSD and OpenBSD ifmedia.4 describing the media and media options and how to set them with ifconfig(8) and in the man pages of the MAC drivers then just reference ifmedia.4 and tell them to check the output of `ifconfig -m foo0` to check what a given interface actually supports. > > To give you an example -- "add" is an alias for "alias" with inet, and > people are writing alias where add should be (different places on the > command line) which leads to confusion as it shouldn't work there and > doesn't for IPv6. Much confusion for years. > Well, without a command line example this is a bit hard to follow but it sounds like the real problem here is the inconsistency between the IPv6 and non-IPv6 cases and maybe that in one place ifconfig(8) shouldn't accept "alias" even in the non-IPv6 case. Generally one can take the argument about inconsistency leading to user confusion into different directions. F.e. users also have complained loudly about the fact the FreeBSD requires (or required?) a netmask of 0xffffffff for IPv4-aliases while the other BSDs and Linux as well as apparently every other system one can configure an alias address on uses the same netmask for the alias as for the primary address (which also is sheer intuitive). Yet, another inconsistency is that in dmesg mii(4) announces the autoselect media as "auto" and the media options {full,half}-duplex as {F,H}DX (and recently also flow-control as "flow") which don't translate to (non-alias) verbs understood by ifconfig(8). IMO r217013 thus actually reduces existing inconsistencies and thus potentially user confusions between OSes and within FreeBSD itself while you arguing with possible future inconsistency if we make the mistake to name new ifconfig(8) options for different things the same as others have already chosen for existing functionality before. Marius