From: Andrey Borzenkov <arvidjaar@mail.ru>
To: linux-hotplug@vger.kernel.org
Cc: David Miller <davem@davemloft.net>,
dwmw2@infradead.org, kay.sievers@vrfy.org, md@linux.it,
harald@redhat.com, netdev@vger.kernel.org,
schwidefsky@de.ibm.com
Subject: Re: [PATCH] Expose netdevice dev_id through sysfs
Date: Sun, 20 Apr 2008 09:21:03 +0400 [thread overview]
Message-ID: <200804200921.09072.arvidjaar@mail.ru> (raw)
In-Reply-To: <20080419.183341.46125500.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1418 bytes --]
On Sunday 20 April 2008, David Miller wrote:
> We're trying to provide uniqueness amongst all devices in the system
> that are using the same MAC address.
>
> On a Sparc system, for example, ethernet chips driven by several
> different drivers can end up with the same MAC address, as the
> system IDPROM specified ethernet MAC is what will be used by
> default.
>
On Sparc system we also have global device tree which provides unique
and persistent reference to every device. Solaris has no problems with
having same MAC for all interfaces.
> So we need some global scheme. And this dev_id value would need to be
> persistent. As best as I can tell, such things aren't available.
What is exactly wrong with using device topology path? This should exist
on any system, it is unique and it is persistent.
> Sure we could do something silly like use the device I/O physical
> address, but that would defeat the whole purpose of making device
> identification agnostic to I/O bus geography. I could move the
> card to a different slot and it would have a different dev_id.
>
Sure; a card in different slot *is* a different device. And when broken
card is replaced in the same slot for all practical purposes it *is* the
same device even if MAC has changed.
Nobody makes cable labels like "card with MAC xxx"; every cable label has
something like "shelf 2; PCI slot 3; port 1".
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
next prev parent reply other threads:[~2008-04-20 5:21 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <ftdb3v$tls$1@ger.gmane.org>
[not found] ` <20080407143805.GA9492@bongo.bofh.it>
2008-04-14 10:08 ` udev can't name PS3's network devices correctly David Woodhouse
2008-04-14 11:11 ` David Woodhouse
2008-04-14 11:55 ` Kay Sievers
2008-04-14 12:32 ` [PATCH] Expose netdevice dev_id through sysfs David Woodhouse
2008-04-20 1:33 ` David Miller
2008-04-20 5:21 ` Andrey Borzenkov [this message]
2008-04-20 5:32 ` David Miller
2008-04-20 10:50 ` David Woodhouse
2008-04-20 10:55 ` David Miller
2008-04-20 11:12 ` David Woodhouse
2008-04-20 11:14 ` David Miller
2008-04-20 11:22 ` David Woodhouse
2008-04-27 17:37 ` udev can't name PS3's network devices correctly David Woodhouse
2008-04-27 18:28 ` Kay Sievers
2008-04-14 12:03 ` Kay Sievers
2008-04-14 12:19 ` David Woodhouse
2008-04-14 12:52 ` Kay Sievers
2008-04-14 13:16 ` David Woodhouse
2008-04-14 12:51 ` Marco d'Itri
2008-04-14 13:38 ` David Woodhouse
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=200804200921.09072.arvidjaar@mail.ru \
--to=arvidjaar@mail.ru \
--cc=davem@davemloft.net \
--cc=dwmw2@infradead.org \
--cc=harald@redhat.com \
--cc=kay.sievers@vrfy.org \
--cc=linux-hotplug@vger.kernel.org \
--cc=md@linux.it \
--cc=netdev@vger.kernel.org \
--cc=schwidefsky@de.ibm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.