Re: user-space xtables ABI [was Re: [Fwd: Re: iptables pull request]]

[Pablo Neira Ayuso <pablo@netfilter.org>]

Jan Engelhardt wrote:
> On Sunday 2009-05-17 16:46, Pablo Neira Ayuso wrote:
>> With this policy, design errors accumulate along time so we learn the
>> lesson from our own mistakes and, then, we work on a new version 2 of
>> the API to resolve the accumulated issues after some time. This is how
>> I'm managing existing netfilter libraries. This policy makes the
>> developement of libraries/public interfaces slower but I think that
>> users are way happier (no binary breakages).
> 
> With that policy we end up with the same crap that is happening
> in the kernel.

I didn't say that this was nice, it's functional :)

> Just because we magically managed to stuff lots of functions into an
> .so file does not make it public. It just so happens to save a bunch
> of kilobytes in all of the binaries that were previously statically
> linked to xtables.c, and was deemed one way to figure out how to deal
> with intrusive m_ipt. Sorry, but in all efforts that went in so far,
> I discharge libxtables having a stable API. For that, the iptables
> code is not beauty enough yet.

I think that we should prioritize backward compatibility versus beauty.

> Now, I had to just think of Xtables-addons that has a similar issue.

Indeed, actually I think that a stable ABI would make this easier for you.

> For the kernel modules, it uses a separate compat_xtables.c glue
> module that hides the hacks needed for older versions.
> 
> Would tc profit from something similar for libxtables? It would gain
> the capability to work with iptableses potentially older than the
> reference point. But is that truly required? Upgrading userspace is a
> lot easier than the kernel. If a newer tc is installed on one's
> system, the user might just as well do so for iptables in the same
> run.

Sorry, I don't like that policy at all.

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers