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? > 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. > And those > events should have all or nearly all info to not bother the kernel going > forward. That's what you wish for, but ... > 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) johannes
