Search Linux Wireless

Re: [PATCH][RFC] cfg80211: NL80211_ATTR_SOCKET_OWNER support for CMD_CONNECT

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

 



Hi Johannes,

On 12/05/2016 09:14 AM, Johannes Berg wrote:
Well, no, that'd only work with an open connection :)

Actually, it also works fairly easily for when firmware has 4-way-
handshake offload, which will be coming to a kernel near you soon.


Great, but still not applicable for all devices, and still questionable how useful an unmanaged connection actually is. But okay.

And even that is questionable in my mind for some of the more
advanced cases.

Well, at least in that case you can have things running (for a while)
if the manager crashes?


To what purpose? That's like saying that maybe a socket should be kept open in case an application crashes.

But I'm not sure what your point is, do you still have objections to
this approach?

Well, first of all, you can keep things running, at least until you've
figured out how to restart wpa_supplicant/whatever.

There also aren't really any important resources to clear when
userspace dies, at least nothing that userspace can't trivially clear
later by disconnecting (even unconditionally and ignoring the
result)...

Sure, but in the meantime you have a completely unmanaged connection, with no connection manager to tell you what the state of it is. Maybe okay for a command line system with a brain in front of it, but not much use anywhere else.

But for that use case the SOCKET_OWNER attribute can be omitted...


So basically I just don't see the advantage. It feels like trading a
single line of userspace code to disconnect with some (not super
complex, but still somewhat involved) kernel-side tracking. That
doesn't really seem like a worthwhile tradeoff to me.


Well, we'd be trading quite a bit of race-prone user space code that performs the clean up on start up for one line of attributes. I call that a good trade.

Also, I thought it was good form / the UNIX way to clean up after processes exit ungracefully. You seem to be arguing against that? I would argue the kernel should be doing the opposite. It should always clean up the connection unless user space has indicated it can be 'reused'.

Regards,
-Denis



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

  Powered by Linux