| 1 | /* $Id: VMMCodingGuidelines.cpp 23 2007-01-15 14:08:28Z vboxsync $ */
|
|---|
| 2 | /** @file
|
|---|
| 3 | * VMM - Coding Guidelines.
|
|---|
| 4 | */
|
|---|
| 5 |
|
|---|
| 6 | /*
|
|---|
| 7 | * Copyright (C) 2006 InnoTek Systemberatung GmbH
|
|---|
| 8 | *
|
|---|
| 9 | * This file is part of VirtualBox Open Source Edition (OSE), as
|
|---|
| 10 | * available from http://www.virtualbox.org. This file is free software;
|
|---|
| 11 | * you can redistribute it and/or modify it under the terms of the GNU
|
|---|
| 12 | * General Public License as published by the Free Software Foundation,
|
|---|
| 13 | * in version 2 as it comes in the "COPYING" file of the VirtualBox OSE
|
|---|
| 14 | * distribution. VirtualBox OSE is distributed in the hope that it will
|
|---|
| 15 | * be useful, but WITHOUT ANY WARRANTY of any kind.
|
|---|
| 16 | *
|
|---|
| 17 | * If you received this file as part of a commercial VirtualBox
|
|---|
| 18 | * distribution, then only the terms of your commercial VirtualBox
|
|---|
| 19 | * license agreement apply instead of the previous paragraph.
|
|---|
| 20 | */
|
|---|
| 21 |
|
|---|
| 22 |
|
|---|
| 23 | /** @page pg_vmm_guideline VMM Coding Guidelines
|
|---|
| 24 | *
|
|---|
| 25 | * The guidelines extends the VBox coding guidelines (@ref pg_vbox_guideline)
|
|---|
| 26 | * and consists of a compulsory part and an optional part. It is very important
|
|---|
| 27 | * that the rules of the compusory part is followed. That will prevent obvious
|
|---|
| 28 | * bugs, and it will ease porting the code to 32/64 and 64/32 bits setups.
|
|---|
| 29 | *
|
|---|
| 30 | *
|
|---|
| 31 | *
|
|---|
| 32 | * @section sec_vmm_guideline_compulsory Compulsory
|
|---|
| 33 | *
|
|---|
| 34 | * It is of vital importance is to distiguish between addresses - both virtual
|
|---|
| 35 | * and physical - applying to Guest Context and Host Context. To assist the
|
|---|
| 36 | * coder in this, a set of types and macros have been created. Another vital
|
|---|
| 37 | * thing is that structures shared between the two contexts ends up with the
|
|---|
| 38 | * same size and member offsets in both places. There are types and macros
|
|---|
| 39 | * for that too.
|
|---|
| 40 | *
|
|---|
| 41 | *
|
|---|
| 42 | * The rules:
|
|---|
| 43 | *
|
|---|
| 44 | * - When declaring pointers in shared structures use the GCPTRTYPE() and
|
|---|
| 45 | * HCPTRTYPE() macros.
|
|---|
| 46 | *
|
|---|
| 47 | * - Use RTGCPTR and RTHCPTR when dealing with the other context in
|
|---|
| 48 | * none shared structures, parameter lists, stack variables and such.
|
|---|
| 49 | *
|
|---|
| 50 | * - Following the above rules, pointers will in a context other than the
|
|---|
| 51 | * one a pointer was defined for, appear as unsigned integers.
|
|---|
| 52 | *
|
|---|
| 53 | * - It is NOT permitted to subject a pointer from the other context to pointer
|
|---|
| 54 | * types of the current context by direct cast or by definition.
|
|---|
| 55 | *
|
|---|
| 56 | * - When doing pointer arithmetic cast using uintptr_t, intptr_t or char *.
|
|---|
| 57 | * Never cast a pointer to anything else for this purpose, that will not
|
|---|
| 58 | * work everywhere! (1)
|
|---|
| 59 | *
|
|---|
| 60 | * - Physical addresses are also specific to their context. Use RTGCPHYS
|
|---|
| 61 | * and RTHCPHYS when dealing when them. Both types are unsigned integers.
|
|---|
| 62 | *
|
|---|
| 63 | * - Integers in shared structures should be using a RT integer type or
|
|---|
| 64 | * any of the [u]int[0-9]+_t types. (2)
|
|---|
| 65 | *
|
|---|
| 66 | * - If code is shared between the contexts, GCTYPE() can be used to declare
|
|---|
| 67 | * things differently. If GCTYPE() usage is extensive, don't share the code.
|
|---|
| 68 | *
|
|---|
| 69 | * - The context is part of all public symbols which are specific to a single
|
|---|
| 70 | * context.
|
|---|
| 71 | *
|
|---|
| 72 | *
|
|---|
| 73 | * (1) Talking about porting between 32-bit and 64-bit architectures and even
|
|---|
| 74 | * between 64-bit platforms. On 64-bit linux int is 32-bit, long is 64-bit.
|
|---|
| 75 | * However on 64-bit windows both int and long are 32-bit - there is no
|
|---|
| 76 | * standard 64 bit type (_int64 is not a standard type, it's an stupid
|
|---|
| 77 | * extension).
|
|---|
| 78 | *
|
|---|
| 79 | * (2) The VBox integer types are RTINT, RTUINT, RTGCINT, RTGCUINT,
|
|---|
| 80 | * RTGCINTPTR, RTGCUINTPTR, RTHCINT, RTHCUINT, RTHCINTPTR and
|
|---|
| 81 | * RTHCUINTPTR.
|
|---|
| 82 | *
|
|---|
| 83 | *
|
|---|
| 84 | *
|
|---|
| 85 | * @section sec_vmm_guideline_optional Optional
|
|---|
| 86 | *
|
|---|
| 87 | * There are the general VBox guidelines, see @ref sec_vbox_guideline_optional.
|
|---|
| 88 | * In addition to these for the following rules applies to the VMM:
|
|---|
| 89 | *
|
|---|
| 90 | * - Prefixes GCPtr and HCPtr are prefered over suffixes HC and GC of
|
|---|
| 91 | * pointers.
|
|---|
| 92 | *
|
|---|
| 93 | * - Prefixes GCPhys and HCPhys are generally used for physical addresses,
|
|---|
| 94 | * types RTGCPHYS and RTHCPHYS respectively.
|
|---|
| 95 | *
|
|---|
| 96 | */
|
|---|
| 97 |
|
|---|
