Hi Johannes,
On 06/20/2019 03:09 PM, Johannes Berg wrote:
On Thu, 2019-06-20 at 15:05 -0500, Denis Kenzior wrote:
Ugh. So, if I understand this correctly, NEW_WIPHY events that are
generated when a new wiphy is plugged would only send the old 'legacy'
info and any info we add in cases 9+ would be 'lost' and the application
is forced into re-dumping the phy.
Yes.
This is pretty much counter to what we want.
Well, you want the info, shouldn't matter how you get it?
Well, it kind of does. You're asking userspace to introduce extra
complexity, extra round trips, extra stuff to go wrong just because the
kernel API has painted itself into a corner.
If you want to keep your sanity in userspace, you need proper 'object
appeared' / 'object disappeared' events from the kernel.
Sure, but you don't really need to know *everything* about the events
right there ... you can already filter which ones you care about
(perhaps you know you never want to bind hwsim ones for example) and
then request data on those that you do need.
Sure, but it would be nice to have all the info available if we do not
want to filter it...
And those
events should have all or nearly all info to not bother the kernel going
forward.
That's what you wish for, but ...
Well, it is a pretty basic requirement for any event driven API, no?
It sounds like nl80211 API has run into the extend-ability
wall, no?
I don't really see it that way.
Any suggestions on how to resolve this? Should NEW_WIPHY events also do
the whole split_dump semantic and generate 15+ or whatever messages?
No, that'd be awful, and anyway you'd have to send a new command because
otherwise old applications might be completely confused (not that I know
of any other than "iw event" that would event listen to this, but who
knows)
Well, given that we're the only ones that seem to care about this right
now, I don't see sending a new command as much of a big deal. I welcome
other ideas, but having the kernel send us an event, then us turning
around and requesting the *same* info is just silly.
Regards,
-Denis
