linux-mips
[Top] [All Lists]

Re: [PATCH] Improve o32 syscall handling

To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Subject: Re: [PATCH] Improve o32 syscall handling
From: Ralf Baechle <ralf@linux-mips.org>
Date: Mon, 22 Nov 2004 08:13:13 +0100
Cc: linux-mips@linux-mips.org
In-reply-to: <20041122070003.GA902@rembrandt.csv.ica.uni-stuttgart.de>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20041121164557.GQ20986@rembrandt.csv.ica.uni-stuttgart.de> <20041122061854.GA25433@linux-mips.org> <20041122070003.GA902@rembrandt.csv.ica.uni-stuttgart.de>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.4.1i
On Mon, Nov 22, 2004 at 08:00:04AM +0100, Thiemo Seufer wrote:

> > Why bother, the unaligned exception handler should take care of this.
> 
> It really does so for unaligned accesses from kernel space?

Yes.  In fact it's crucially important for this very case.  TCP for example
may result in missalignment.  And not everybody is using get_unaligned /
put_unaligned as they were intended.  Relying on the unaligned handler
is preferable where we expect pointers to be properly aligned almost
always.

The MIPS ABI mandates at least 8 byte stack alignment and funny things
happen if that assumption is violated.  So there is no motivation at all
to care about the performance of missalignment.  Aside of me defining this
to be verboten by punishment of signal 9 ;-)

> has 4 bytes and is loaded with lw. Using a macro which abstracts for
> 32/64bit compilation hides this needlessly, and can even lead to the
> erraneous impression the code would be useful for 64bit, too.

I'm more following the religion of using such abstractions everywhere
because code tends to be copied around mindlessly ...

  Ralf

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