Multiple targets for REDIRECT & friends

Multiple targets for REDIRECT & friends

[Munteanu Eduard Gabriel]

I'm looking to contribute this to netfilter.

Right now, ip_nat_multi_range is typedeffed (as a macro, though) to 
ip_nat_multi_range_compat. I think it will be okay to make 
ip_nat_multi_range be a linked list, but eliminate rangesize member. 
Older targets will preserve ip_nat_multi_range_compat, while those which 
support multiple targets will use this new structure.

However, there is a problem and I need your help. Linked lists need 
linux/list.h, but that one checks for __KERNEL__ and backfires when you 
need to compile iptables. As I see it, there are two solutions for that:
1) Using a "ip_nat_multi_range *next" pointer instead of using kernel's 
list_head. This fulfills all requirements for my patch, but I don't know 
if it's okay for kernel devels to use nonstandard lists (though there is 
no single-linked list implementation in kernel AFAIK).
2) Providing different linux/list.h in iptables package. This will bring 
up future API compatibility issues, so we need to maintain that header 
and insert checks for kernel version.
3) Modify linux/list.h so that it doesn't check anymore for __KERNEL__. 
Kernel devels won't be happy about this AFAICS.

If you have any other advice regarding my ideas on how to implement 
this, feel free to ask. I already came up with a patch for iptables' 
REDIRECT target, it just needs to have that linked list thingy filled up.

Re: Multiple targets for REDIRECT & friends

[Munteanu Eduard Gabriel]

Well, it seems I haven't checked out iptables package thoroughly enough 
before posting here. There is libiptc/linux_list.h which looks like an 
API-compatible userspace implementation of double-linked lists in kernel.

Having this thing answered by myself, I'm asking you the following 
question: should I use these double-linked lists or avoid complexity by 
coming up with some "homemade" single-linked lists? It just needs a 
*next pointer, as I said, so it should be a less complex mechanism. 
Either way, I'll start working on one of these ideas (most probably the 
2nd, since I think it's the right thing to do), since switching to 
another flavour of linked lists is no problem.

Hope to hear from you guys soon,
Eduard Munteanu

P.S.: sorry for posting twice the last message. At first, I didn't want 
to subscribe to the list, so after sending it, I have seen that the 
archives (despite the fact they were enough up-to-date) did not contain 
my post. So I subscribed to the mailing list and sent it again, which 
made my 2nd post go in the archive pretty fast.

Multiple targets for REDIRECT & friends

[Munteanu Eduard Gabriel]

I'm looking to contribute this to netfilter.

Right now, ip_nat_multi_range is typedeffed (as a macro, though) to
ip_nat_multi_range_compat. I think it will be okay to make
ip_nat_multi_range be a linked list, but eliminate rangesize member.
Older targets will preserve ip_nat_multi_range_compat, while those which
support multiple targets will use this new structure.

However, there is a problem and I need your help. Linked lists need
linux/list.h, but that one checks for __KERNEL__ and backfires when you
need to compile iptables. As I see it, there are two solutions for that:
1) Using a "ip_nat_multi_range *next" pointer instead of using kernel's
list_head. This fulfills all requirements for my patch, but I don't know
if it's okay for kernel devels to use nonstandard lists (though there is
no single-linked list implementation in kernel AFAIK).
2) Providing different linux/list.h in iptables package. This will bring
up future API compatibility issues, so we need to maintain that header
and insert checks for kernel version.
3) Modify linux/list.h so that it doesn't check anymore for __KERNEL__.
Kernel devels won't be happy about this AFAICS.

If you have any other advice regarding my ideas on how to implement
this, feel free to ask. I already came up with a patch for iptables'
REDIRECT target, it just needs to have that linked list thingy filled up.