netlink backwards compatibility in userspace tools

netlink backwards compatibility in userspace tools

[Jason A. Donenfeld]

Hi guys,

One handy aspect of Netlink is that it's backwards compatible. This
means that you can run old userspace utilities on new kernels, even if
the new kernel supports new features and netlink attributes. The wire
format is stable enough that the data marshaled can be extended
without breaking compat. Neat.

I was wondering, though, what you think the best stance is toward
these old userspace utilities. What should they do if the kernel sends
it netlink attributes that it does not recognize? At the moment, I'm
doing something like this:

static void warn_unrecognized(void)
{
    static bool once = false;
    if (once)
        return;
    once = true;
    fprintf(stderr,
        "Warning: this program received from your kernel one or more\n"
        "attributes that it did not recognize. It is possible that\n"
        "this version of wg(8) is older than your kernel. You may\n"
        "want to update this program.\n");
}

This seems like a somewhat sensible warning, but then I wonder about
distributions like Debian, which has a long stable life cycle, so it
frequently has very old tools (ancient iproute2 for example). Then,
VPS providers have these Debian images run on top of newer kernels.
People in this situation would undoubtedly see the above warning a lot
and not be able to do anything about it. Not horrible, but a bit
annoying. Is this an okay annoyance? Or is it advised to just have no
warning at all? One idea would be to put it behind an environment
variable flag, but I don't like too many nobs.

I'm generally wondering about attitudes toward this kind of userspace
program behavior in response to newer kernels.

Thanks,
Jason

Re: netlink backwards compatibility in userspace tools

[Stephen Hemminger]

On Fri, 29 Sep 2017 12:22:42 +0200
"Jason A. Donenfeld" <Jason@zx2c4.com> wrote:

> Hi guys,
> 
> One handy aspect of Netlink is that it's backwards compatible. This
> means that you can run old userspace utilities on new kernels, even if
> the new kernel supports new features and netlink attributes. The wire
> format is stable enough that the data marshaled can be extended
> without breaking compat. Neat.
> 
> I was wondering, though, what you think the best stance is toward
> these old userspace utilities. What should they do if the kernel sends
> it netlink attributes that it does not recognize? At the moment, I'm
> doing something like this:
> 
> static void warn_unrecognized(void)
> {
>     static bool once = false;
>     if (once)
>         return;
>     once = true;
>     fprintf(stderr,
>         "Warning: this program received from your kernel one or more\n"
>         "attributes that it did not recognize. It is possible that\n"
>         "this version of wg(8) is older than your kernel. You may\n"
>         "want to update this program.\n");
> }
> 
> This seems like a somewhat sensible warning, but then I wonder about
> distributions like Debian, which has a long stable life cycle, so it
> frequently has very old tools (ancient iproute2 for example). Then,
> VPS providers have these Debian images run on top of newer kernels.
> People in this situation would undoubtedly see the above warning a lot
> and not be able to do anything about it. Not horrible, but a bit
> annoying. Is this an okay annoyance? Or is it advised to just have no
> warning at all? One idea would be to put it behind an environment
> variable flag, but I don't like too many nobs.
> 
> I'm generally wondering about attitudes toward this kind of userspace
> program behavior in response to newer kernels.
> 
> Thanks,
> Jason

I can not see a reason that such a warning is required.
Old utilities should just work fine, they just won't show or allow
setting attributes they don't understand.

Any netlink attributes that the tools do not recognize should just
be ignored.

Re: netlink backwards compatibility in userspace tools

[Rustad, Mark D]

[-- Attachment #1: Type: text/plain, Size: 2135 bytes --]


> On Sep 29, 2017, at 3:22 AM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> 
> Hi guys,
> 
> One handy aspect of Netlink is that it's backwards compatible. This
> means that you can run old userspace utilities on new kernels, even if
> the new kernel supports new features and netlink attributes. The wire
> format is stable enough that the data marshaled can be extended
> without breaking compat. Neat.
> 
> I was wondering, though, what you think the best stance is toward
> these old userspace utilities. What should they do if the kernel sends
> it netlink attributes that it does not recognize? At the moment, I'm
> doing something like this:
> 
> static void warn_unrecognized(void)
> {
>    static bool once = false;
>    if (once)
>        return;
>    once = true;
>    fprintf(stderr,
>        "Warning: this program received from your kernel one or more\n"
>        "attributes that it did not recognize. It is possible that\n"
>        "this version of wg(8) is older than your kernel. You may\n"
>        "want to update this program.\n");
> }
> 
> This seems like a somewhat sensible warning, but then I wonder about
> distributions like Debian, which has a long stable life cycle, so it
> frequently has very old tools (ancient iproute2 for example). Then,
> VPS providers have these Debian images run on top of newer kernels.
> People in this situation would undoubtedly see the above warning a lot
> and not be able to do anything about it. Not horrible, but a bit
> annoying. Is this an okay annoyance? Or is it advised to just have no
> warning at all? One idea would be to put it behind an environment
> variable flag, but I don't like too many nobs.
> 
> I'm generally wondering about attitudes toward this kind of userspace
> program behavior in response to newer kernels.
> 
> Thanks,
> Jason

That seems like a bit much. Consider only emitting a message with the use of a verbose flag - or two. Even then the message should be shortened - the first sentence is entirely adequate even in verbose mode.

--
Mark Rustad, Networking Division, Intel Corporation


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 841 bytes --]

Re: netlink backwards compatibility in userspace tools

[David Miller]

From: "Jason A. Donenfeld" <Jason@zx2c4.com>
Date: Fri, 29 Sep 2017 12:22:42 +0200

> One handy aspect of Netlink is that it's backwards compatible. This
> means that you can run old userspace utilities on new kernels, even if
> the new kernel supports new features and netlink attributes. The wire
> format is stable enough that the data marshaled can be extended
> without breaking compat. Neat.
> 
> I was wondering, though, what you think the best stance is toward
> these old userspace utilities. What should they do if the kernel sends
> it netlink attributes that it does not recognize? At the moment, I'm
> doing something like this:
> 
> static void warn_unrecognized(void)
> {
>     static bool once = false;
>     if (once)
>         return;
>     once = true;
>     fprintf(stderr,
>         "Warning: this program received from your kernel one or more\n"
>         "attributes that it did not recognize. It is possible that\n"
>         "this version of wg(8) is older than your kernel. You may\n"
>         "want to update this program.\n");
> }
> 
> This seems like a somewhat sensible warning, but then I wonder about
> distributions like Debian, which has a long stable life cycle, so it
> frequently has very old tools (ancient iproute2 for example). Then,
> VPS providers have these Debian images run on top of newer kernels.
> People in this situation would undoubtedly see the above warning a lot
> and not be able to do anything about it. Not horrible, but a bit
> annoying. Is this an okay annoyance? Or is it advised to just have no
> warning at all? One idea would be to put it behind an environment
> variable flag, but I don't like too many nobs.
> 
> I'm generally wondering about attitudes toward this kind of userspace
> program behavior in response to newer kernels.

Generally, yes you should simply ignore attributes you don't understand.

But we keep coming back to this issue, because it's not always the best
thing to do.

For example, let's say you have settings X and Y for object A.

User A has a newer tool and is able to set both X and Y, as well as
see them in dumps.  And let's further assume that Y's setting has some
kind of influence on the behavior of X.

User B has an older tool, and sees X but not Y because Y is not
understood by the older tool.  User B will not be able to figure out
why X is not behaving the way they expect it to, because of the loss
of information.

Similar, even more serious, issues arise when setting values.  User B
can set X and wonder why it's not doing what they expect it to do
because of setting Y which they can't even see with their tools.

For this reason it might be beneficical to at least say to the user
"Warning, I've seen one or more unrecognized netlink attributes."
so that there is at least a chance for the user to figure out what
might be happening to them.

Re: netlink backwards compatibility in userspace tools

[Jason A. Donenfeld]

Hi Dave,

That seems wise. Thanks for the advice. A more sophisticated way of
approaching this would be for the kernel to also send a bitmap of
which attributes are "critical" and only warn (or even error) of
_those_ are not understood. But that seems needlessly complex, and so
I think I'll go with your suggestion, and simply warn once with a
shorter message.

Jason