lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 19 Apr 2008 18:33:41 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	dwmw2@...radead.org
Cc:	kay.sievers@...y.org, md@...ux.it, harald@...hat.com,
	linux-hotplug@...r.kernel.org, netdev@...r.kernel.org,
	schwidefsky@...ibm.com
Subject: Re: [PATCH] Expose netdevice dev_id through sysfs

From: David Woodhouse <dwmw2@...radead.org>
Date: Mon, 14 Apr 2008 13:32:02 +0100

> Expose dev_id to userspace, because it helps to disambiguate between
> interfaces where the MAC address is unique.
> 
> Signed-off-by: David Woodhouse <dwmw2@...radead.org>

As far as I can tell there is only one driver, s390's qeth, even
setting netdev->dev_id.

And this driver is providing netdev->dev_id uniqueness amongst qeth
device instances.

But that's not the problem we're trying to solve.

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.

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

We therefore need a more concrete and workable plan to resolve
this issue.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ