diff options
author | Linus Torvalds <torvalds@ppc970.osdl.org> | 2005-04-16 18:20:36 -0400 |
---|---|---|
committer | Linus Torvalds <torvalds@ppc970.osdl.org> | 2005-04-16 18:20:36 -0400 |
commit | 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 (patch) | |
tree | 0bba044c4ce775e45a88a51686b5d9f90697ea9d /Documentation/arm/mem_alignment |
Linux-2.6.12-rc2v2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Diffstat (limited to 'Documentation/arm/mem_alignment')
-rw-r--r-- | Documentation/arm/mem_alignment | 58 |
1 files changed, 58 insertions, 0 deletions
diff --git a/Documentation/arm/mem_alignment b/Documentation/arm/mem_alignment new file mode 100644 index 000000000000..d145ccca169a --- /dev/null +++ b/Documentation/arm/mem_alignment | |||
@@ -0,0 +1,58 @@ | |||
1 | Too many problems poped up because of unnoticed misaligned memory access in | ||
2 | kernel code lately. Therefore the alignment fixup is now unconditionally | ||
3 | configured in for SA11x0 based targets. According to Alan Cox, this is a | ||
4 | bad idea to configure it out, but Russell King has some good reasons for | ||
5 | doing so on some f***ed up ARM architectures like the EBSA110. However | ||
6 | this is not the case on many design I'm aware of, like all SA11x0 based | ||
7 | ones. | ||
8 | |||
9 | Of course this is a bad idea to rely on the alignment trap to perform | ||
10 | unaligned memory access in general. If those access are predictable, you | ||
11 | are better to use the macros provided by include/asm/unaligned.h. The | ||
12 | alignment trap can fixup misaligned access for the exception cases, but at | ||
13 | a high performance cost. It better be rare. | ||
14 | |||
15 | Now for user space applications, it is possible to configure the alignment | ||
16 | trap to SIGBUS any code performing unaligned access (good for debugging bad | ||
17 | code), or even fixup the access by software like for kernel code. The later | ||
18 | mode isn't recommended for performance reasons (just think about the | ||
19 | floating point emulation that works about the same way). Fix your code | ||
20 | instead! | ||
21 | |||
22 | Please note that randomly changing the behaviour without good thought is | ||
23 | real bad - it changes the behaviour of all unaligned instructions in user | ||
24 | space, and might cause programs to fail unexpectedly. | ||
25 | |||
26 | To change the alignment trap behavior, simply echo a number into | ||
27 | /proc/sys/debug/alignment. The number is made up from various bits: | ||
28 | |||
29 | bit behavior when set | ||
30 | --- ----------------- | ||
31 | |||
32 | 0 A user process performing an unaligned memory access | ||
33 | will cause the kernel to print a message indicating | ||
34 | process name, pid, pc, instruction, address, and the | ||
35 | fault code. | ||
36 | |||
37 | 1 The kernel will attempt to fix up the user process | ||
38 | performing the unaligned access. This is of course | ||
39 | slow (think about the floating point emulator) and | ||
40 | not recommended for production use. | ||
41 | |||
42 | 2 The kernel will send a SIGBUS signal to the user process | ||
43 | performing the unaligned access. | ||
44 | |||
45 | Note that not all combinations are supported - only values 0 through 5. | ||
46 | (6 and 7 don't make sense). | ||
47 | |||
48 | For example, the following will turn on the warnings, but without | ||
49 | fixing up or sending SIGBUS signals: | ||
50 | |||
51 | echo 1 > /proc/sys/debug/alignment | ||
52 | |||
53 | You can also read the content of the same file to get statistical | ||
54 | information on unaligned access occurrences plus the current mode of | ||
55 | operation for user space code. | ||
56 | |||
57 | |||
58 | Nicolas Pitre, Mar 13, 2001. Modified Russell King, Nov 30, 2001. | ||