[NETFILTER] Kill lockhelp.h for rtsp-conntrack

[NETFILTER] Kill lockhelp.h for rtsp-conntrack

[Samir Bellabes]

[-- Attachment #1: Type: text/plain, Size: 140 bytes --]

Hi,
This patch fix the match 'rtsp-conntrack', after the kill_lockhelp.patch
Please apply at top of the svn tree.

regards,
Samir Bellabes


[-- Attachment #2: rtsp-conntrack_kill_lockhelp.patch --]
[-- Type: text/x-patch, Size: 812 bytes --]

[NETFILTER] Kill lockhelp.h for rtsp_conntrack

------------------------------------------------------------------------------

 ip_conntrack_rtsp.h |    2 --
 1 files changed, 2 deletions(-)

------------------------------------------------------------------------------
Index: patchlets/rtsp-conntrack/linux-2.6.11/include/linux/netfilter_ipv4/ip_conntrack_rtsp.h
===================================================================
--- patchlets/rtsp-conntrack/linux-2.6.11/include/linux/netfilter_ipv4/ip_conntrack_rtsp.h	(révision 4248)
+++ patchlets/rtsp-conntrack/linux-2.6.11/include/linux/netfilter_ipv4/ip_conntrack_rtsp.h	(copie de travail)
@@ -49,8 +49,6 @@
 
 #ifdef __KERNEL__
 
-#include <linux/netfilter_ipv4/lockhelp.h>
-
 #define RTSP_PORT   554
 
 #endif /* __KERNEL__ */

Re: [NETFILTER] Kill lockhelp.h for rtsp-conntrack

[Samir Bellabes]

Samir Bellabes <sbellabes@mandriva.com> writes:

> Please apply at top of the svn tree.
well, in fact, it should be applyed to a new 'linux-2.6.13' directory..

regards,
Samir Bellabes

Re: [NETFILTER] Kill lockhelp.h for rtsp-conntrack

[Patrick McHardy]

Samir Bellabes wrote:
> Samir Bellabes <sbellabes@mandriva.com> writes:
> 
> 
>>Please apply at top of the svn tree.

All applied, thanks. I've changed the raw spinlock/rwlock declarations
to DEFINE_SPINLOCK/DECLARE_RWLOCK.

> well, in fact, it should be applyed to a new 'linux-2.6.13' directory..

Do you mean it needs to be applied to other directories than -p1 in the
patchlets dir?

Re: [NETFILTER] Kill lockhelp.h for rtsp-conntrack

[Samir Bellabes]

Patrick McHardy <kaber@trash.net> writes:

> All applied, thanks. I've changed the raw spinlock/rwlock declarations
> to DEFINE_SPINLOCK/DECLARE_RWLOCK.
ok, thanks.

>> well, in fact, it should be applyed to a new 'linux-2.6.13' directory..
>
> Do you mean it needs to be applied to other directories than -p1 in the
> patchlets dir?

I mean that linux-2.6.11 don't need this patch at all.
As far a you push 'kill lockhelp.h patch' in 2.6.13, people who use
p-o-m with a kernel version < 2.6.13, should use lockhelp.h again.
But now, this 3 patches will apply to all versions.

But it's not a main problem. And yes, i know versionning in p-o-m is
always discussed.

thanks for applying,
Samir Bellabes

Re: [NETFILTER] Kill lockhelp.h for rtsp-conntrack

[Patrick McHardy]

Samir Bellabes wrote:
> Patrick McHardy <kaber@trash.net> writes:
> 
> 
>>All applied, thanks. I've changed the raw spinlock/rwlock declarations
>>to DEFINE_SPINLOCK/DECLARE_RWLOCK.
> 
> ok, thanks.
> 
> 
>>>well, in fact, it should be applyed to a new 'linux-2.6.13' directory..
>>
>>Do you mean it needs to be applied to other directories than -p1 in the
>>patchlets dir?
> 
> 
> I mean that linux-2.6.11 don't need this patch at all.
> As far a you push 'kill lockhelp.h patch' in 2.6.13, people who use
> p-o-m with a kernel version < 2.6.13, should use lockhelp.h again.
> But now, this 3 patches will apply to all versions.

I don't know what the general feeling about supporting old versions
in pom is, I would tend to ignore them if it means starting a third
linux subdirectory that should be maintained in some patchlets.
Harald, what is your opinion on this?

Re: [NETFILTER] Kill lockhelp.h for rtsp-conntrack

[Harald Welte]

On Tue, Aug 30, 2005 at 01:00:42AM +0200, Patrick McHardy wrote:

> > I mean that linux-2.6.11 don't need this patch at all.
> > As far a you push 'kill lockhelp.h patch' in 2.6.13, people who use
> > p-o-m with a kernel version < 2.6.13, should use lockhelp.h again.
> > But now, this 3 patches will apply to all versions.
> 
> I don't know what the general feeling about supporting old versions
> in pom is, I would tend to ignore them if it means starting a third
> linux subdirectory that should be maintained in some patchlets.
> Harald, what is your opinion on this?

I would rather start a new subdirectory than patching the old code.
This way users of old kernels can have a working version, too (even if
that old version doesn't have all the features or receives all the
patches that newer versions do).  At least as long as we're using the
current patch-o-matic-ng, I think that's the way to go.

When we decide do get rid of patch-o-matic-ng at some point, we
obviously can also drop the 'old kernel' requirement.

-- 
- Harald Welte <laforge@netfilter.org>                 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

Re: [NETFILTER] Kill lockhelp.h for rtsp-conntrack

[Patrick McHardy]

Harald Welte wrote:
> On Tue, Aug 30, 2005 at 01:00:42AM +0200, Patrick McHardy wrote:
> 
> 
>>>I mean that linux-2.6.11 don't need this patch at all.
>>>As far a you push 'kill lockhelp.h patch' in 2.6.13, people who use
>>>p-o-m with a kernel version < 2.6.13, should use lockhelp.h again.
>>>But now, this 3 patches will apply to all versions.
>>
>>I don't know what the general feeling about supporting old versions
>>in pom is, I would tend to ignore them if it means starting a third
>>linux subdirectory that should be maintained in some patchlets.
>>Harald, what is your opinion on this?
> 
> 
> I would rather start a new subdirectory than patching the old code.
> This way users of old kernels can have a working version, too (even if
> that old version doesn't have all the features or receives all the
> patches that newer versions do).  At least as long as we're using the
> current patch-o-matic-ng, I think that's the way to go.

Ok, I'll fix it up tomorrow. Still something to discuss at the workshop
I think, putting time into maintaining compatibility with old kernels
is badly invested time IMO.

> When we decide do get rid of patch-o-matic-ng at some point, we
> obviously can also drop the 'old kernel' requirement.

Obviously :)