[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y2KT4A6ZGVfcbsfx@nanopsycho>
Date: Wed, 2 Nov 2022 16:59:28 +0100
From: Jiri Pirko <jiri@...nulli.us>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, davem@...emloft.net, pabeni@...hat.com,
edumazet@...gle.com, tariqt@...dia.com, moshe@...dia.com,
saeedm@...dia.com, linux-rdma@...r.kernel.org
Subject: Re: [patch net-next v3 13/13] net: expose devlink port over rtnetlink
Wed, Nov 02, 2022 at 04:52:49PM CET, kuba@...nel.org wrote:
>On Wed, 2 Nov 2022 16:37:00 +0100 Jiri Pirko wrote:
>> >> Maybe it's time to plumb policies thru to classic netlink, instead of
>> >> creating weird attribute constructs?
>> >
>> >Not a blocker, FWIW, just pointing out a better alternative.
>>
>> Or, even better, move RTnetlink to generic netlink. Really, there is no
>> point to have it as non-generic netlink forever. We moved ethtool there,
>> why not RTnetlink?
>
>As a rewrite? We could plug in the same callbacks into a genl family
>but the replies / notifications would have different headers depending
>on the socket type which gets hairy, no?
I mean like ethtool, completely side iface, independent, new attrs etc.
We can start with NetdevNetlink for example. Just cover netdev part of
RTNetlink. That is probably most interesting anyway.
Powered by blists - more mailing lists