libiptc, arptables, ebtables plans or so - and header files

libiptc, arptables, ebtables plans or so - and header files

[Jan Engelhardt]

Hi Patrick and list,


when Adam sent his xt_LED, I noticed that he avoided to create an 
xt_LED.h and instead had the definition of the blob structs directly in 
xt_LED.c and libxt_LED.c. It occurred to me that this has some 
implications.

Theoretically, we could kill all {ipt,ip6t,xt}_*.h files in 
<kernel>/include/linux/netfilter*/ -- since userspace, usually only 
iptables, does not make use of them anyway, but has its own copies.

Yes, for simplicity, we let unifdef run over these headers before 
copying them, but then again, when was the last time you had __KERNEL__ 
in xt_*.h?

I really doubt there are any other userspace programs of these 
files at this time. As I see it, these header files make only sense 
when you are crafting blobs when interacting with libiptc. I am not 
aware of any program making such extensive use of libiptc, probably due 
to libiptc having been very closely kept in the iptables garden.

I would be tempted to suggest their removal from 
<kernel>/include/linux/ and moving them into the code.

However... realistically you would need those files if you ever wanted 
to interpret the blob when dealing with iptc.

Giving this some consideration, perhaps these header files should be 
made available through iptables/a separate libiptc(-devel) package 
instead of the kernel.

All these philosophical questions lead to the question what should be 
done about libiptc itself. It only looks bad because of the macro 
substitution that is applied to produce a libip6tc... and this sort of 
thing cannot really be resolved I figured. As in, using VFT tables to 
dispatch for a given NFPROTO to get rid of the macro constructs is not 
going to buy us anything - the code is so identical, it's really because 
of miniscule differences between struct ipt_{internal_stuff} and struct 
ip6t_{internal_stuff} that seem to make this an impossible undertaking. 
Is it actually worth working on it?

I have stopped my efforts to push arptables into iptables because 
eventually I would have come to think about getting libiptc and libarptc 
together, and I practically just did that with iptc and ip6tc (see 
previous paragraph). Yeah I see it's SNAFU.

Possible exit? Clone iptables/libiptc/sonstwastables yet again into — 
this time — an nfproto-agnostic table structure, but keep most other 
pieces. No sample code yet, because I usually try to ask before going on 
tasks like these.

Comments?
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: libiptc, arptables, ebtables plans or so - and header files

[Rick Jones]

Jan Engelhardt wrote:
> Hi Patrick and list,
> 
> 
> when Adam sent his xt_LED, I noticed that he avoided to create an 
> xt_LED.h and instead had the definition of the blob structs directly in 
> xt_LED.c and libxt_LED.c. It occurred to me that this has some 
> implications.
> 
> Theoretically, we could kill all {ipt,ip6t,xt}_*.h files in 
> <kernel>/include/linux/netfilter*/ -- since userspace, usually only 
> iptables, does not make use of them anyway, but has its own copies.
> 
> Yes, for simplicity, we let unifdef run over these headers before 
> copying them, but then again, when was the last time you had __KERNEL__ 
> in xt_*.h?
> 
> I really doubt there are any other userspace programs of these 
> files at this time. As I see it, these header files make only sense 
> when you are crafting blobs when interacting with libiptc. I am not 
> aware of any program making such extensive use of libiptc, probably due 
> to libiptc having been very closely kept in the iptables garden.

Well, there are a few of us trying to scale the walls :)  Some may have 
even managed to sneak into the garden, but perhaps the bugspray will 
drive them back out again :)

More seriously though I thought your goal was a libiptc that could 
wander-out from behind the garden walls?  If that were to happen, 
wouldn't that want some form of .h files, and perhaps even taking the 
copies out of iptables itself?

rick jones

Re: libiptc, arptables, ebtables plans or so - and header files

[Patrick McHardy]

Jan Engelhardt wrote:
> Hi Patrick and list,
> 
> 
> when Adam sent his xt_LED, I noticed that he avoided to create an 
> xt_LED.h and instead had the definition of the blob structs directly in 
> xt_LED.c and libxt_LED.c. It occurred to me that this has some 
> implications.
> 
> Theoretically, we could kill all {ipt,ip6t,xt}_*.h files in 
> <kernel>/include/linux/netfilter*/ -- since userspace, usually only 
> iptables, does not make use of them anyway, but has its own copies.
> 
> Yes, for simplicity, we let unifdef run over these headers before 
> copying them, but then again, when was the last time you had __KERNEL__ 
> in xt_*.h?
> 
> I really doubt there are any other userspace programs of these 
> files at this time. As I see it, these header files make only sense 
> when you are crafting blobs when interacting with libiptc. I am not 
> aware of any program making such extensive use of libiptc, probably due 
> to libiptc having been very closely kept in the iptables garden.
> 
> I would be tempted to suggest their removal from 
> <kernel>/include/linux/ and moving them into the code.
> 
> However... realistically you would need those files if you ever wanted 
> to interpret the blob when dealing with iptc.
> 
> Giving this some consideration, perhaps these header files should be 
> made available through iptables/a separate libiptc(-devel) package 
> instead of the kernel.

About moving the definitions - I don't see what this would buy us.
Besides that, the kernel defines these structures, so they really
belong there.

> All these philosophical questions lead to the question what should be 
> done about libiptc itself. It only looks bad because of the macro 
> substitution that is applied to produce a libip6tc... and this sort of 
> thing cannot really be resolved I figured. As in, using VFT tables to 
> dispatch for a given NFPROTO to get rid of the macro constructs is not 
> going to buy us anything - the code is so identical, it's really because 
> of miniscule differences between struct ipt_{internal_stuff} and struct 
> ip6t_{internal_stuff} that seem to make this an impossible undertaking. 
> Is it actually worth working on it?

Without having looked at it in much detail, I think it should
be pretty easy to define per-family functions to fill the
ipt_entry/ip6t_entry structs and a struct to describe the
length and offset differences. The remaining parts are invariant
across families, so the code should be easily unifiable.

> I have stopped my efforts to push arptables into iptables because 
> eventually I would have come to think about getting libiptc and libarptc 
> together, and I practically just did that with iptc and ip6tc (see 
> previous paragraph). Yeah I see it's SNAFU.
> 
> Possible exit? Clone iptables/libiptc/sonstwastables yet again into — 
> this time — an nfproto-agnostic table structure, but keep most other 
> pieces. No sample code yet, because I usually try to ask before going on 
> tasks like these.
> 
> Comments?

I think the best way is to abstract the very minor differences
using an af-specific callback for *_entry and some length information.
But I'm not familiar with libarptc, so this might not be enough.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: libiptc, arptables, ebtables plans or so - and header files

[Jan Engelhardt]

On Monday 2008-11-10 19:07, Patrick McHardy wrote:
>
> Without having looked at it in much detail, I think it should
> be pretty easy to define per-family functions to fill the
> ipt_entry/ip6t_entry structs and a struct to describe the
> length and offset differences. The remaining parts are invariant
> across families, so the code should be easily unifiable.

struct iptc_handle {
	struct ipt_getinfo {
	};
	struct ipt_get_entries {
		struct ipt_entry [];
	};
};

TC_INIT/create_tc_socket(table)
{
	STRUCT_GETINFO info;
	strcpy(info.name, table);
	getsockopt(sockfd, TC_IPPROTO, SO_GET_INFO, &info...);
	h = alloc_handle(info.name, info.size, info.num_entries);
}

Just look at this pseudocode. The primitive transformation approach would be

	create_v4_socket(table)
	{
		struct ip6t_getinfo info;
		strcpy...
		getsockopt..
		h = alloc_handle...
	}
	
	create_v6_socket(table)
	{
		struct ip6t_getinfo info;
		strcpy...
		getsockopt..
		h = alloc_handle...
	}
	
	create_socket(table, proto)
	{
		return proto_vft[proto]->create_socket(table)
	}

This because every line where a member of info is accessed is
essentially af-dependent already. And I am not even down to
ipt_entry. It's not clear what to do here -- apart from ugly
tricks to record the offsets of members and then dereferencing
through void à la  (char *)(((void *)&info) + af->name_offset).
(Where's Captain Obvious when you need him?!)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: libiptc, arptables, ebtables plans or so - and header files

[Rick Jones]

For some reason, perhaps only to have my daily emily litella moment, the 
discussion of abstraction is reminding me of struct sockaddr_storage vs 
an IPv4 or IPv6 sockaddr.

rick jones

Re: libiptc, arptables, ebtables plans or so - and header files

[Jan Engelhardt]

On Monday 2008-11-10 19:53, Rick Jones wrote:

> For some reason, perhaps only to have my daily emily litella moment, the
> discussion of abstraction is reminding me of struct sockaddr_storage vs an IPv4
> or IPv6 sockaddr.

If you have worked with sockets you probably now.
Even though there is a struct/union sockaddr_storage,
you still end up duplicating all the code:

	struct sockaddr_storage p;
	if (af == PF_INET) {
		struct sockaddr_in *q = (void *)&p;
		p->sin_family = PF_INET;
		p->sin_port = htons(1234);
		inet_pton(PF_INET, host, &p->sin_addr);
	} else {
		struct sockaddr_in6 *q = (void *)&p;
		p->sin6_family = PF_INET6;
		p->sin6_port = htons(1234);
		inet_pton(PF_INET6, host, &p->sin6_addr);
	}

it illustrates the problem with libiptc even better than libiptc itself.

Re: libiptc, arptables, ebtables plans or so - and header files

[Patrick McHardy]

Jan Engelhardt wrote:
> On Monday 2008-11-10 19:07, Patrick McHardy wrote:
>> Without having looked at it in much detail, I think it should
>> be pretty easy to define per-family functions to fill the
>> ipt_entry/ip6t_entry structs and a struct to describe the
>> length and offset differences. The remaining parts are invariant
>> across families, so the code should be easily unifiable.
> 
> struct iptc_handle {
> 	struct ipt_getinfo {
> 	};
> 	struct ipt_get_entries {
> 		struct ipt_entry [];
> 	};
> };
> 
> TC_INIT/create_tc_socket(table)
> {
> 	STRUCT_GETINFO info;
> 	strcpy(info.name, table);
> 	getsockopt(sockfd, TC_IPPROTO, SO_GET_INFO, &info...);
> 	h = alloc_handle(info.name, info.size, info.num_entries);
> }
> 
> Just look at this pseudocode. The primitive transformation approach would be
> 
> 	create_v4_socket(table)
> 	{
> 		struct ip6t_getinfo info;
> 		strcpy...
> 		getsockopt..
> 		h = alloc_handle...
> 	}
> 	
> 	create_v6_socket(table)
> 	{
> 		struct ip6t_getinfo info;
> 		strcpy...
> 		getsockopt..
> 		h = alloc_handle...
> 	}
> 	
> 	create_socket(table, proto)
> 	{
> 		return proto_vft[proto]->create_socket(table)
> 	}
> 
> This because every line where a member of info is accessed is
> essentially af-dependent already.

An af-dependant function to get a pointer to the sub-structures
might simplify this a bit.

> And I am not even down to
> ipt_entry. It's not clear what to do here -- apart from ugly
> tricks to record the offsets of members and then dereferencing
> through void à la  (char *)(((void *)&info) + af->name_offset).

proto_vft[proto]->fill_entry(...)?
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html