[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20211015134448.GA16157@asgard.redhat.com>
Date: Fri, 15 Oct 2021 15:44:48 +0200
From: Eugene Syromiatnikov <esyr@...hat.com>
To: Jeremy Kerr <jk@...econstruct.com.au>
Cc: netdev@...r.kernel.org, Matt Johnston <matt@...econstruct.com.au>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>
Subject: Re: [PATCH net-next v3] mctp: Implement extended addressing
On Thu, Oct 14, 2021 at 04:34:20PM +0800, Jeremy Kerr wrote:
> This change allows an extended address struct - struct sockaddr_mctp_ext
> - to be passed to sendmsg/recvmsg. This allows userspace to specify
> output ifindex and physical address information (for sendmsg) or receive
> the input ifindex/physaddr for incoming messages (for recvmsg). This is
> typically used by userspace for MCTP address discovery and assignment
> operations.
>
> The extended addressing facility is conditional on a new sockopt:
> MCTP_OPT_ADDR_EXT; userspace must explicitly enable addressing before
> the kernel will consume/populate the extended address data.
[...]
> +/* setsockopt(2) level & options */
> +#define SOL_MCTP 0
Socket option levels tend to be globally unique and additionally defined
in include/linux/socket.h (which led to them not being exposed to UAPI
in many cases, but that is another, entirely avoiadable, problem), with
Bluetooth socket option levels being most notable exception (and IEEE 802.15.4
and mISDN being less notable). So, unless there is existing code that relies
on this socket level definition, it is probably worth re-defining it to 284
and put a copy of SOL_MCTP definition after SOL_XDP in include/linux/socket.h.
Powered by blists - more mailing lists