1 If variable is of Type, use printk format specifier:
2 ---------------------------------------------------------
6 unsigned long %lu or %lx
8 unsigned long long %llu or %llx
16 If <type> is dependent on a config option for its size (e.g., sector_t,
17 blkcnt_t) or is architecture-dependent for its size (e.g., tcflag_t), use a
18 format specifier of its largest possible type and explicitly cast to it.
21 printk("test: sector number/total blocks: %llu/%llu\n",
22 (unsigned long long)sector, (unsigned long long)blockcount);
24 Reminder: sizeof() result is of type size_t.
27 Raw pointer value SHOULD be printed with %p. The kernel supports
28 the following extended format specifiers for pointer types:
30 Symbols/Function Pointers:
32 %pF versatile_init+0x0/0x110
34 %pS versatile_init+0x0/0x110
35 %pSR versatile_init+0x9/0x110
36 (with __builtin_extract_return_addr() translation)
38 %pB prev_fn_of_versatile_init+0x88/0x88
40 For printing symbols and function pointers. The 'S' and 's' specifiers
41 result in the symbol name with ('S') or without ('s') offsets. Where
42 this is used on a kernel without KALLSYMS - the symbol address is
45 The 'B' specifier results in the symbol name with offsets and should be
46 used when printing stack backtraces. The specifier takes into
47 consideration the effect of compiler optimisations which may occur
48 when tail-call's are used and marked with the noreturn GCC attribute.
50 On ia64, ppc64 and parisc64 architectures function pointers are
51 actually function descriptors which must first be resolved. The 'F' and
52 'f' specifiers perform this resolution and then provide the same
53 functionality as the 'S' and 's' specifiers.
57 %pK 0x01234567 or 0x0123456789abcdef
59 For printing kernel pointers which should be hidden from unprivileged
60 users. The behaviour of %pK depends on the kptr_restrict sysctl - see
61 Documentation/sysctl/kernel.txt for more details.
65 %pr [mem 0x60000000-0x6fffffff flags 0x2200] or
66 [mem 0x0000000060000000-0x000000006fffffff flags 0x2200]
67 %pR [mem 0x60000000-0x6fffffff pref] or
68 [mem 0x0000000060000000-0x000000006fffffff pref]
70 For printing struct resources. The 'R' and 'r' specifiers result in a
71 printed resource with ('R') or without ('r') a decoded flags member.
74 Physical addresses types phys_addr_t:
76 %pa[p] 0x01234567 or 0x0123456789abcdef
78 For printing a phys_addr_t type (and its derivatives, such as
79 resource_size_t) which can vary based on build options, regardless of
80 the width of the CPU data path. Passed by reference.
82 DMA addresses types dma_addr_t:
84 %pad 0x01234567 or 0x0123456789abcdef
86 For printing a dma_addr_t type which can vary based on build options,
87 regardless of the width of the CPU data path. Passed by reference.
89 Raw buffer as an escaped string:
93 For printing raw buffer as an escaped string. For the following buffer
95 1b 62 20 5c 43 07 22 90 0d 5d
97 few examples show how the conversion would be done (the result string
98 without surrounding quotes):
100 %*pE "\eb \C\a"\220\r]"
101 %*pEhp "\x1bb \C\x07"\x90\x0d]"
102 %*pEa "\e\142\040\\\103\a\042\220\r\135"
104 The conversion rules are applied according to an optional combination
105 of flags (see string_escape_mem() kernel documentation for the
114 By default ESCAPE_ANY_NP is used.
116 ESCAPE_ANY_NP is the sane choice for many cases, in particularly for
119 If field width is omitted the 1 byte only will be escaped.
121 Raw buffer as a hex string:
123 %*phC 00:01:02: ... :3f
124 %*phD 00-01-02- ... -3f
127 For printing a small buffers (up to 64 bytes long) as a hex string with
128 certain separator. For the larger buffers consider to use
133 %pM 00:01:02:03:04:05
134 %pMR 05:04:03:02:01:00
135 %pMF 00-01-02-03-04-05
139 For printing 6-byte MAC/FDDI addresses in hex notation. The 'M' and 'm'
140 specifiers result in a printed address with ('M') or without ('m') byte
141 separators. The default byte separator is the colon (':').
143 Where FDDI addresses are concerned the 'F' specifier can be used after
144 the 'M' specifier to use dash ('-') separators instead of the default
147 For Bluetooth addresses the 'R' specifier shall be used after the 'M'
148 specifier to use reversed byte order suitable for visual interpretation
149 of Bluetooth addresses which are in the little endian order.
159 For printing IPv4 dot-separated decimal addresses. The 'I4' and 'i4'
160 specifiers result in a printed address with ('i4') or without ('I4')
163 The additional 'h', 'n', 'b', and 'l' specifiers are used to specify
164 host, network, big or little endian order addresses respectively. Where
165 no specifier is provided the default network/big endian order is used.
171 %pI6 0001:0002:0003:0004:0005:0006:0007:0008
172 %pi6 00010002000300040005000600070008
173 %pI6c 1:2:3:4:5:6:7:8
175 For printing IPv6 network-order 16-bit hex addresses. The 'I6' and 'i6'
176 specifiers result in a printed address with ('I6') or without ('i6')
177 colon-separators. Leading zeros are always used.
179 The additional 'c' specifier can be used with the 'I' specifier to
180 print a compressed IPv6 address as described by
181 http://tools.ietf.org/html/rfc5952
185 IPv4/IPv6 addresses (generic, with port, flowinfo, scope):
187 %pIS 1.2.3.4 or 0001:0002:0003:0004:0005:0006:0007:0008
188 %piS 001.002.003.004 or 00010002000300040005000600070008
189 %pISc 1.2.3.4 or 1:2:3:4:5:6:7:8
190 %pISpc 1.2.3.4:12345 or [1:2:3:4:5:6:7:8]:12345
193 For printing an IP address without the need to distinguish whether it's
194 of type AF_INET or AF_INET6, a pointer to a valid 'struct sockaddr',
195 specified through 'IS' or 'iS', can be passed to this format specifier.
197 The additional 'p', 'f', and 's' specifiers are used to specify port
198 (IPv4, IPv6), flowinfo (IPv6) and scope (IPv6). Ports have a ':' prefix,
199 flowinfo a '/' and scope a '%', each followed by the actual value.
201 In case of an IPv6 address the compressed IPv6 address as described by
202 http://tools.ietf.org/html/rfc5952 is being used if the additional
203 specifier 'c' is given. The IPv6 address is surrounded by '[', ']' in
204 case of additional specifiers 'p', 'f' or 's' as suggested by
205 https://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-07
207 In case of IPv4 addresses, the additional 'h', 'n', 'b', and 'l'
208 specifiers can be used as well and are ignored in case of an IPv6
215 %pISfc 1.2.3.4 or [1:2:3:4:5:6:7:8]/123456789
216 %pISsc 1.2.3.4 or [1:2:3:4:5:6:7:8]%1234567890
217 %pISpfc 1.2.3.4:12345 or [1:2:3:4:5:6:7:8]:12345/123456789
221 %pUb 00010203-0405-0607-0809-0a0b0c0d0e0f
222 %pUB 00010203-0405-0607-0809-0A0B0C0D0E0F
223 %pUl 03020100-0504-0706-0809-0a0b0c0e0e0f
224 %pUL 03020100-0504-0706-0809-0A0B0C0E0E0F
226 For printing 16-byte UUID/GUIDs addresses. The additional 'l', 'L',
227 'b' and 'B' specifiers are used to specify a little endian order in
228 lower ('l') or upper case ('L') hex characters - and big endian order
229 in lower ('b') or upper case ('B') hex characters.
231 Where no additional specifiers are used the default big endian
232 order with lower case hex characters will be printed.
240 For printing dentry name; if we race with d_move(), the name might be
241 a mix of old and new ones, but it won't oops. %pd dentry is a safer
242 equivalent of %s dentry->d_name.name we used to use, %pd<n> prints
243 n last components. %pD does the same thing for struct file.
251 For printing struct va_format structures. These contain a format string
252 and va_list as follows:
259 Do not use this feature without some mechanism to verify the
260 correctness of the format string and va_list arguments.
270 For printing struct clk structures. '%pC' and '%pCn' print the name
271 (Common Clock Framework) or address (legacy clock framework) of the
272 structure; '%pCr' prints the current clock rate.
276 bitmap and its derivatives such as cpumask and nodemask:
281 For printing bitmap and its derivatives such as cpumask and nodemask,
282 %*pb output the bitmap with field width as the number of bits and %*pbl
283 output the bitmap as range list with field width as the number of bits.
287 Thank you for your cooperation and attention.
290 By Randy Dunlap <rdunlap@infradead.org> and
291 Andrew Murray <amurray@mpc-data.co.uk>