Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 6 Jan 2011 00:27:18 +0100
From:      Marius Strobl <marius@alchemy.franken.de>
To:        "Bjoern A. Zeeb" <bz@FreeBSD.org>
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
Message-ID:  <20110105232718.GB97101@alchemy.franken.de>
In-Reply-To: <20110105185451.W14966@maildrop.int.zabbadoz.net>
References:  <201101051528.p05FSVPL082696@svn.freebsd.org> <20110105153107.X14966@maildrop.int.zabbadoz.net> <20110105155513.GA97101@alchemy.franken.de> <20110105185451.W14966@maildrop.int.zabbadoz.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110105232718.GB97101>