mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Joachim Breuer <jmbreuer@gmx.net>
To: Robert Love <rml@tech9.net>
Cc: "Andrew Morton" <akpm@zip.com.au>,
	"christophe barbé" <christophe.barbe.ml@online.fr>,
	"Marcelo Tosatti" <marcelo@conectiva.com.br>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] 3c59x and resume
Date: Mon, 25 Mar 2002 12:34:18 +0100	[thread overview]
Message-ID: <m3r8m851ad.fsf@venus.fo.et.local> (raw)
In-Reply-To: <20020323161647.GA11471@ufies.org> <3C9CCBEB.D39465A6@zip.com.au> <1016914030.949.20.camel@phantasy>

Robert Love <rml@tech9.net> writes:

> On Sat, 2002-03-23 at 13:39, Andrew Morton wrote:
>
>> in modules.conf, and we really have eight NICS, and they're
>> being plugged and unplugged, how can we reliably associate
>> that option with the eight cards?  So the right option is
>> applied to each card eash time it's inserted?  Should the
>> option be associated with a card, or with a bus position?
>
> Ugh, not pretty.
>
> Associate it with the bus position I'd say?

I don't know wherewith the <i> in eth<i> is associated (bus pos or
maybe linear ordering of the MAC addresses or somesuch), but I would
expect a selected combination of eth<i> userland configuration (IP
address, netmask) and driver level configuration (WOL, ...) to remain
stable.

Being able to redetect a pulled card put in a different slot as a
"known" one giving it the same eth<i> (and associated WOL etc. config)
as before would of course be nice, but I can't see how this can be
cleanly done over reboots.

With bus pos you get a lesser variant of the "SCSI disk association
problem", i.e. inserting an eth card in an empty slot between other
eth cards moves at least some of the others (I'm not sure, but I think
this would be the current behaviour. - Over reboots, not in the
hot-plug case, of course).

I wouldn't mind if the <i> in eth<i> was somehow derived from the
phy. bus pos; so I'd maybe have eth3 and eth7 and if I plugged another
one it could be eth4. That way I'd only have to worry about the cards
"wandering" around when changing/drastically reconfiguring (BIOS
update?) the motherboard.

To cut a lengthy dogfight short most of that useful functionality
could be had by indexing the eth configure scripts over, say, MAC
address instead of eth<i>; that way I'd have to touch the config when
exchanging the card against a different one; but no others would
decide to move around no matter what. OK, so there might be b0rked
cards with unusable MACs out there, but for the applications I have in
mind I wouldn't use those, anyway.

(All this comes to mind because in my PFY days I had to fight with a
firewall which, after card change (might even have been driver load
order, can't remember whether it was the same driver for all 3 cards)
shifted eth<i> in a most, ah, undesirable fashion.)


So long,
   Joe

-- 
"I use emacs, which might be thought of as a thermonuclear
 word processor."
-- Neal Stephenson, "In the beginning... was the command line"

  parent reply	other threads:[~2002-03-25 11:35 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-23 16:16 christophe barbé
2002-03-23 18:39 ` Andrew Morton
2002-03-23 20:06   ` Robert Love
2002-03-23 22:44     ` christophe barbé
2002-03-24  8:07       ` Greg KH
2002-03-24 14:25         ` christophe barbé
2002-03-25 18:01           ` Greg KH
2002-03-25 18:19             ` christophe barbé
2002-03-25 19:11               ` Greg KH
2002-03-25 20:27                 ` christophe barbé
2002-03-25 20:58                 ` christophe barbé
2002-03-25 11:34     ` Joachim Breuer [this message]
2002-03-25 11:53       ` Xavier Bestel
2002-03-25 21:31         ` Joachim Breuer
2002-03-25 19:44     ` Bill Davidsen
2002-03-25 20:16       ` christophe barbé
2002-03-26  0:57 ` Jeff Garzik
2002-03-26  1:40   ` christophe barbé
2002-03-26  4:10     ` Jeff Garzik
2002-03-26  4:39       ` christophe barbé
2002-03-26  4:50         ` Andrew Morton
2002-03-26 16:56           ` christophe barbé
2002-03-26 16:57             ` Jeff Garzik

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=m3r8m851ad.fsf@venus.fo.et.local \
    --to=jmbreuer@gmx.net \
    --cc=akpm@zip.com.au \
    --cc=christophe.barbe.ml@online.fr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo@conectiva.com.br \
    --cc=rml@tech9.net \
    /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®