mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Robert P. J. Day" <rpjday@mindspring.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: ok to kill "ether=" kernel parm?
Date: Tue, 28 Aug 2007 13:58:05 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0708281347390.20783@localhost.localdomain> (raw)
In-Reply-To: <46D45A02.6010306@zytor.com>

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
========================================================================

  reply	other threads:[~2007-08-28 18:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-28  7:08 Robert P. J. Day
2007-08-28 16:45 ` H. Peter Anvin
2007-08-28 17:03   ` Robert P. J. Day
2007-08-28 17:23     ` H. Peter Anvin
2007-08-28 17:58       ` Robert P. J. Day [this message]
2007-08-28 18:51         ` Alexey Dobriyan
2007-08-29 14:35         ` Denys Vlasenko
2007-08-29 14:28           ` Robert P. J. Day
2007-08-28 18:12       ` Jan Engelhardt
2007-08-28 18:43 H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0708281347390.20783@localhost.localdomain \
    --to=rpjday@mindspring.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®