linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bob Copeland <me@bobcopeland.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Ben Greear <greearb@candelatech.com>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: question on "mac80211_hwsim: support any address in userspace"
Date: Wed, 16 Dec 2015 09:59:33 -0500	[thread overview]
Message-ID: <20151216145933.GE4073@localhost> (raw)
In-Reply-To: <1450275340.8247.18.camel@sipsolutions.net>

On Wed, Dec 16, 2015 at 03:15:40PM +0100, Johannes Berg wrote:
> On Wed, 2015-12-16 at 06:11 -0800, Ben Greear wrote:
> 
> > My code expected that the key was the MAC of the radio, not the
> > MAC of a vif.  It set up mappings accordingly in the user-space
> > program.
> 
> I guess you were trying to be much smarter than wmediumd :)
> 
> Bob, any thoughts?

So, now that I understand the argument, I see the value in having
an unchanging key for each phy.  I'm also pretty sure that it was by
accident that it used to work that way.  If we were designing the ABI
from scratch, radio id would probably be better than a mac address for
that purpose.

Anyway, in the interest of not breaking userspace, I'm not opposed to
reverting that patch, and perhaps adding some documentation on top to make
it clear that the addr attributes have nothing to do with any mac addresses
actually in use.

For wmediumd users that would mean going back to the way it was previously,
in which only the 42:xx mac addresses will work, until I can work out another
way to do it.  I think that would break the test_wmediumd.py in hostapd
test suite in the meantime though.

-- 
Bob Copeland %% http://bobcopeland.com/

  reply	other threads:[~2015-12-16 14:59 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-16  3:29 question on "mac80211_hwsim: support any address in userspace" Ben Greear
2015-12-16  9:17 ` Johannes Berg
2015-12-16 13:13   ` Ben Greear
2015-12-16 13:25     ` Johannes Berg
2015-12-16 13:35       ` Ben Greear
2015-12-16 13:42         ` Johannes Berg
2015-12-16 14:11           ` Ben Greear
2015-12-16 14:14             ` Johannes Berg
2015-12-16 14:15             ` Johannes Berg
2015-12-16 14:59               ` Bob Copeland [this message]
2015-12-16 15:52                 ` Ben Greear
2015-12-16 17:30           ` Adam R. Welle
2015-12-16 17:46             ` Bob Copeland
2015-12-16 18:57               ` Adam R. Welle
2015-12-16 22:14             ` Ben Greear
2015-12-16 22:56               ` Adam R. Welle
2015-12-16 23:20                 ` Ben Greear
2015-12-16 23:56                   ` Adam R. Welle
2015-12-17 13:26               ` Bob Copeland
2015-12-16 13:21 ` me@bobcopeland.com >> Bob Copeland
2015-12-16 13:27   ` Ben Greear
2015-12-16 13:57     ` me@bobcopeland.com >> Bob Copeland
2015-12-16 14:16       ` Ben Greear
2015-12-16 14:33         ` me@bobcopeland.com >> Bob Copeland

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=20151216145933.GE4073@localhost \
    --to=me@bobcopeland.com \
    --cc=greearb@candelatech.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@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).