On Fri, Mar 01, 2013 at 12:59:18PM +0200, Mihail Costea wrote:
Hi,
I've started implementing DAT for IPv6 and I have a few questions regarding the design. I've already implemented a snooping mechanism for Network Solicitation package, but now I have to add it to the ipv6 distributed table. I'm also a beginner in kernel programming so any help would be useful.
From what I've seen there is a lot of code in distributed-arp-table.c that could be used for ipv6 distributed table.
yeah, I think that the table handling and DHT primitives can be reused for IPv6 (they were designed on purpose).
A problem in using that code, from what I've seen, is the fact that <struct batadv_dat_entry > has a field for ip with only 32 bits (__be32).
Yes, here a way to generalise the structure is needed.
So I was thinking to make it more general by:
- transforming that into a pointer (unsigned char *ip) and add a
field size which will represent the total size of the ip. The ip itself would be allocated dynamically. 2. use a union with both _be32 / struct in6_addr. In this case the problem is that if we use ipv4 then all the other space for struct in6_addr would be wasted.
correct. and for point 2) I think we waste a not negligible amount of memory..
The second problem from what I've seen in the code is that the batadv_priv->dat field is hardcoded. For ipv6 we would need a new field to memorize the table, but I don't think it's a really hard problem to solve in order to make it general.
I did not get the problem with the dat field? Can't you use the same table to store both IPv4 and IPv6? The DHT is made to store general data, so I think (with the suggestions you wrote above) that you should be able to use one table only.
This solution would be to avoid code duplicate. Off course, I could still write all the code in parallel just for IPv6, but I think that a common base would be useful.
Re-use code is definitely the way to go :) easy maintenance later, one single point for bug-fixing and code has been tested already (so it should work[tm] as expected :-))
Thanks,
no worries :)
Cheers,