[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1537288970.2957.30.camel@sipsolutions.net>
Date: Tue, 18 Sep 2018 18:42:50 +0200
From: Johannes Berg <johannes@...solutions.net>
To: Jamal Hadi Salim <jhs@...atatu.com>,
Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
Michal Kubecek <mkubecek@...e.cz>
Cc: linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
jbenc@...hat.com
Subject: Re: [PATCH 1/2] netlink: add NLA_REJECT policy type
On Tue, 2018-09-18 at 09:12 -0400, Jamal Hadi Salim wrote:
> Not very familiar with how wifi scan gets initiated. I am guessing
> you issue some GET or SET to start a scan - and you get an async
> response when it is complete (and it would include the time it took)?
> Or maybe you get an immediate response and event notification later
> and the time spent is in that notification?
There isn't really a GET or SET. It's just an arbitrary generic netlink
command that you send down. Not everything is a GET/SET model :-)
But yes, you issue a command via generic netlink to start a scan, with
some attributes, and then eventually get an async notification when it's
done (or was aborted for some reason.)
For purposes of my example, that time attribute would be in the
notification, yes.
> I would still see that as a read-only attribute.
I suppose you could, but you never really get to see it anywhere else.
> And the utility of "execute" bit is only in blocking another scan
> from being initiated when one is in progress, if that is a desired
> goal.
Not sure I understand that. I'm not really talking about some sort of
generic "SET_VALUE" command with a "SCAN_NOW" attribute?
> > I dunno. I think we already bloated the policies too much by including
> > the validation_data pointer, and would hate to add more to that :-)
>
> Your mileage may vary. NLA_REJECT may work acls offer more fine grained
> controls.
Fair point. We do have padding in the policy (at least on 64-bit
platforms) that we could use for more bits ;-)
johannes
Powered by blists - more mailing lists