[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CO1PR11MB5089E0F6516DAB7657792667D6C59@CO1PR11MB5089.namprd11.prod.outlook.com>
Date: Fri, 20 Jan 2023 18:35:19 +0000
From: "Keller, Jacob E" <jacob.e.keller@...el.com>
To: Johannes Berg <johannes@...solutions.net>,
Jakub Kicinski <kuba@...nel.org>,
"davem@...emloft.net" <davem@...emloft.net>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"edumazet@...gle.com" <edumazet@...gle.com>,
"pabeni@...hat.com" <pabeni@...hat.com>,
"robh@...nel.org" <robh@...nel.org>,
"stephen@...workplumber.org" <stephen@...workplumber.org>,
"ecree.xilinx@...il.com" <ecree.xilinx@...il.com>,
"sdf@...gle.com" <sdf@...gle.com>,
"f.fainelli@...il.com" <f.fainelli@...il.com>,
"fw@...len.de" <fw@...len.de>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"razor@...ckwall.org" <razor@...ckwall.org>,
"nicolas.dichtel@...nd.com" <nicolas.dichtel@...nd.com>,
Bagas Sanjaya <bagasdotme@...il.com>
Subject: RE: [PATCH net-next v3 1/8] docs: add more netlink docs (incl. spec
docs)
> -----Original Message-----
> From: Johannes Berg <johannes@...solutions.net>
> Sent: Friday, January 20, 2023 1:11 AM
> To: Keller, Jacob E <jacob.e.keller@...el.com>; Jakub Kicinski <kuba@...nel.org>;
> davem@...emloft.net
> Cc: netdev@...r.kernel.org; edumazet@...gle.com; pabeni@...hat.com;
> robh@...nel.org; stephen@...workplumber.org; ecree.xilinx@...il.com;
> sdf@...gle.com; f.fainelli@...il.com; fw@...len.de; linux-
> doc@...r.kernel.org; razor@...ckwall.org; nicolas.dichtel@...nd.com; Bagas
> Sanjaya <bagasdotme@...il.com>
> Subject: Re: [PATCH net-next v3 1/8] docs: add more netlink docs (incl. spec docs)
>
> On Thu, 2023-01-19 at 16:23 -0800, Jacob Keller wrote:
> >
> > Per op policy is important because otherwise it can become impossible to
> > safely extend a new attribute to commands over multiple kernel releases.
> >
>
> Yeah. I think I just realised that my issues is more with the fact that
> per-op policy implies per-op attribute (identifier/number/name)space,
> and if you don't have that you have attribute duplication etc.
>
> Anyway, it just feels superfluous, not really dangerous I guess :)
>
> Johannes
I think we want per-family attribute and op IDs, but still per-op policy that indicates which attributes are supported for a command.
This way you can re-use attributes for multiple commands, and they should behave the same semantics for those commands which support them, but the kernel can properly express which attributes are valid for a given command using the per-op policy.
I know some commands do use separate attributes for each command, or separate attribute space for sub-attributes in nests, but I am not sure how widespread that is. Devlink uses a single space for all its attributes.
Thanks,
Jake
Powered by blists - more mailing lists