64bit changes in cvs

64bit changes in cvs

[Martin Josefsson]

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

Hi

During the day I've committed some patches into the iptables tree to get
things working better on 64bit kernels (with both 32bit and 64bit
userspace).
(only tested on sparc64 and compile-tested on alpha. x86_64 and ia64
will most likely need more love in order to work correctly with 32bit
userspace, more on that later)

All matches and targets in the 2.6 kernel works fine on the sparc64
kernel now. One thing to mention concerns the ULOG target, the iptables
part of it works fine with both 32bit and 64bit userspace, but the ulogd
daemon _must_ be 64bit compiled in order to recieve packets correctly
from kernel, this is true for all 64bit kernels.

I've reworked the part of the makefile that tries to detect if you are
compiling a 32bit iptables against a 64bit kernel. I hope it works...

To those of you who have 64bit machines, please test and report any
problems (including x86_64 / ia64 if you are feeling brave but it will
probably fail :)

-- 
/Martin

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 64bit changes in cvs

[Pablo Neira]

Hi Martin,

Martin Josefsson wrote:

>All matches and targets in the 2.6 kernel works fine on the sparc64
>kernel now. One thing to mention concerns the ULOG target, the iptables
>part of it works fine with both 32bit and 64bit userspace, but the ulogd
>daemon _must_ be 64bit compiled in order to recieve packets correctly
>from kernel, this is true for all 64bit kernels.
>  
>

I sent a patch to add autoconf some time ago, actually to fix this issue 
with 32bit in user space, 64 bit in kernel space architectures.

Well, I just want to reopen some discussion if possible, if you consider 
that autoconf is more than we need for iptables it's ok I will understand.

Please see:
http://lists.netfilter.org/pipermail/netfilter-devel/2004-May/015245.html
http://lists.netfilter.org/pipermail/netfilter-devel/2004-May/015246.html

>I've reworked the part of the makefile that tries to detect if you are
>compiling a 32bit iptables against a 64bit kernel. I hope it works...
>  
>

What did you use? uname stuff? I'll promise to have a look at CVS when 
having some spare time.

regards,
Pablo

Re: 64bit changes in cvs

[Martin Josefsson]

On Fri, 28 May 2004, Pablo Neira wrote:

> Hi Martin,

Hi Pablo

> I sent a patch to add autoconf some time ago, actually to fix this issue
> with 32bit in user space, 64 bit in kernel space architectures.
>
> Well, I just want to reopen some discussion if possible, if you consider
> that autoconf is more than we need for iptables it's ok I will understand.

I know almost nothing about autoconf (more than I think it's very bloated
:), I'll see if I can make some time to actually look at it.

> Please see:
> http://lists.netfilter.org/pipermail/netfilter-devel/2004-May/015245.html
> http://lists.netfilter.org/pipermail/netfilter-devel/2004-May/015246.html
>
> >I've reworked the part of the makefile that tries to detect if you are
> >compiling a 32bit iptables against a 64bit kernel. I hope it works...
> >
> >
>
> What did you use? uname stuff? I'll promise to have a look at CVS when
> having some spare time.

Just remember that I never said it was pretty... :)
I use uname and check the BITS_PER_LONG macro in the kernel we are
compiling against and I try to determine if we are compiling 32bit or
64bit. It isn't pretty but it's an improvement over the previous version.
As that blindly said that uname -m == sparc64 always was 32bit userspace
(and the extra define wasn't propagated to the extensions/ directory)

It seems to do the right(tm) thing on x86, sparc64 (32/64bit userspace)
and alpha, don't have access to more architectures.

/Martin

Re: 64bit changes in cvs

[Henrik Nordstrom]

On Fri, 28 May 2004, Martin Josefsson wrote:

> I know almost nothing about autoconf (more than I think it's very bloated
> :), I'll see if I can make some time to actually look at it.

It is very bloated for a project targeting only a single OS / libc..

But for any other project the bloat makes detecting all those platform 
dependent junk, compile time options etc a magnitude easier to manage..

Regards
Henrik