Re: [RFC 0/1] Allow MAC change on up interface

[Denis Kenzior <denkenz@gmail.com>]

Hi Dan,

On 8/20/19 4:18 PM, Dan Williams wrote:

<snip>

> 
> Code will be written, but I'd rather it be written once rather than 3+
> times for STA/AP/Mesh/etc.
> 

I'm not sure you can state that definitively just yet?  So the real 
question is whether saving the extra round-trip to the kernel is worth 
the in-kernel complexity.  Given that interleaved system calls are 
_always_ a problem, I argue that it is worth it for at least the Station 
case (and it will keep connection times even faster to boot).  Isn't 
minimizing the latency of connections the end goal here?  I get that 
there are trade offs and people have other opinions on what a good trade 
off is.

But don't misunderstand, either solution is better than what we have 
today.  My argument is: "why close the door on a particular solution 
until the costs are known?"

>> 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.
> 
> Why would you not want to pass a random MAC for AP or Mesh modes? The
> same reasons for MAC randomization apply for all those too, I'd think.

Umm, I was not arguing against doing that at all?  All I said was that 
no such use case was yet presented.  For AP it isn't typically needed to 
rapidly switch between MAC addresses while keeping the device UP.  If 
you think there's such a need, I'm happy to learn something new? Same 
goes for Mesh really?

> 
>>> 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? :)
> 
> Not really. It's the job of maintainers to balance all these things, to
> step back and think of the bigger picture and the future rather than
> just solving one particular use-case today.
>  > Your tone leaves the impression you want a particular solution pushed
> through without the normal planning/architecture discussions that
> accompany API changes. And that's not how the process typically works.
> 

So who's attacking who now?  We're trying to solve a long standing issue 
that nobody has bothered to fix for years in a clean way.  Something 
that one of your projects would benefit from, btw.

I have a technical opinion about how it should look like.  Johannes 
might have a different opinion.  In the end it is up to him and I can go 
pound sand.  So yes, I know how the process works ;)

Regards,
-Denis