Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH 3/3] nl80211: Include wiphy address setup in NEW_WIPHY
To:     Johannes Berg <johannes@sipsolutions.net>
Cc:     linux-wireless@vger.kernel.org
References: <20190619223606.4575-1-denkenz@gmail.com>
 <20190619223606.4575-3-denkenz@gmail.com>
 <ec1ca95a5789f9001e89e603633b20316d687721.camel@sipsolutions.net>
 <7da9b924-78c7-ba72-fecc-a11700a34ff4@gmail.com>
 <44923833f1068e360b1f9534a9bbd37be41e4833.camel@sipsolutions.net>
From:   Denis Kenzior <denkenz@gmail.com>
Message-ID: <427f488f-98f5-f888-f079-e2bbbb6eedf3@gmail.com>
Date:   Thu, 20 Jun 2019 15:05:25 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <44923833f1068e360b1f9534a9bbd37be41e4833.camel@sipsolutions.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

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