Search Linux Wireless

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux