Tue, Aug 27, 2019 at 12:18:19AM CEST, da...@davemloft.net wrote:
>From: Jakub Kicinski <jakub.kicin...@netronome.com>
>Date: Mon, 26 Aug 2019 15:15:52 -0700
>
>> Weren't there multiple problems with the size of the RTM_NEWLINK
>> notification already? Adding multiple sizeable strings to it won't
>> help there either :S
>
>Indeed.
>
>We even had situations where we had to make the information provided
>in a newlink dump opt-in when we added VF info because the buffers
>glibc was using at the time were too small and this broke so much
>stuff.
>
>I honestly think that the size of link dumps are out of hand as-is.
Okay, so if I understand correctly, on top of separate commands for
add/del of alternative names, you suggest also get/dump to be separate
command and don't fill this up in existing newling/getlink command.
So we'll have:
CMD to add:
RTM_NEWALTIFNAME = 108
#define RTM_NEWALTIFNAME RTM_NEWALTIFNAME
Example msg (user->kernel):
IFLA_IFNAME eth0
IFLA_ALT_IFNAME_MOD somereallyreallylongname
Example msg (user->kernel):
IFLA_ALT_IFNAME somereallyreallylongname
IFLA_ALT_IFNAME_MOD someotherreallyreallylongname
CMD to delete:
RTM_DELALTIFNAME,
#define RTM_DELALTIFNAME RTM_DELALTIFNAME
Example msg (user->kernel):
IFLA_IFNAME eth0
IFLA_ALT_IFNAME_MOD somereallyreallylongname
CMD to get/dump:
RTM_GETALTIFNAME,
#define RTM_GETALTIFNAME RTM_GETALTIFNAME
Example msg (kernel->user):
hdr (with ifindex)
IFLA_ALT_IFNAME_LIST (nest)
IFLA_ALT_IFNAME somereallyreallylongname
IFLA_ALT_IFNAME someotherreallyreallylongname
Correct?
