Re: [PATCH 2.4] jffs2 aligment problems

[David Woodhouse <dwmw2@infradead.org>]

On Mon, 2004-06-07 at 17:41 +0100, Russell King wrote:
> > Pleas fix jffs2 to use the proper "get_unaligned()"/"put_unaligned()"
> > instead.

> I'll let you have a bun fight with dwmw2 and networking people over
> this.  I'm standing well clear. 8)

S'fine by me. I already added get_unaligned() to the flash drivers years
ago -- it's actually those, not JFFS2 itself which needs it. Alan
insisted I remove it on the basis that much of our network code is
similarly broken anyway; an arch without fixups is dead in the water
whatever happens.

Admittedly it's not _entirely_ stupid in the network code, because a
direct load is often a lot faster than the byte-wise load emitted by
get_unaligned(). If alignment is the common case, it makes some sense to
optimise that and take the trap only occasionally.

But with uClinux being merged (many uClinux arches can't fix up
alignment at all), I think we should revisit that decision.

Anything which _could_ be unaligned should be marked as such, even if we
do have two levels ('possibly unaligned', 'probably unaligned') where
the latter behaves purely as an optimisation on most arches, just like
our current get_unaligned() does.

Or in fact since the ratio between the speeds of the inline and the trap
version varies wildly from arch to arch, and hence the point at which it
becomes more efficient just to use the current get_unaligned() varies --
perhaps we should have 'get_unaligned(ptr, probability)' and let the
arch code decide where the threshold should be. It's not that hard to
make it go away completely given __builtin_constant_p(probability) and
some preprocessor macros.

-- 
dwmw2