Prev: wm8960: fix compile error
Next: sysfs: add entry to indicate network interfaces with random MAC address
From: David Miller on 20 Jul 2010 17:30
From: Stephen Hemminger <shemminger(a)vyatta.com>
Date: Tue, 20 Jul 2010 14:18:16 -0700

> No one mentioned that the first octet of an Ethernet address already
> indicates "software generated" Ethernet address. Per the standard,
> if bit 1 is set it means address is locally assigned.
>
> static inline bool is_locally_assigned_ether(const u8 *addr)
> {
> return (addr[0] & 0x2) != 0;
> }

W00t!

Indeed, can udev just use that? :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: David Miller on 21 Jul 2010 02:40
From: Harald Hoyer <harald(a)redhat.com>
Date: Wed, 21 Jul 2010 08:26:27 +0200

> On 07/20/2010 11:20 PM, David Miller wrote:
>> From: Stephen Hemminger<shemminger(a)vyatta.com>
>> Date: Tue, 20 Jul 2010 14:18:16 -0700
>>
>>> No one mentioned that the first octet of an Ethernet address already
>>> indicates "software generated" Ethernet address. Per the standard,
>>> if bit 1 is set it means address is locally assigned.
>>>
>>> static inline bool is_locally_assigned_ether(const u8 *addr)
>>> {
>>> return (addr[0]& 0x2) != 0;
>>> }
>>
>> W00t!
>>
>> Indeed, can udev just use that? :-)
>
> It already does:
> see /lib/udev/rules.d/75-persistent-net-generator.rules

So... why doesn't this work?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Ben Hutchings on 21 Jul 2010 10:00
On Wed, 2010-07-21 at 10:10 +0200, Stefan Assmann wrote:
> On 20.07.2010 22:18, David Miller wrote:
> > From: Stefan Assmann <sassmann(a)redhat.com>
> > Date: Tue, 20 Jul 2010 14:17:30 +0200
> >
> >> On 20.07.2010 13:58, Alex Badea wrote:
> >>> Hi,
> >>>
> >>> On 07/20/2010 02:47 PM, Stefan Assmann wrote:
> >>>>> What about devices that 'steal' MAC addresses from slave devices?
> >>>
> >>> Might I suggest an attribute such as "address_type", which could report
> >>> "permanent", "random", "stolen", or something else in the future?
> >>
> >> In case there's demand for such a multi-purpose attribute I see no
> >> reason to object. More thoughts on this?
> >
> > I think this is a great idea.
> >
> > Now it makes sense to use a new 'u8' in struct netdevice or similar to
> > store this, since we'll have more than a boolean here.
> >
>
> I put Alex' idea into code for further discussion, keeping the names
> mentioned here until we agree on the scope of this attribute. When we
> have settled I'll post a patch with proper patch description.
[...]

Just a little nitpick: I think it would be clearer to use a more
specific term like 'address source' or 'address assignment type' rather
than 'address type'.

Ben.

--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Stephen Hemminger on 21 Jul 2010 13:30
On Wed, 21 Jul 2010 09:34:27 -0700
Casey Leedom <leedom(a)chelsio.com> wrote:

> | From: Andy Gospodarek <andy(a)greyhouse.net>
> | Date: Wednesday, July 21, 2010 08:07 am
> |
> | Agreed. The subtle difference between a locally assigned address that
> | is persistent and one that is random would be helpful.
>
> And just to point out that this case _does_ exist: the igb/igbvf drivers use
> random_ether_addr() to generate a random, locally assigned MAC address for the
> PCI-E SR-IOV Virtual Function MAC Addresses while the cxgb4/cxgb4vf drivers use
> a persistent, non-random locally assigned MAC Addresses.
>
> Note that I am neither arguing for nor against the proposal. I'm just
> pointing out an existence case for the distinction. And yes, bit 1 being set in
> the first octet of a MAC address for locally assigned MAC Addresses is part of
> the IEEE 802 specification just as bit 0 being set in the same octet indicates
> that it's a multi-station address.

IMHO no local assigned address should be used by udev. The cxgb4 driver
should be using random value.

Does anyone have an example of locally assigned address that has persistence
so that udev could use it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: David Miller on 21 Jul 2010 13:40
From: Stephen Hemminger <shemminger(a)vyatta.com>
Date: Wed, 21 Jul 2010 10:28:16 -0700

> IMHO no local assigned address should be used by udev. The cxgb4 driver
> should be using random value.
>
> Does anyone have an example of locally assigned address that has persistence
> so that udev could use it.

The cxgb4 vf addresses are not random because they are fetched from the
card's NVRAM/EEPROM/firmware/whatever and thus are persistent.

We definitely want udev to use persistent rules for them.

This whole issue only exists because of the Intel VF case, where it
lacks persistent addresses but somehow we want to assign persistent
names to it's VF interfaces.

One idea I've proposed in other discussions about this is that if the
address is not persistent (either via the MAC address bit or the sysfs
value we're thinking of providing here) we use the device's geographic
location ("device path") as the key for udev stuff.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: wm8960: fix compile error
Next: sysfs: add entry to indicate network interfaces with random MAC address