[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230209180727.0ec328dd@kernel.org>
Date: Thu, 9 Feb 2023 18:07:27 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Chuck Lever III <chuck.lever@...cle.com>
Cc: Paolo Abeni <pabeni@...hat.com>,
Eric Dumazet <edumazet@...gle.com>,
"open list:NETWORKING [GENERAL]" <netdev@...r.kernel.org>,
"hare@...e.com" <hare@...e.com>,
David Howells <dhowells@...hat.com>,
Benjamin Coddington <bcodding@...hat.com>,
Olga Kornievskaia <kolga@...app.com>,
"jmeneghi@...hat.com" <jmeneghi@...hat.com>
Subject: Re: [PATCH v3 1/2] net/handshake: Create a NETLINK service for
handling handshake requests
On Thu, 9 Feb 2023 15:43:06 +0000 Chuck Lever III wrote:
> >> @@ -29,6 +29,7 @@
> >> #define NETLINK_RDMA 20
> >> #define NETLINK_CRYPTO 21 /* Crypto layer */
> >> #define NETLINK_SMC 22 /* SMC monitoring */
> >> +#define NETLINK_HANDSHAKE 23 /* transport layer sec handshake requests */
> >
> > The extra indirection of genetlink introduces some complications?
>
> I don't think it does, necessarily. But neither does it seem
> to add any value (for this use case). <shrug>
Our default is to go for generic netlink, it's where we invest most time
in terms of infrastructure. It can take care of attribute parsing, and
allows user space to dump information about the family (eg. the parsing
policy). Most recently we added support for writing the policies in
(simple) YAML:
https://docs.kernel.org/next/userspace-api/netlink/intro-specs.html
It takes care of a lot of the netlink tedium. If you're willing to make
use of it I'm happy to help converting etc. We merged this stuff last
month, so there are likely sharp edges.
Powered by blists - more mailing lists