lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 28 Aug 2007 13:58:05 -0400 (EDT)
From:	"Robert P. J. Day" <rpjday@...dspring.com>
To:	"H. Peter Anvin" <hpa@...or.com>
cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: ok to kill "ether=" kernel parm?

On Tue, 28 Aug 2007, H. Peter Anvin wrote:

> Robert P. J. Day wrote:
> > On Tue, 28 Aug 2007, H. Peter Anvin wrote:
> >
> >> Robert P. J. Day wrote:
> >>>   given that "ether=" has been officially obsolete since 2.6.18
> >>> (replaced by "netdev="), is there any reason to keep it around?
> >>> or can it be blasted?
> >> That sounds like way too short of a timeline for breaking people's
> >> working boot setup.  For a lot of people, 2.6.18->current is going
> >> to be a single step.
> >
> > actually, now that i look more closely at the code browser at
> > lxr.linux.no, "ether=" has been listed as "obsolete" since *at least*
> > 2.6.10.  not to sound unsympathetic but anyone who tries to jump from
> > 2.6.10 to 2.6.24 in one step deserves what they get.  :-)
> >
> > ok, that was cruel, but you see my point, right?
>
> Yes, and I think it's quite pointless.
>
> The thing is, people's boot setups have probably been that way since
> *long* before 2.6.9.  They continue to work, as they should, so they
> aren't changed.  This is why we very rarely break boot interfaces
> (and this is a user-visible interface you're talking about); we're
> still supporting interfaces that have been obsolete *SINCE BEFORE
> 1.0 WAS RELEASED.*
>
> What's the upside of changing?  What's the downside?  The upside is
> so infinitesimal that that leaving "ether=" in indefinitely seems
> like a good move to me.

i've never found these "well, it's not hurting anything" arguments
terribly compelling.  if that's the case, why remove *anything* from
the kernel?  why obsolete *anything*?  but that's not my actual point.

why continue to support two different ways to do the same thing?  in
situations like that, i can imagine the following (admittedly
hypothetical) conversation between old-timer and young geek:

OT:  "so, what the problem?"
YG:  "i can't get my network module to work properly.  i use modprobe
with netdev= and ..."
OT:  "huh?  netdev?  why don't you use ether=?"
YG:  "what's ether=?"
OT:  "what's netdev=?"

followed by a confused conversation as to whether they really
represent the same thing, or maybe not, or maybe mostly.

if you want to keep the old way of doing it, that's cool.  but it
would be nice if, in cases like that, a clear choice was made.  if you
want to keep the old way, then *keep* it.  make it clear that it's
official, and supported.

or if you're going to delete it, then *delete* it.  but let's not keep
doing this half-way, half-assed measure of tagging something as
obsolete, then just letting it hang out in the kernel forever.  either
keep it, or delete it, and stop being so wishy-washy and doing things
halfway.

and, finally, while "there's more than one way to do it" may be a
terrific perl philosophy, i don't think much of it as a kernel coding
standard.

anyway, my $0.02, for what little it's worth.

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca
========================================================================
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ