Phil: Yes, I certainly hope that the netfilter interface is byte level backwards compatible from the netfilter calls upwards, but there is a chance that compatibility is only from userspace libmnl and upwards. If that is the case, what kernel version release can I expect the current netfilter message packing structures to be changed where the current version 4.x kernel based libmnl would no longer work? It would be lovely if the kernel netfilter team documented the byte level interface that libmnl is written, but I don't have sponsorship dollars. Merry Christmas, Marco On Tue, Dec 20, 2016 at 11:21 AM, Phil Sutter <phil@xxxxxx> wrote: > Hi Mark, > > On Tue, Dec 20, 2016 at 10:27:45AM -0600, mark diener wrote: >> Will the V8 NFT have byte level protocol compatibility with current >> linux kernel versions? > > We were talking about nft manpage (which happens to live in section 8, > hence why I referred to it as 'nft.8'), not some version 8 (which would > still take a while to come as we're only at version 0.6 ATM). > >> I am deployed on kernel 4.4.0-53-generic and would like to know when >> structural defines like RTM_NEWADDR,NLM_F_REQUEST, etc become updated >> or obsoleted. > > Not sure I understand you correctly, but why should userspace exported > constants like RTM_NEWADDR or NLM_F_REQUEST become obsolete? This would > break backwards compatibility, which is generally frowned upon. > >> As you can likely tell, I am not using libmnl or libnft but using >> direct NETFILTER kernel calls. >> >> What a challenge to scan the code and reverse-engineer the byte >> sequences and understand the way the NFT virtual machine works in the >> kernel. > > Sounds like you're baking your own cake here. I'd say if you decide to > reinvent the wheel, well, then you have to invent a wheel. No? ;) > > Cheers, Phil -- 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
