On 17/12/10 10:35, Jan Engelhardt wrote:
>
> On Friday 2010-12-17 08:25, Thomas Graf wrote:
>> On Thu, Dec 16, 2010 at 03:22:07PM +0100, Jan Engelhardt wrote:
>>>
>>> Oh great, now the confusion is complete. One person says this,
>>> another says something else. Best of all, the Netlink RFC leaves it
>>> unspecified, so it's all hearsay, beliefs and Perl5-style ("Source
>>> acts as normative reference") referencing. I guess we are doomed
>>> until the original Netlink3549 authors step up and tell us their
>>> intentions.
>>>
>>> As I see it, we need a discussion to specify what is to be done
>>> with unspecified parts, with 3549 as an origin.
>>
>> The current netlink code implementation defines the standard. It is
>> the standard because we have not been breaking it and will never do.
>>
>> Netlink is very open minded, it does not care if individual
>> protocols define their own semantics.
>
> So in fact, it does allow for preservation of attribute order and
> support for multiple attributes appearing with the same type, since that
> is part of my subprotocol anyway, right?
>
> Cf. http://marc.info/?l=netfilter-devel&m=129068531114996&w=2
As Thomas said, Netlink whatever protocol upon it, but I already told
you: making assumptions on the order of the attributes is not a good
practise because you'll have to stick to a certain message layout.
That's the opposite to what we aim which is to provide protocols that
can be easily extended in the future. If you assume that we cannot
change the attribute ordering, that's a rule that everybody will have to
live with forever.
Again, it will be valid, yes, but it's a poorly designed protocol.
Moreover, the reason why you want that attribute trailer is because of
the supposed-to-be limitations that you're trying to avoid. And, again,
I have to tell you that, avoiding the limitation by introducing
assumptions in the protocol is not a good idea.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
