linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sergey Vlasov <vsu@altlinux.ru>
To: linux-hotplug@vger.kernel.org
Subject: Re: [RESEND] [PATCH] by-path persistence for NICs
Date: Wed, 14 Feb 2007 20:55:20 +0000	[thread overview]
Message-ID: <20070214235520.7f9dac3b.vsu@altlinux.ru> (raw)
In-Reply-To: <45D25492.6050203@kadzban.is-a-geek.net>


[-- Attachment #1.1: Type: text/plain, Size: 1895 bytes --]

On Wed, 14 Feb 2007 12:49:36 -0500 Bryan Kadzban wrote:

> On Wed, Feb 14, 2007 at 11:22:45AM +0100, Marco d'Itri wrote:
> > USB paths change frequently.
>
> You're right, rats.  So would paths for other removable devices.
>
> Well, I'm not sure whether that's a showstopper, but I think it probably
> is.  I was only thinking about PCI hardware and what happens when a NIC
> dies and is replaced.  With MAC-based persistence, the MAC address in
> the generated rules file needs to be changed to the new NIC's MAC before
> the new NIC is inserted, otherwise the system's configuration (e.g. the
> config files for the distro's network boot script) is invalid.

Even worse, sometimes you need to change MAC to the value from the old
card, because someone dumb at the other end configured static ARP
entries supposedly to increase security, and it is easier to change
the MAC locally than to make the other end update its config.  Then
you need to have rules both for the new and the old MAC (the latter
for the case when the device is processed by udev again for some
reason).

> But that's not as big of a deal as forcing the user to use the same USB
> port (or more accurately, the same physical path) all the time.
>
> > Anyway it must not be the default.
>
> It's not the default (in that patch anyway), but from what you said
> about it not working for anything removable, it sounds like it's not a
> good idea in any case.  I think this kind of persistence would fail more
> often than MAC-based persistence does.
>
> So: Retracted, unless someone wants to pick it up even with this issue.
> There's no way around the problem either.

It could be possible to detect the device type and use different
persistence methods for different kinds of devices.

And the first part of the patch (path_id change to support network
devices) could be useful by itself at least for manual configuration.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 226 bytes --]

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

      parent reply	other threads:[~2007-02-14 20:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-14  0:15 [RESEND] [PATCH] by-path persistence for NICs Bryan Kadzban
2007-02-14 10:22 ` Marco d'Itri
2007-02-14 17:49 ` Bryan Kadzban
2007-02-14 20:55 ` Sergey Vlasov [this message]

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=20070214235520.7f9dac3b.vsu@altlinux.ru \
    --to=vsu@altlinux.ru \
    --cc=linux-hotplug@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;
as well as URLs for NNTP newsgroup(s).