[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.01.1212161815310.27614@nerf07.vanv.qr>
Date: Sun, 16 Dec 2012 18:21:08 +0100 (CET)
From: Jan Engelhardt <jengelh@...i.de>
To: Jamal Hadi Salim <jhs@...atatu.com>
cc: Pablo Neira Ayuso <pablo@...filter.org>,
Yury Stankevich <urykhy@...il.com>, shemonc@...il.com,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
netfilter-devel@...r.kernel.org
Subject: Re: tc ipt action
On Sunday 2012-12-16 11:43, Jamal Hadi Salim wrote:
> On 12-12-15 07:59 PM, Jan Engelhardt wrote:
>>
>
>> For the C level, there is XTABLES_VERSION_CODE.
>>
>> #if XTABLES_VERSION_CODE >= 6
>> if (m != NULL && m->x6_parse != NULL)
>> m->x6_parse(...)
>> #else
>> else if (m != NULL && m->parse != NULL)
>> m->parse(...)
>> ...
>>
>
> I think you are suggesting this to be done in tc. That would make it easier to
> fix.
> IMO, it is easier to keep backward compat if you left the old
> APIs around for a period of time
As you can see, the old ->parse() that goes back to libxtables.so.0
still remains. It's just that... only 5 out of 99 plugins still come
with an old parse function.
[m_xt] -> [libxtables] <- (plugins: libxt_*.so)
> and maybe log a warning that they
> will be deprecated over a period of time (sort of like kernel approach to
> changing APIs).
old parse has not entered any deprecation stage yet, since there are still
plugins out there (both the 5 and external ones) that make use of it.
Right now, both parse and x6_parse are valid.
> BTW: another interface that seems to have changed that we
> need is m->final_check().
Yes, all those with an x6_ prefix are new.
Mh, I already dream of plans reducing m_xt to something that
does not require libxtables.so anymore.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists