netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Assmann <sassmann@redhat.com>
To: Ben Hutchings <bhutchings@solarflare.com>
Cc: netdev <netdev@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	davem@davemloft.net, Andy Gospodarek <gospo@redhat.com>,
	"Rose, Gregory V" <gregory.v.rose@intel.com>,
	"Duyck, Alexander H" <alexander.h.duyck@intel.com>,
	Casey Leedom <leedom@chelsio.com>,
	Harald Hoyer <harald@redhat.com>
Subject: Re: [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address
Date: Tue, 20 Jul 2010 14:41:15 +0200	[thread overview]
Message-ID: <4C45996B.3000003@redhat.com> (raw)
In-Reply-To: <1279627656.2110.13.camel@achroite.uk.solarflarecom.com>

On 20.07.2010 14:07, Ben Hutchings wrote:
> On Tue, 2010-07-20 at 13:47 +0200, Stefan Assmann wrote:
>> On 20.07.2010 13:20, Ben Hutchings wrote:
>>> On Tue, 2010-07-20 at 12:50 +0200, Stefan Assmann wrote:
>>>> From: Stefan Assmann <sassmann@redhat.com>

[snip]

>> Actually Dave Miller suggested to put it there. What other place is
>> there to put it?
> 
> If Dave said that then I'm sure it's OK.
> 
> However, if you define this as an interface flag (net_device::flags;
> <linux/if.h>) and add it to the set of changeable flags in
> __dev_change_flags(), user-space will be able to clear the flag if it
> later sets a stable address.

As I said I'm not that knowledgeable about this MAC address stealing
thing and I'm assuming that's what you're aiming at. Would you really
want/need it to be user-space writable? Currently all I can think of is
the scenario where you set a "stable" address that outlasts a reboot so
udev might be able to assign it a permanent name after it gets stable.

So it might make sense to have it writable, but I'd like to avoid to add
unnecessary complexity that may cause errors if it's not necessary.
Read-only is simple, just read the flag and deal with it.

Btw, the driver itself could also alter the flag. Then we'd have a well
defined way of setting a stable address.

  Stefan
--
Stefan Assmann         | Red Hat GmbH
Software Engineer      | Otto-Hahn-Strasse 20, 85609 Dornach
                       | HR: Amtsgericht Muenchen HRB 153243
                       | GF: Brendan Lane, Charlie Peters,
sassmann at redhat.com |     Michael Cunningham, Charles Cachera

> 
> Ben.
> 

  reply	other threads:[~2010-07-20 12:41 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-20 10:50 [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address Stefan Assmann
2010-07-20 11:20 ` Ben Hutchings
2010-07-20 11:47   ` Stefan Assmann
2010-07-20 11:58     ` Alex Badea
2010-07-20 12:17       ` Stefan Assmann
2010-07-20 20:18         ` David Miller
2010-07-21  8:10           ` Stefan Assmann
2010-07-21 13:54             ` Ben Hutchings
2010-07-22 12:50               ` [PATCH net-next] sysfs: add attribute to indicate hw address assignment type Stefan Assmann
2010-07-22 14:07                 ` Ben Hutchings
2010-07-22 14:47                   ` Stefan Assmann
2010-07-25  3:50                     ` David Miller
2010-07-20 12:07     ` [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address Ben Hutchings
2010-07-20 12:41       ` Stefan Assmann [this message]
2010-07-20 14:29         ` Ben Hutchings
2010-07-20 20:17           ` David Miller
2010-07-20 21:18             ` Stephen Hemminger
2010-07-20 21:20               ` David Miller
2010-07-21  6:26                 ` Harald Hoyer
2010-07-21  6:34                   ` David Miller
2010-07-21  6:47                     ` Harald Hoyer
2010-07-21 15:07                       ` Andy Gospodarek
2010-07-21 16:34                         ` Casey Leedom
2010-07-21 17:28                           ` Stephen Hemminger
2010-07-21 17:32                             ` David Miller
2010-07-21 18:29                               ` Casey Leedom
2010-07-21 18:39                                 ` David Miller
2010-07-21 19:25                                   ` Casey Leedom
2010-07-21 18:43                                 ` Rose, Gregory V
2010-07-21 18:48                                   ` David Miller
2010-07-21 18:50                                     ` David Miller
2010-07-21 19:02                                       ` Rose, Gregory V
2010-07-21 19:33                                         ` David Miller
2010-07-21 19:35                                           ` Rose, Gregory V
2010-07-22  7:12                                           ` Ian Campbell
2010-07-22  6:53                                   ` Stefan Assmann
2010-07-23  0:26                                     ` Casey Leedom
2010-07-23  8:08                                       ` Stefan Assmann
2010-07-23 16:35                                         ` Casey Leedom

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=4C45996B.3000003@redhat.com \
    --to=sassmann@redhat.com \
    --cc=alexander.h.duyck@intel.com \
    --cc=bhutchings@solarflare.com \
    --cc=davem@davemloft.net \
    --cc=gospo@redhat.com \
    --cc=gregory.v.rose@intel.com \
    --cc=harald@redhat.com \
    --cc=leedom@chelsio.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@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).