netdev
[Top] [All Lists]

Re: ipt_physdev.c alignment problems on parisc64

To: Bart De Schuymer <bdschuym@xxxxxxxxxx>
Subject: Re: ipt_physdev.c alignment problems on parisc64
From: "David S. Miller" <davem@xxxxxxxxxx>
Date: Sat, 13 Sep 2003 19:25:22 -0700
Cc: laforge@xxxxxxxxxxxxx, acme@xxxxxxxxxxxxxxxx, netfilter-devel@xxxxxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <200309132159.37834.bdschuym@xxxxxxxxxx>
References: <200309022116.41697.bdschuym@xxxxxxxxxx> <20030905153152.GA3623@xxxxxxxxxxxxxxxxxxxxxxxxxx> <20030908191400.5ef59ab6.davem@xxxxxxxxxx> <200309132159.37834.bdschuym@xxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
On Sat, 13 Sep 2003 21:59:37 +0200
Bart De Schuymer <bdschuym@xxxxxxxxxx> wrote:

> It just uses unsigned int instead of unsigned long, so there should
> be no problem with the evil Sparc64.

Sparc64 doesn't have the problems, it just fixes up the unaligned
accesses there so it'll just be super-slow (some "optimization" :).

The problem is on parisc64 which is very strict about accessing
structure members which are not aligned to the accessor type you use
to dereference and gives you a link/compile error when you violate
this.

> Perhaps the ip_tables.c code from which I copied the original code
> should be altered too.

Yes.

> It's a real optimization btw, the .o file is 32 bytes
> larger when doing the bit operations on a char with i<IFNAMSIZ.
> All hail Rusty :)

I understand, but instead create an arch routine to optimize this
instead of using non-portable constructs.  memcmp_masked() or
something like that.

<Prev in Thread] Current Thread [Next in Thread>