Well, let me put it this way:
1. NFS locking worked on ARM in 2.2.17 without any problems or modifications
what so ever.
2. NFS locking does NOT work on ARM without the above patch. It FAILS
completely.
> I also don't understand Alan's comment, what has the cast of data to a
> structure have to do with the size of a field in the structure?
I won't bother replying to this, since you obviously know the answer from
your following comment. ;)
> Furthmore
> the cast of data to a struct should work on all architectures as far as C is
> concerned (if you then run alignment problems then it's your mistake).
WRONG WRONG WRONG WRONG WRONG. You are *SO* wrong.
C explicitly allows this behaviour. The fact that most processors can load
unaligned data without any trouble is merely co-incidence and leads to BAD
programming techniques, like this one illusatrated above.
Therefore, it is BAD code which needs to be fixed. Now, on ARM, all
structures are defined by the ABI to be aligned to a 32-bit word. End
of story. No other story will do. Finito. Capisco?
Yes, you can get around them by taking an alignment abort, but that is REALLY
REALLY expensive. Eg, instead of a load taking 1 cycle, it turns into around
500 cycles, just to decode the instruction by hand, calculate the addresses,
calculate the side effects and implement them.
So, if we can get away with a little BETTER coding technique, then that is
FAR FAR better than thaning a 499 cycle penalty.
Oh, and did I mention that x86 also has a performance penalty for unaligned
loads as well?
> So for now I backed it out. If you want to push it in again then implement
> it right and make an mount backwards compatible nfs_fh type for the
> nfs_mount_data.
This is pretty gawling, especially as the fix was posted to the NFS
development list and not one person complained that it would break any APIs.
I'd like the NFS developers to look at this. Yes, I'm delegating it. Why?
I've got too much on my plate at the moment, and I'm desperately trying to
get rid of the 2.2 ARM kernel tree so I can concentrate on 2.4 only. In the
spirit of open source, I am willing to test patches that claim to fix this
problem once I've got my 2.2 kernel tree back into a reasonable state (after
chasing some 128MB bad DIMM problem around for 2 months across 2 versions of
Linux).
And yes, APIs shouldn't break in a major kernel release. Its a shame some
API broke in 2.2.18.
_____
|_____| ------------------------------------------------- ---+---+-
| | Russell King rmk@arm.linux.org.uk --- ---
| | | | http://www.arm.linux.org.uk/personal/aboutme.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ ------------------------------------------------- /\\\ |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/