Re: [PATCH 3/8] [NETFILTER]: rename NF_ARP to NFPROTO_ARP and assign a non-clashing value

[Patrick McHardy <kaber@trash.net>]

Jan Engelhardt wrote:
> On Wednesday 2008-04-09 18:35, Patrick McHardy wrote:
>>> A few concerns.
>>> If so, how would you deal with the addition of a new, real,
>>> protocol? Suppose someone added support for the
>>> semifictional IPv5, say  AF_INET5=42 or so. How would
>>> this affect the NFPROTO list?
>> It wouldn't since those values simply have seperate
>> meanings. AF_INET5 might be 42, NFPROTO_INET5 could
>> be .. lets say 5.
>>
> Then the big question is: what do you store in
> ct->tuplehash[0].src.l3num, AF_INET5 or NFPROTO_IPV5?
> Probably NFPROTO_IPV5.
> Ok, then the only issue - if there is such - is when
> AF_ values from the networking code pass into netfilter territory,
> then you would need a translation function.


Right. There is currently to my knowledge only a single
place where this happens, which is net/xfrm/xfrm_output.c.
All others explicitly pass AF_INET etc, and then would
simply pass NFPROTO_INET.

But you have a point, that doesn't sound ideal.

Unfortunately, as I said, we need to export these values
to userspace, so we can't have them depend on AF_MAX.
Another constraint is that they must not exceed 255
or they won't fit in nfgenmsg->nfgen_family.

Mhh tricky. I still would prefer to avoid AF_ARP ...