On 17-04-21 11:20 AM, Eric Dumazet wrote:
On Fri, 2017-04-21 at 11:12 -0400, Jamal Hadi Salim wrote:
On 17-04-21 09:12 AM, Jiri Pirko wrote:
Fri, Apr 21, 2017 at 12:55:31PM CEST, j...@mojatatu.com wrote:
From: Jamal Hadi Salim <j...@mojatatu.com>
Jiri, there is a balance between extensibility and performance.
It is senseless to use a TLV just so i can set a 0/1(true/false).
You assume that the (user space) did sensible things.
If it didnt it is a bug. Seriously.
Look: If this was the case a lot of things would break in the
kernel. We have bit flags everywhere. We add new ones frequently
to these bitmaps.
Sometimes they do not, and sets some bits to 1 while they should not.
That is a bug. You cant blame the compiler.
If old kernel just ignored theses bits, application just ran fine and
was _qualified_.
Now customers might use these _working_ applications.
Then, Jamal comes and change the kernel to give a meaning to these bits.
As happens frequently, not just Jamal - Eric also;->
Now the customer is running the new kernel and the old application
breaks horribly.
Who is at fault ? Jamal of course, not the application authors that
might be out of business, and could not have any test that could have
spot the (future) issue.
Please Jamal, can we stop this for good ?
Eric: Your are speaking in generalities and you starting premise is
wrong. Anyone setting random bits in a netlink bitmask that has not
been defined is creating bug. We have many examples of how netlink
bitmasks are being used and constantly extended. Please take a look.
If i was the first person starting this today, then yes you will be
making a lot of sense.
For the pads - the arguement that malloc-ing the datastructure may put
random values in the pads was a reasonable arguement. But this is not.
cheers,
jamal
