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 ...
--
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
