netdev - Re: [PATCH net-next v11 00/23] Introducing OpenVPN Data Channel Offload

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: <4fa316ce-c6f7-41d8-bb47-00c15f76faba@gmail.com>
Date: Fri, 15 Nov 2024 00:10:17 +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,
 steffen.klassert@...unet.com, antony.antony@...unet.com,
 Shuah Khan <skhan@...uxfoundation.org>
Subject: Re: [PATCH net-next v11 00/23] Introducing OpenVPN Data Channel
 Offload

On 14.11.2024 17:33, Antonio Quartulli wrote:
> On 06/11/2024 02:18, Sergey Ryazanov wrote:
>> Regarding "big" topics I have only two concerns: link creation using 
>> RTNL and a switch statement usage. In the corresponding thread, I 
>> asked Jiri to clarify that "should" regarding .newlink implementation. 
>> Hope he will have a chance to find a time to reply.
> 
> True, but to be honest at this point I am fine with sticking to RTNL, 
> also because we will soon introduce the ability to create 'persistent' 
> ifaces, which a user should be able to create before starting openvpn.

Could you share the use case for this functionality?

> Going through RTNL for this is the best choice IMHO, therefore we have 
> an extra use case in favour of this approach (next to what Jiri already 
> mentioned).

In absence of arguments it's hard to understand, what's the "best" 
meaning. So, I'm still not sure is it worth to split uAPI between two 
interfaces. Anyway, it's up to maintainers to decide is it mergeable in 
this form or not. I just shared some arguments for the full management 
interface in GENL.

--
Sergey