Hi Johannes,
On 06/20/2019 02:17 PM, Johannes Berg wrote:
Hi Denis,
We generally can't add anything to any of the cases before the split was
allowed, for compatibility with old userspace.
Can you educate me here? Is it because the non-split dump messages would
grow too large?
No. Those messages aren't really relevant, userspace will need to do a
larger buffer for it.
The problem is that old userspace (like really old) didn't split even
dumps. Eventually, we had so much information here that the default dump
message size is exceeded, and we simply couldn't dump that particular
wiphy anymore.
We solved this by splitting the wiphy information into multiple
messages, but that needed new userspace, so when userspace doesn't
request split dumps, we fall through all the way to "case 8" and then
stop - old userspace cannot care about new information anyway.
The reason it was split into cases 0-8 that are combined in non-split
dumps is that it was safer that way - there were certain configurations
where even the original data would go above the message size limit.
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. This is pretty much counter to what
we want.
If you want to keep your sanity in userspace, you need proper 'object
appeared' / 'object disappeared' events from the kernel. And those
events should have all or nearly all info to not bother the kernel going
forward. It sounds like nl80211 API has run into the extend-ability
wall, no?
Any suggestions on how to resolve this? Should NEW_WIPHY events also do
the whole split_dump semantic and generate 15+ or whatever messages?
Regards,
-Denis
