DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=subject:from:to:cc:content-type:date:message-id:mime-version
         :x-mailer:content-transfer-encoding;
        b=cwZ3fWAgScrL2W+GJMxDWLbxxjpuNh3Z0ccaFShHzYIHZQfSOIjztjgBjljsfaX5XI
         zHocq5du0wVmDBYvE1COB19i12JCBUQk5XtQsRPx/Y/y6QUY1JYWra1CayJLP8eem/Pi
         f+rfMWbhQpKidwbl8b6y1M8+5d35a7/5U6Og0=
Subject: FRV/ARM unaligned access question
From: Harvey Harrison <harvey.harrison@gmail.com>
To: Russell King <rmk@arm.linux.org.uk>, David Howells <dhowells@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
       LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain
Date: Wed, 08 Oct 2008 00:26:13 -0700
Message-Id: <1223450773.8195.80.camel@brick>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1301
Lines: 34

David, Russell,

I noticed that frv/arm are the only two arches that currently use open-coded
byteshifting routines for both the cpu endianness and the other endianness
whereas just about all the other arches use a packed-struct version for the
cpu-endian and then the byteshifting versions (lifted from arm) for the other
endianness.

For frv, this was due to the consolidation of unaligned access helpers which
removed the assembly version.  For ARM, I think it was done this way as the
kernel could be compiled for either endianness and so it was just easiest to
always have the byteshifting versions around.  

>From the comments in the ARM version, time was spent to make sure the byteshifting
helpers used a small amount or registers.  Was there a known problem with the
packed-struct implementation on ARM that made you choose to use byte-shifting
or was it just done this way to more easily support compiling for different
endianness?

If there isn't an issue I'm missing, could ARM/FRV move over to the packed-struct
version?

Cheers,

Harvey


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/