Merge tag 'v3.3.7' into 3.3/master
[zen-stable.git] / Documentation / printk-formats.txt
blob5df176ed59b826e8cbeaca7c96d6ed6d06759fa8
1 If variable is of Type,         use printk format specifier:
2 ---------------------------------------------------------
3                 int                     %d or %x
4                 unsigned int            %u or %x
5                 long                    %ld or %lx
6                 unsigned long           %lu or %lx
7                 long long               %lld or %llx
8                 unsigned long long      %llu or %llx
9                 size_t                  %zu or %zx
10                 ssize_t                 %zd or %zx
12 Raw pointer value SHOULD be printed with %p. The kernel supports
13 the following extended format specifiers for pointer types:
15 Symbols/Function Pointers:
17         %pF     versatile_init+0x0/0x110
18         %pf     versatile_init
19         %pS     versatile_init+0x0/0x110
20         %ps     versatile_init
21         %pB     prev_fn_of_versatile_init+0x88/0x88
23         For printing symbols and function pointers. The 'S' and 's' specifiers
24         result in the symbol name with ('S') or without ('s') offsets. Where
25         this is used on a kernel without KALLSYMS - the symbol address is
26         printed instead.
28         The 'B' specifier results in the symbol name with offsets and should be
29         used when printing stack backtraces. The specifier takes into
30         consideration the effect of compiler optimisations which may occur
31         when tail-call's are used and marked with the noreturn GCC attribute.
33         On ia64, ppc64 and parisc64 architectures function pointers are
34         actually function descriptors which must first be resolved. The 'F' and
35         'f' specifiers perform this resolution and then provide the same
36         functionality as the 'S' and 's' specifiers.
38 Kernel Pointers:
40         %pK     0x01234567 or 0x0123456789abcdef
42         For printing kernel pointers which should be hidden from unprivileged
43         users. The behaviour of %pK depends on the kptr_restrict sysctl - see
44         Documentation/sysctl/kernel.txt for more details.
46 Struct Resources:
48         %pr     [mem 0x60000000-0x6fffffff flags 0x2200] or
49                 [mem 0x0000000060000000-0x000000006fffffff flags 0x2200]
50         %pR     [mem 0x60000000-0x6fffffff pref] or
51                 [mem 0x0000000060000000-0x000000006fffffff pref]
53         For printing struct resources. The 'R' and 'r' specifiers result in a
54         printed resource with ('R') or without ('r') a decoded flags member.
56 MAC/FDDI addresses:
58         %pM     00:01:02:03:04:05
59         %pMF    00-01-02-03-04-05
60         %pm     000102030405
62         For printing 6-byte MAC/FDDI addresses in hex notation. The 'M' and 'm'
63         specifiers result in a printed address with ('M') or without ('m') byte
64         separators. The default byte separator is the colon (':').
66         Where FDDI addresses are concerned the 'F' specifier can be used after
67         the 'M' specifier to use dash ('-') separators instead of the default
68         separator.
70 IPv4 addresses:
72         %pI4    1.2.3.4
73         %pi4    001.002.003.004
74         %p[Ii][hnbl]
76         For printing IPv4 dot-separated decimal addresses. The 'I4' and 'i4'
77         specifiers result in a printed address with ('i4') or without ('I4')
78         leading zeros.
80         The additional 'h', 'n', 'b', and 'l' specifiers are used to specify
81         host, network, big or little endian order addresses respectively. Where
82         no specifier is provided the default network/big endian order is used.
84 IPv6 addresses:
86         %pI6    0001:0002:0003:0004:0005:0006:0007:0008
87         %pi6    00010002000300040005000600070008
88         %pI6c   1:2:3:4:5:6:7:8
90         For printing IPv6 network-order 16-bit hex addresses. The 'I6' and 'i6'
91         specifiers result in a printed address with ('I6') or without ('i6')
92         colon-separators. Leading zeros are always used.
94         The additional 'c' specifier can be used with the 'I' specifier to
95         print a compressed IPv6 address as described by
96         http://tools.ietf.org/html/rfc5952
98 UUID/GUID addresses:
100         %pUb    00010203-0405-0607-0809-0a0b0c0d0e0f
101         %pUB    00010203-0405-0607-0809-0A0B0C0D0E0F
102         %pUl    03020100-0504-0706-0809-0a0b0c0e0e0f
103         %pUL    03020100-0504-0706-0809-0A0B0C0E0E0F
105         For printing 16-byte UUID/GUIDs addresses. The additional 'l', 'L',
106         'b' and 'B' specifiers are used to specify a little endian order in
107         lower ('l') or upper case ('L') hex characters - and big endian order
108         in lower ('b') or upper case ('B') hex characters.
110         Where no additional specifiers are used the default little endian
111         order with lower case hex characters will be printed.
113 struct va_format:
115         %pV
117         For printing struct va_format structures. These contain a format string
118         and va_list as follows:
120         struct va_format {
121                 const char *fmt;
122                 va_list *va;
123         };
125         Do not use this feature without some mechanism to verify the
126         correctness of the format string and va_list arguments.
128 u64 SHOULD be printed with %llu/%llx, (unsigned long long):
130         printk("%llu", (unsigned long long)u64_var);
132 s64 SHOULD be printed with %lld/%llx, (long long):
134         printk("%lld", (long long)s64_var);
136 If <type> is dependent on a config option for its size (e.g., sector_t,
137 blkcnt_t, phys_addr_t, resource_size_t) or is architecture-dependent
138 for its size (e.g., tcflag_t), use a format specifier of its largest
139 possible type and explicitly cast to it.  Example:
141         printk("test: sector number/total blocks: %llu/%llu\n",
142                 (unsigned long long)sector, (unsigned long long)blockcount);
144 Reminder: sizeof() result is of type size_t.
146 Thank you for your cooperation and attention.
149 By Randy Dunlap <rdunlap@xenotime.net> and
150 Andrew Murray <amurray@mpc-data.co.uk>