Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux

unaligned-memory-access.txt: standardize document format

Each text file under Documentation follows a different
format. Some doesn't even have titles!

Change its representation to follow the adopted standard,
using ReST markups for it to be parseable by Sphinx:
- promote document title one level;
- use markups for authorship and put it at the beginning;
- mark literal blocks;
- adjust identation.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

authored by

Mauro Carvalho Chehab and committed by
Jonathan Corbet
c6ebaf6b 79ab3b0d

+30 -27
+30 -27
Documentation/unaligned-memory-access.txt
··· 1 + ========================= 1 2 UNALIGNED MEMORY ACCESSES 2 3 ========================= 4 + 5 + :Author: Daniel Drake <dsd@gentoo.org>, 6 + :Author: Johannes Berg <johannes@sipsolutions.net> 7 + 8 + :With help from: Alan Cox, Avuton Olrich, Heikki Orsila, Jan Engelhardt, 9 + Kyle McMartin, Kyle Moffett, Randy Dunlap, Robert Hancock, Uli Kunitz, 10 + Vadim Lobanov 11 + 3 12 4 13 Linux runs on a wide variety of architectures which have varying behaviour 5 14 when it comes to memory access. This document presents some details about ··· 82 73 83 74 Fortunately things are not too complex, as in most cases, the compiler 84 75 ensures that things will work for you. For example, take the following 85 - structure: 76 + structure:: 86 77 87 78 struct foo { 88 79 u16 field1; ··· 115 106 that you could reorder the fields in the structure in order to place fields 116 107 where padding would otherwise be inserted, and hence reduce the overall 117 108 resident memory size of structure instances. The optimal layout of the 118 - above example is: 109 + above example is:: 119 110 120 111 struct foo { 121 112 u32 field2; ··· 148 139 With the above in mind, let's move onto a real life example of a function 149 140 that can cause an unaligned memory access. The following function taken 150 141 from include/linux/etherdevice.h is an optimized routine to compare two 151 - ethernet MAC addresses for equality. 142 + ethernet MAC addresses for equality:: 152 143 153 - bool ether_addr_equal(const u8 *addr1, const u8 *addr2) 154 - { 155 - #ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS 144 + bool ether_addr_equal(const u8 *addr1, const u8 *addr2) 145 + { 146 + #ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS 156 147 u32 fold = ((*(const u32 *)addr1) ^ (*(const u32 *)addr2)) | 157 148 ((*(const u16 *)(addr1 + 4)) ^ (*(const u16 *)(addr2 + 4))); 158 149 159 150 return fold == 0; 160 - #else 151 + #else 161 152 const u16 *a = (const u16 *)addr1; 162 153 const u16 *b = (const u16 *)addr2; 163 154 return ((a[0] ^ b[0]) | (a[1] ^ b[1]) | (a[2] ^ b[2])) == 0; 164 - #endif 165 - } 155 + #endif 156 + } 166 157 167 158 In the above function, when the hardware has efficient unaligned access 168 159 capability, there is no issue with this code. But when the hardware isn't ··· 180 171 which is true almost all of the time in ethernet networking context. 181 172 182 173 183 - Here is another example of some code that could cause unaligned accesses: 174 + Here is another example of some code that could cause unaligned accesses:: 175 + 184 176 void myfunc(u8 *data, u32 value) 185 177 { 186 178 [...] ··· 194 184 195 185 In summary, the 2 main scenarios where you may run into unaligned access 196 186 problems involve: 187 + 197 188 1. Casting variables to types of different lengths 198 189 2. Pointer arithmetic followed by access to at least 2 bytes of data 199 190 ··· 206 195 put_unaligned() macros provided by the <asm/unaligned.h> header file. 207 196 208 197 Going back to an earlier example of code that potentially causes unaligned 209 - access: 198 + access:: 210 199 211 200 void myfunc(u8 *data, u32 value) 212 201 { ··· 215 204 [...] 216 205 } 217 206 218 - To avoid the unaligned memory access, you would rewrite it as follows: 207 + To avoid the unaligned memory access, you would rewrite it as follows:: 219 208 220 209 void myfunc(u8 *data, u32 value) 221 210 { ··· 226 215 } 227 216 228 217 The get_unaligned() macro works similarly. Assuming 'data' is a pointer to 229 - memory and you wish to avoid unaligned access, its usage is as follows: 218 + memory and you wish to avoid unaligned access, its usage is as follows:: 230 219 231 220 u32 value = get_unaligned((u32 *) data); 232 221 ··· 256 245 4*n+2 or non-ethernet hardware, this can be a problem, and it is then 257 246 required to copy the incoming frame into an aligned buffer. Because this is 258 247 unnecessary on architectures that can do unaligned accesses, the code can be 259 - made dependent on CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS like so: 248 + made dependent on CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS like so:: 260 249 261 - #ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS 262 - skb = original skb 263 - #else 264 - skb = copy skb 265 - #endif 266 - 267 - -- 268 - Authors: Daniel Drake <dsd@gentoo.org>, 269 - Johannes Berg <johannes@sipsolutions.net> 270 - With help from: Alan Cox, Avuton Olrich, Heikki Orsila, Jan Engelhardt, 271 - Kyle McMartin, Kyle Moffett, Randy Dunlap, Robert Hancock, Uli Kunitz, 272 - Vadim Lobanov 273 - 250 + #ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS 251 + skb = original skb 252 + #else 253 + skb = copy skb 254 + #endif