On Thursday 2010-04-22 13:29, Patrick McHardy wrote:
>Jan Engelhardt wrote:
>> On Thursday 2010-04-22 13:14, Patrick McHardy wrote:
>>
>>>> +static struct xt_match condition_mt_reg __read_mostly = {
>>>> + .name = "condition",
>>>> + .revision = 1,
>>> Why are we starting with revision 1?
>>
>> So as to avoid collisions with previously-deployed extensions.
>>
>> Debian once decided to patch their etch 2.6.18 kernel with
>> ipt_connlimit ("connlimit.0"). That subsequently backfired with the
>> etchnhalf upgrade where xt_connlimit (also known as "connlimit.0")
>> was introduced.
>>
>> condition.0 was used by pom-ng.
>>
>> For the same reason, xt_TEE-2.6.35 starts with TEE.1, because TEE.0
>> is already in use by the variant without oif in struct xt_tee_tginfo;
>> i.e. all the Xtables-addons installations to date, basically.
>>
>> It is not a particularl hardship to pick a revision number that is
>> distinct from all revision numbers previously seen in the wild, so
>> I'm set to go this way.
>
>Fair enough, I guess we don't have to fear running out of revisions :)
>Thanks for the explanation.
Well... the revision field is only 8 bit, so - maybe in 30 years
we have a population as dense as /etc/protocols. Though I don't
suspect we're still supporting iptables 1.2.x at that point.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
