public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dale Amon <amon@vnl.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Dale Amon <amon@vnl.com>, linux-kernel@vger.kernel.org
Subject: Re: A return to PCI ordering problems...
Date: Tue, 20 Nov 2001 21:47:05 +0000	[thread overview]
Message-ID: <20011120214705.D22590@vnl.com> (raw)
In-Reply-To: <20011120190316.H19738@vnl.com> <2048.1006291657@redhat.com>
In-Reply-To: <2048.1006291657@redhat.com>

On Tue, Nov 20, 2001 at 09:27:37PM +0000, David Woodhouse wrote:
> Why must the motherboard be set to eth0? Why not just configure it as it
> gets detected?

There are a couple reasons. One that is specific to this
particular case is that the VeryExpensiveProprietaryPackage
someone bought checks the eth0 MAC address to be sure you
haven't moved it. It would not really be smart to license
it against a removable, swappable PCI card.

In general: I have more than once gotten bitten late
in the night modifying kernels where I switched something
from modular to non-modular and lost communication with
the machine when it came back up. At 4am these things *do*
happen.

I'd really not mind the ability to say MAC addresss X is
by definition ethY. That would work for me because the only
way you get screwed is if you change the NIC. And if you
are swapping out hardware, you are usually physically present
to sort things out if your network gets effed.

> If you really care about the names, there's an ioctl you can use to change
> them. You can call them 'fred' and 'sheila' if you so desire.

The iproute2 commands another fellow mentioned look
like they will do the job nicely for my particular
immediate problem.

In the more general case though, I can see a need to
explicitely force or override assignments in special 
circumstances.

--
------------------------------------------------------
    Nuke bin Laden:           Dale Amon, CEO/MD
  improve the global          Islandone Society
     gene pool.               www.islandone.org
------------------------------------------------------


  reply	other threads:[~2001-11-20 21:42 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-20 19:03 A return to PCI ordering problems Dale Amon
2001-11-20 20:03 ` Richard B. Johnson
2001-11-20 19:51   ` Tim Hockin
2001-11-20 20:13   ` Faux Pas III
2001-11-20 21:20   ` Dale Amon
2001-11-20 21:58     ` Andreas Dilger
2001-11-20 21:49   ` David Woodhouse
2001-11-20 22:02     ` Dale Amon
2001-11-20 22:04       ` Richard B. Johnson
2001-11-20 21:27 ` David Woodhouse
2001-11-20 21:47   ` Dale Amon [this message]
2001-11-21  9:27     ` Helge Hafting
2001-11-21 12:52     ` Christer Weinigel
2001-11-21  8:57   ` James A Sutherland
2001-11-21  9:20     ` Alan Cox
2001-11-21 11:29     ` Henning P. Schmiedehausen
2001-11-21 11:53       ` Christoph Hellwig
2001-11-21 12:10         ` Henning P. Schmiedehausen
2001-11-21 13:51       ` James A Sutherland

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=20011120214705.D22590@vnl.com \
    --to=amon@vnl.com \
    --cc=dwmw2@infradead.org \
    --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