linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Denis Kenzior <denkenz@gmail.com>
To: Johannes Berg <johannes@sipsolutions.net>,
	James Prestwood <prestwoj@gmail.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	Dan Williams <dcbw@redhat.com>
Subject: Re: [RFC 0/1] Allow MAC change on up interface
Date: Tue, 20 Aug 2019 15:37:43 -0500	[thread overview]
Message-ID: <3313f0a7-2b38-9941-46bf-4c1a3e06a267@gmail.com> (raw)
In-Reply-To: <3fd41591acd55535863f11a0cc4f0f5f2afd5bdf.camel@sipsolutions.net>

Hi Johannes,

On 8/20/19 3:15 PM, Johannes Berg wrote:
> On Tue, 2019-08-20 at 14:58 -0500, Denis Kenzior wrote:
>>
>> But what actual complexity are we talking about here? If the kernel can
>> do this while the CONNECT is pending, why not?  It makes things simpler
>> and faster for userspace.  I don't see the downside unless you can
>> somehow objectively explain 'complexity'.
> 
> It's just extra code that we have to worry about. Right now you want it
> for CMD_CONNECT and CMD_AUTH. Somebody will come up with a reason to do
> it in CMD_ASSOC next, perhaps, who knows. Somebody else will say "oh,
> this is how it's done, so let's add it to CMD_JOIN_IBSS", because of
> course that's what they care about. OCB? Mesh? AP mode for tethering?
> Etc.

I don't buy the extra code argument.  If you want to do something useful 
you need to write 'extra code'.

The rest, I'm not sure why you are worried about them now?  For station 
there's a very clear & present use case.  If such a clear and present 
use case is presented for AP or Mesh, then deal with it then.

> 
> I don't see how this will not keep proliferating, and each new thing
> will come with its own dozen lines of code, a new feature flag, etc.

Such is life? :)

> 
> Relaxing and defining once and for all in which situations while the
> interface is up you can actually allow changing the address, and then
> having userspace do it that way is IMHO a better way to design the
> system, since it forgoes entirely all those questions of when and how
> and which new use cases will come up etc.
> 

That would be great in theory, but practically never works at least in 
my experience.  So maybe keep and open mind?  There is a clear need to 
make this path as fast as possible for STA.  There is no such need (yet) 
for the other cases you mentioned.

>> This was an RFC.  There isn't much point for us to cross all the 't's
>> and dot all the 'i's if you hate the idea in the first place.
> 
> Sure, but I cannot distinguish between "we only want it on CMD_CONNECT"
> and "we'll extend this once we agree" unless you actually say so. It'd
> help to communicate which t's and i's you didn't cross or dot.

Okay, I'll admit the RFC description could have been better.  But in the 
end you're human last I checked (at least I recall meeting you several 
times? ;)  How about a simple "Why do you think you need this?" first?

Regards,
-Denis

  reply	other threads:[~2019-08-20 20:45 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-15 18:57 [RFC 0/1] Allow MAC change on up interface James Prestwood
2019-08-15 18:57 ` [RFC 1/1] RFC: allow mac address change on up iface James Prestwood
2019-08-15 20:48 ` [RFC 0/1] Allow MAC change on up interface Jeff Johnson
2019-08-16  9:56   ` Toke Høiland-Jørgensen
2019-08-19 10:14 ` Johannes Berg
2019-08-19 15:55   ` James Prestwood
2019-08-19 20:20     ` Johannes Berg
2019-08-19 20:58       ` Denis Kenzior
2019-08-20  8:59         ` Johannes Berg
2019-08-20 15:40           ` Denis Kenzior
2019-08-20 17:53             ` Dan Williams
2019-08-20 18:21               ` Denis Kenzior
2019-08-20 18:54                 ` Toke Høiland-Jørgensen
2019-08-20 19:32             ` Johannes Berg
2019-08-20 19:46               ` Denis Kenzior
2019-08-20 20:01                 ` Johannes Berg
2019-08-19 21:14       ` James Prestwood
2019-08-20  6:59         ` Johannes Berg
2019-08-20 19:22           ` Denis Kenzior
2019-08-20 19:43             ` Johannes Berg
2019-08-20 19:58               ` Denis Kenzior
2019-08-20 20:15                 ` Johannes Berg
2019-08-20 20:37                   ` Denis Kenzior [this message]
2019-08-20 21:18                     ` Dan Williams
2019-08-20 21:52                       ` Denis Kenzior
2019-08-21  7:21                         ` Johannes Berg
2019-08-20 19:53           ` James Prestwood
2019-08-20 20:06             ` Johannes Berg

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=3313f0a7-2b38-9941-46bf-4c1a3e06a267@gmail.com \
    --to=denkenz@gmail.com \
    --cc=dcbw@redhat.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=prestwoj@gmail.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 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).