[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <578923F6.1070606@6wind.com>
Date: Fri, 15 Jul 2016 19:57:10 +0200
From: Nicolas Dichtel <nicolas.dichtel@...nd.com>
To: Topi Miettinen <toiwoton@...il.com>, linux-kernel@...r.kernel.org
Cc: Jonathan Corbet <corbet@....net>, Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Balbir Singh <bsingharora@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Markus Elfring <elfring@...rs.sourceforge.net>,
Thomas Gleixner <tglx@...utronix.de>,
Rik van Riel <riel@...hat.com>,
"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>
Subject: Re: [PATCH 01/14] resource limits: foundation for resource highwater
tracking
Le 15/07/2016 18:27, Topi Miettinen a écrit :
[snip]
>> Why playing with version number? It complexifies the (userland) code and
>> existing applications break when the kernel is updated.
>> Goal of netlink is to be easily extensible. By adding a new attribute, existing
>> userspace tools won't break.
>
> I just followed this text in taskstats.h. Does that give wrong advice?
>
> * The struct is versioned. Newer versions should only add fields to
> * the bottom of the struct to maintain backward compatibility.
> *
> *
> * To add new fields
> * a) bump up TASKSTATS_VERSION
> * b) add comment indicating new version number at end of struct
> * c) add new fields after version comment; maintain 64-bit alignment
I don't know taskstats well, but that is not how netlink works. There is no need
to manage a version with netlink, just add new attributes.
Regards,
Nicolas
Powered by blists - more mailing lists