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>
 <427f488f-98f5-f888-f079-e2bbbb6eedf3@gmail.com>
 <144f36779085498bdc1b2f7ac0d0c267d431f51d.camel@sipsolutions.net>
From:   Denis Kenzior <denkenz@gmail.com>
Message-ID: <4e2407af-ef56-d1dc-93a8-b2cf558a5460@gmail.com>
Date:   Thu, 20 Jun 2019 15:35:51 -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: <144f36779085498bdc1b2f7ac0d0c267d431f51d.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 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