]> git.proxmox.com Git - mirror_qemu.git/blame - HACKING
nbd: BLOCK_STATUS constants
[mirror_qemu.git] / HACKING
CommitLineData
45fad878
BS
11. Preprocessor
2
0891ee11
SH
31.1. Variadic macros
4
45fad878
BS
5For variadic macros, stick with this C99-like syntax:
6
7#define DPRINTF(fmt, ...) \
8 do { printf("IRQ: " fmt, ## __VA_ARGS__); } while (0)
84174436 9
0891ee11
SH
101.2. Include directives
11
12Order include directives as follows:
13
14#include "qemu/osdep.h" /* Always first... */
15#include <...> /* then system headers... */
16#include "..." /* and finally QEMU headers. */
17
18The "qemu/osdep.h" header contains preprocessor macros that affect the behavior
19of core system headers like <stdint.h>. It must be the first include so that
20core system headers included by external libraries get the preprocessor macros
21that QEMU depends on.
22
23Do not include "qemu/osdep.h" from header files since the .c file will have
24already included it.
25
84174436
BS
262. C types
27
28It should be common sense to use the right type, but we have collected
29a few useful guidelines here.
30
312.1. Scalars
32
33If you're using "int" or "long", odds are good that there's a better type.
34If a variable is counting something, it should be declared with an
35unsigned type.
36
37If it's host memory-size related, size_t should be a good choice (use
38ssize_t only if required). Guest RAM memory offsets must use ram_addr_t,
39but only for RAM, it may not cover whole guest address space.
40
41If it's file-size related, use off_t.
42If it's file-offset related (i.e., signed), use off_t.
43If it's just counting small numbers use "unsigned int";
44(on all but oddball embedded systems, you can assume that that
45type is at least four bytes wide).
46
47In the event that you require a specific width, use a standard type
48like int32_t, uint32_t, uint64_t, etc. The specific types are
49mandatory for VMState fields.
50
51Don't use Linux kernel internal types like u32, __u32 or __le32.
52
a8170e5e 53Use hwaddr for guest physical addresses except pcibus_t
84174436
BS
54for PCI addresses. In addition, ram_addr_t is a QEMU internal address
55space that maps guest RAM physical addresses into an intermediate
56address space that can map to host virtual address spaces. Generally
57speaking, the size of guest memory can always fit into ram_addr_t but
58it would not be correct to store an actual guest physical address in a
59ram_addr_t.
60
2be8d450
PM
61For CPU virtual addresses there are several possible types.
62vaddr is the best type to use to hold a CPU virtual address in
63target-independent code. It is guaranteed to be large enough to hold a
64virtual address for any target, and it does not change size from target
65to target. It is always unsigned.
66target_ulong is a type the size of a virtual address on the CPU; this means
67it may be 32 or 64 bits depending on which target is being built. It should
68therefore be used only in target-specific code, and in some
69performance-critical built-per-target core code such as the TLB code.
70There is also a signed version, target_long.
71abi_ulong is for the *-user targets, and represents a type the size of
72'void *' in that target's ABI. (This may not be the same as the size of a
73full CPU virtual address in the case of target ABIs which use 32 bit pointers
74on 64 bit CPUs, like sparc32plus.) Definitions of structures that must match
75the target's ABI must use this type for anything that on the target is defined
76to be an 'unsigned long' or a pointer type.
77There is also a signed version, abi_long.
84174436
BS
78
79Of course, take all of the above with a grain of salt. If you're about
80to use some system interface that requires a type like size_t, pid_t or
81off_t, use matching types for any corresponding variables.
82
83Also, if you try to use e.g., "unsigned int" as a type, and that
84conflicts with the signedness of a related variable, sometimes
85it's best just to use the *wrong* type, if "pulling the thread"
86and fixing all related variables would be too invasive.
87
88Finally, while using descriptive types is important, be careful not to
89go overboard. If whatever you're doing causes warnings, or requires
90casts, then reconsider or ask for help.
91
922.2. Pointers
93
94Ensure that all of your pointers are "const-correct".
95Unless a pointer is used to modify the pointed-to storage,
96give it the "const" attribute. That way, the reader knows
97up-front that this is a read-only pointer. Perhaps more
98importantly, if we're diligent about this, when you see a non-const
99pointer, you're guaranteed that it is used to modify the storage
100it points to, or it is aliased to another pointer that is.
101
1022.3. Typedefs
103Typedefs are used to eliminate the redundant 'struct' keyword.
104
1052.4. Reserved namespaces in C and POSIX
106Underscore capital, double underscore, and underscore 't' suffixes should be
107avoided.
54b2cc50
BS
108
1093. Low level memory management
110
111Use of the malloc/free/realloc/calloc/valloc/memalign/posix_memalign
112APIs is not allowed in the QEMU codebase. Instead of these routines,
f603a687 113use the GLib memory allocation routines g_malloc/g_malloc0/g_new/
6eebf958 114g_new0/g_realloc/g_free or QEMU's qemu_memalign/qemu_blockalign/qemu_vfree
f603a687 115APIs.
54b2cc50 116
f603a687
PM
117Please note that g_malloc will exit on allocation failure, so there
118is no need to test for failure (as you would have to with malloc).
119Calling g_malloc with a zero size is valid and will return NULL.
54b2cc50 120
6eebf958
PB
121Memory allocated by qemu_memalign or qemu_blockalign must be freed with
122qemu_vfree, since breaking this will cause problems on Win32.
d241f143
BS
123
1244. String manipulation
125
9b9e3ec1
JM
126Do not use the strncpy function. As mentioned in the man page, it does *not*
127guarantee a NULL-terminated buffer, which makes it extremely dangerous to use.
128It also zeros trailing destination bytes out to the specified length. Instead,
129use this similar function when possible, but note its different signature:
130void pstrcpy(char *dest, int dest_buf_size, const char *src)
d241f143
BS
131
132Don't use strcat because it can't check for buffer overflows, but:
133char *pstrcat(char *buf, int buf_size, const char *s)
134
135The same limitation exists with sprintf and vsprintf, so use snprintf and
136vsnprintf.
137
138QEMU provides other useful string functions:
139int strstart(const char *str, const char *val, const char **ptr)
140int stristart(const char *str, const char *val, const char **ptr)
141int qemu_strnlen(const char *s, int max_len)
142
143There are also replacement character processing macros for isxyz and toxyz,
144so instead of e.g. isalnum you should use qemu_isalnum.
145
145e21db 146Because of the memory management rules, you must use g_strdup/g_strndup
d241f143 147instead of plain strdup/strndup.
876f256b
BS
148
1495. Printf-style functions
150
151Whenever you add a new printf-style function, i.e., one with a format
152string argument and following "..." in its prototype, be sure to use
153gcc's printf attribute directive in the prototype.
154
155This makes it so gcc's -Wformat and -Wformat-security options can do
156their jobs and cross-check format strings with the number and types
157of arguments.
47536317
PM
158
1596. C standard, implementation defined and undefined behaviors
160
161C code in QEMU should be written to the C99 language specification. A copy
162of the final version of the C99 standard with corrigenda TC1, TC2, and TC3
163included, formatted as a draft, can be downloaded from:
164 http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
165
166The C language specification defines regions of undefined behavior and
167implementation defined behavior (to give compiler authors enough leeway to
168produce better code). In general, code in QEMU should follow the language
169specification and avoid both undefined and implementation defined
170constructs. ("It works fine on the gcc I tested it with" is not a valid
171argument...) However there are a few areas where we allow ourselves to
172assume certain behaviors because in practice all the platforms we care about
173behave in the same way and writing strictly conformant code would be
174painful. These are:
175 * you may assume that integers are 2s complement representation
176 * you may assume that right shift of a signed integer duplicates
177 the sign bit (ie it is an arithmetic shift, not a logical shift)
d76a3bf5 178
435405ac
PK
179In addition, QEMU assumes that the compiler does not use the latitude
180given in C99 and C11 to treat aspects of signed '<<' as undefined, as
181documented in the GNU Compiler Collection manual starting at version 4.0.
182
d76a3bf5
MA
1837. Error handling and reporting
184
1857.1 Reporting errors to the human user
186
187Do not use printf(), fprintf() or monitor_printf(). Instead, use
188error_report() or error_vreport() from error-report.h. This ensures the
189error is reported in the right place (current monitor or stderr), and in
190a uniform format.
191
192Use error_printf() & friends to print additional information.
193
194error_report() prints the current location. In certain common cases
195like command line parsing, the current location is tracked
196automatically. To manipulate it manually, use the loc_*() from
197error-report.h.
198
1997.2 Propagating errors
200
201An error can't always be reported to the user right where it's detected,
202but often needs to be propagated up the call chain to a place that can
203handle it. This can be done in various ways.
204
205The most flexible one is Error objects. See error.h for usage
206information.
207
208Use the simplest suitable method to communicate success / failure to
209callers. Stick to common methods: non-negative on success / -1 on
210error, non-negative / -errno, non-null / null, or Error objects.
211
212Example: when a function returns a non-null pointer on success, and it
213can fail only in one way (as far as the caller is concerned), returning
214null on failure is just fine, and certainly simpler and a lot easier on
215the eyes than propagating an Error object through an Error ** parameter.
216
217Example: when a function's callers need to report details on failure
218only the function really knows, use Error **, and set suitable errors.
219
220Do not report an error to the user when you're also returning an error
221for somebody else to handle. Leave the reporting to the place that
222consumes the error returned.
223
2247.3 Handling errors
225
226Calling exit() is fine when handling configuration errors during
227startup. It's problematic during normal operation. In particular,
228monitor commands should never exit().
229
230Do not call exit() or abort() to handle an error that can be triggered
231by the guest (e.g., some unimplemented corner case in guest code
232translation or device emulation). Guests should not be able to
233terminate QEMU.
234
235Note that &error_fatal is just another way to exit(1), and &error_abort
236is just another way to abort().