[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CADXeF1F5R+p7ohvMRDBsRSxxqqAO-zXwctSz5KvMJEPbQLy90Q@mail.gmail.com>
Date: Tue, 21 Jan 2025 11:29:24 +0900
From: Yuyang Huang <yuyanghuang@...gle.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>, David Ahern <dsahern@...nel.org>,
netdev@...r.kernel.org, Donald Hunter <donald.hunter@...il.com>,
Shuah Khan <shuah@...nel.org>, Nikolay Aleksandrov <razor@...ckwall.org>,
Hangbin Liu <liuhangbin@...il.com>, Daniel Borkmann <daniel@...earbox.net>,
linux-kselftest@...r.kernel.org, Maciej Żenczykowski <maze@...gle.com>,
Lorenzo Colitti <lorenzo@...gle.com>
Subject: Re: [PATCH net-next, v6 1/2] netlink: support dumping IPv4 multicast addresses
Thanks for the feedback.
>IIUC Paolo's suggestion was to create a new header file under net/ipv4,
>if you consider addrconf.h unsuitable. There is no need to expose this
>argument struct in kernel-wide headers.
Currently the structure is like follows:
IPv4: `struct inet_fill_args` in igmp.h and use it in igmp.c/devinet.c
IPv6: `struct inet6_fill_args` in addrconf.h and use it in mld.c/addrconf.c
We could move `struct inet_fill_args` to a separate header file, but
this would cause the IPv4 and IPv6 code to diverge. Therefore, we may
need to modify the IPv6 header structure slightly as well.
I propose moving `struct inet_fill_args` to `igmp_internal.h` and, in
a separate patch, moving struct inet6_fill_args to
addrconf_internal.h.
Please let me know if you have any other suggestions.
Thanks,
Yuyang
On Tue, Jan 21, 2025 at 9:46 AM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Fri, 17 Jan 2025 17:15:58 +0900 Yuyang Huang wrote:
> > include/linux/igmp.h | 12 +++++++
> > net/ipv4/devinet.c | 76 ++++++++++++++++++++++++++++++++++++--------
> > net/ipv4/igmp.c | 13 +++++---
>
> IIUC Paolo's suggestion was to create a new header file under net/ipv4,
> if you consider addrconf.h unsuitable. There is no need to expose this
> argument struct in kernel-wide headers.
Powered by blists - more mailing lists