On Tue, Apr 11, 2006 at 04:42:50PM +0200, Patrick McHardy wrote:
> > Maybe we should add a printk ('app foo is using obsolete ip_queue
> > system').
>
> Good idea, that will probably help speed it up. But I still think
> we need to give them at least another six month.ok. I'll prepare a patch for both the printk and the update of feature-removal-schedule. > I think we need to do two things: > > - make libipq_compat a drop-in replacement that doesn't require > recompilation libipq is not distributed as a shared library (at least not by us), so I don't see any purpose for doing so. Do you think anyone is going to re-link statically linked code against the new lib > - make it work with both ipq and nfnetlink_queue that should be possible, though. I still don't really think that it is worth all the effort, especially since there is only one hand full of applications using libipq. The backwards compatibility library is expected to perform a lot worse thna both the old libipq as well as the new native libnetfilter_queue due to additional data copies, etc. When I wrote it, it was more intended as some intermediate aid, something that helps while people migrate. We shouldn't make it too perfect, otherwise they won't migrate at all. -- - Harald Welte <[EMAIL PROTECTED]> http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie
pgpUyDjQahTpM.pgp
Description: PGP signature
