Jan Engelhardt wrote:
On Wednesday 2008-04-09 17:15, Patrick McHardy wrote:
#define AF_INET 2 /* Internet IP Protocol */
#define AF_ATMPVC 8 /* ATM PVCs */
#define AF_INET6 10 /* IP version 6 */
#define AF_BLUETOOTH 31
after decoupling them we don't really care about clashes
anymore, so we might still use zero for ARP and AF_INET6
as highest value.
I have a bad feeling about it, though.. maybe someone wants
to add a PF_LOCAL filter one day, and if NFPROTO_ARP is
exported, that'd be really bad - more than currently even.
PF_LOCAL? And why would it matter, if we decouple the
values they simply have nothing in common anymore except
the a few old values for compatibility (IP,IP6,BRIDGE).
Are you suggesting to split the AF and NFPROTO list?
(Took me quite some time..)
Yes.
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.
--
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
