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

[Johannes Berg <johannes@sipsolutions.net>]

On Tue, 2019-08-20 at 16:52 -0500, Denis Kenzior wrote:

> I'm not sure you can state that definitively just yet?  

That's not an argument, you also cannot state definitively that it will
not happen. But yes, I'd think it _is_ in fact likely to happen at some
point for something new, maybe it won't be IBSS but NAN, or something
new that we can't even consider yet. Why close the door on it?

> So the real 
> question is whether saving the extra round-trip to the kernel is worth 
> the in-kernel complexity.

Sort of.

>   Given that interleaved system calls are _always_ a problem

They're not interleaved, they're just serial. And seriously, if syscalls
were such a big problem, we wouldn't be using them, we'd have found a
better solution.

(and FWIW, I don't feel you're really arguing in good faith here. You're
just throwing out statements like that and dismissing all other
arguments with no good explanation.)

> , 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.

That's ridiculous. If I extrapolate that statement the logical
consequence is that you should put iwd into a kernel module. You're not
doing that, last I checked? So minimizing the latency of connections is
quite clearly not the only goal here.

I understand that you're interested in minimizing the latency of
connections. I can even agree that it's a worthwhile goal. But it cannot
be the only goal.

> 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?"

That's not actually what you said.

> > 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.

Seriously Denis, stop it.

johannes