lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a125f933-b985-441e-9fac-49002bc5933a@gmail.com>
Date: Tue, 19 Nov 2024 04:05:01 +0200
From: Sergey Ryazanov <ryazanov.s.a@...il.com>
To: Antonio Quartulli <antonio@...nvpn.net>
Cc: Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>, Donald Hunter <donald.hunter@...il.com>,
 Shuah Khan <shuah@...nel.org>, sd@...asysnail.net,
 Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH net-next v11 03/23] ovpn: add basic netlink support

On 15.11.2024 12:05, Antonio Quartulli wrote:
> On 09/11/2024 00:15, Sergey Ryazanov wrote:
>> On 29.10.2024 12:47, Antonio Quartulli wrote:
>>> @@ -37,7 +41,7 @@ static int ovpn_newlink(struct net *src_net, struct 
>>> net_device *dev,
>>>   }
>>>   static struct rtnl_link_ops ovpn_link_ops = {
>>> -    .kind = "ovpn",
>>> +    .kind = OVPN_FAMILY_NAME,
>>
>> nit: are you sure that the link kind is the same as the GENL family? I 
>> mean, they are both deriviated from the protocol name that is common 
>> for both entities, but is it making RTNL kind a derivative of GENL 
>> family?
> 
> I just want to use the same name everywhere and I thought it doesn't 
> make sense to create a separate define (they can be decoupled later 
> should see any need for that).
> But I can add:
> 
> #define OVPN_RTNL_LINK_KIND OVPN_FAMILY_NAME
> 
> to make this relationship explicit?

Can we just leave it as literal? This string is going to be a part of 
ABI and there will be no chance to change it in the future. So, what the 
purpose to define it using a macro if it's self-descriptive?

People also like to define a macro with a generic name like DRV_NAME and 
use it everywhere. What also looks reasonable.

--
Sergey

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ