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

[Patrick McHardy <kaber@trash.net>]

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