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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200708291535.41594.vda.linux@googlemail.com>
Date:	Wed, 29 Aug 2007 15:35:41 +0100
From:	Denys Vlasenko <vda.linux@...glemail.com>
To:	"Robert P. J. Day" <rpjday@...dspring.com>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: ok to kill "ether=" kernel parm?

On Tuesday 28 August 2007 18:58, Robert P. J. Day wrote:
> 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.

Add a printk("Deprecated, use netdev=xxx\n"); to the handler.
After 1-2 years you can remove ether=xxx.
--
vda
-
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