2 ** Source tree organization
4 ******************************************************
6 There is at least 4 projects in the tree:
8 - XBT: eXtended Bundle of Tools (low-level toolbox: logging, datatypes).
9 - GRAS: Grid Reality And Simulation (message passing API with two
10 implementations allowing to compile programs on top of the
11 simulator or for the real life without code modification)
12 - SURF: Server for the Use of Resource Fictions (the simulator used
14 - AMOK: Advanced Metacomputing Overlay Kit (high level toolbox; Grid
15 application elements such as distributed database, topology
16 discovery service, and so on)
18 They are all in the same tree because GRAS depends on SURF which depends on
19 GRAS (that's the only cycle here, we're not *that* vicious).
21 The tree is not splited on projects, but on file finality:
22 include/ -> all *public* headers
23 include/xbt/*.h -> one file per module
24 include/gros.h -> file including all modules headers
25 (same for gras, surf and amok instead of gros)
27 src/Makefile.am -> main makefile. All projects should fit in only one
28 library (I mean 2, RL+SG), which is compiled here.
30 Since all object.o files are placed here, you should
31 choose the name of c files carfully to avoid
34 src/gras/DataDesc -> typical project module
35 src/gras/DataDesc/datadesc_interface.h -> visible to any GRAS modules;
36 masked to the user and GROS/AMOK/SURF
37 src/gras/DataDesc/datadesc_private.h -> visible only from this module
39 So, the modules have 3 levels of publicity for their interface.
40 Private, internal to GRAS, public. Of course, I try to keep as much stuff
43 src/include -> another location for protected headers. Used by SURF, and
44 other should be converted, since this is the Right Thing.
46 testsuite/ -> The more test the better.
47 Same organization than src/ and include/
48 Tests are allowed to load some headers of the module they test.
49 All tests should be listed in run_test.in so that they get
51 They are not listed directly in the check_PROGRAMS part of
52 the makefile because run_test knows about the gras logging
53 features and relaunch with full details the failed tests.
55 examples/ -> Supposed to be copy/pastable by the user, so keep it clear and
56 avoid any kind of trick. In particular, do only include the
60 ** Type naming standard
62 *****************************************************
64 It may sound strange, but the type naming convention was source of intense
65 discution between da GRAS posse members. The convention we came to may not
66 be the best solution, but it has the merit to exist and leave everyone work.
67 So please stick to it.
69 - ???_t is a valid type (builded with typedef)
70 - s_toto_t is a structure (access to fields with .)
71 - s_toto is a structure needing 'struct' keyword to be used
73 - u_toto_t is an union
74 - u_toto is an union needing 'union' keyword to be used
75 - toto_t is an 'object' (struct*)
77 Please to not call toto_t something else than an 'object' (ie, something you
78 have to call _new and _free on it).
81 typedef struct s_toto {} s_toto_t, *toto_t;
82 typedef enum {} e_toto_t;
84 Moreover, only toto_t (and e_toto_t) are public. The rest (mainly s_toto_t)
87 If you see any part of the code not following this convention, this is a
88 bug. Please report it (or fix it yourself if you can).
91 ** Random bits about coding standards and portability
93 *****************************************************
96 Don't use it, or you'll have to check the result (and do some dirty stuff
97 on AIX). Use xbt_malloc (or even better, xbt_new) instead.
100 If possible, avoid size_t and use unsigned long instead. If not,
101 #include <sys/types.h> in all files manipulating size_t
102 do cast it to unsigned long before printing (and use %lu)
104 PRINTF pointer difference
105 printf ("diff = %ld\n", (long) (pointer2 - pointer1));
109 ** Commenting the source: doxygen
111 ****************************************************
113 The global structure of the documentation is in doc/modules.doc
115 The structure of each module (xbt, gras, etc) is in doc/module-<module>.doc
117 The structure of a module is in its public header. This way, you're sure to
118 see all the public interface (and only it). The different parts of the
119 interface are grouped using the @name construct, even if it's buggy. Since
120 parts often get reordered, it's better to add numbers to the parts (so that
121 users can see the intended order).
123 The documentation of each type and macro are also in the public header since
124 this is were they live.
126 The documentation of each function must be in the C file were it lives.
128 Any public element (function, type and macro) must have a @brief part.
134 ****************************************************
136 Dans gras, tu ne te contente pas d'écrire des choses à l'écran, mais tu
137 écris sur un sujet particulier (notion de canal) des choses d'une gravité
138 particulière. Il y a 7 niveaux de gravité.
139 trace: tracer les entrées dans une fonction, retour de fonction
140 (famille de macros XBT_IN/XBT_OUT)
141 debug: pour t'aider à mettre au point le module, potentiellement tres bavard
142 verbose: quelques infos succintes sur les internals du module
143 info: niveau normal, ton de la conversation
144 warning: problème potentiel, mais auquel on a su faire face
145 error: problème qui t'as empêché de faire ton job
146 critical: juste avant de mourir
148 Quand on compile avec -DNDEBUG (par défaut dans le paquet Debian), tout ce
149 qui est '>= verbose' est supprimé au moment de la compilation. Retiré du
152 Ensuite, tu écris dans un canal particulier. Tous les canaux sont rangés en
153 arbre. Il faudrait faire un ptit script qui fouille les sources à la
154 recherche des macros XBT_LOG_NEW_* utilisées pour créer des canaux. Le
155 dernier argument de ces macros est ignoré dans le source. Il est destiné à
156 être la documentation de la chose en une ligne. En gros, ca fait:
177 +--raw_trp (Je devrais tuer ce module, un jour)
183 Et ensuite les utilisateurs peuvent choisir le niveau de gravité qui les
184 interresse sur tel ou tel sujet.
186 Toute la mécanique de logging repose sur des variables statiques dont le nom
187 dépend du nom du canal.
188 => attention aux conflits de nom de canal
189 => il faut une macro XBT_LOG dans chaque fichier où tu fais des logs.
191 XBT_LOG_NEW_CATEGORY: nouveau canal sous "root". Rare, donc.
192 XBT_LOG_NEW_SUBCATEGORY: nouveau canal dont on précise le père.
193 XBT_LOG_DEFAULT_CATEGORY: indique quel est le canal par défaut dans ce fichier
194 XBT_LOG_NEW_DEFAULT_CATEGORY: Crèe un canal et l'utilise par défaut
195 XBT_LOG_NEW_DEFAULT_SUBCATEGORY: devine
196 XBT_LOG_EXTERNAL_CATEGORY: quand tu veux utiliser par défaut un canal créé
197 dans un autre fichier.
199 Une fois que ton canal est créé, tu l'utilise avec les macros LOG, DEBUG,
200 VERB, WARN, ERROR et CRITICAL. Il faut que tu donne le nombre d'arguments
201 après le nom de macro. Exemple: LOG2("My name is %s %s","Martin","Quinson")
202 Si tu veux préciser explicitement le canal où écrire, ajoute un C devant le
203 nom de la macro. Exemple: CCRITICAL0(module, "Cannot initialize GRAS")
205 Toutes ces macros (enfin, ce en quoi elles se réécrivent) vérifient leurs
206 arguments comme printf le fait lorsqu'on compile avec gcc.
207 LOG1("name: %d","toto"); donne un warning, et donc une erreur en mode
210 Enfin, tu peux tester si un canal est ouvert à une priorité donnée (pour
211 préparer plus de débug, par exemple. Dans le parseur, je fais du pretty
212 printing sur ce qu'il faut parser dans ce cas).
213 XBT_LOG_ISENABLED(catName, priority) Le second argument doit être une valeur
214 de e_xbt_log_priority_t (log.h). Par exemple: xbt_log_priority_verbose
216 Voila sur comment mettre des logs dans ton code. N'hesite pas à faire pleins
217 de canaux différents pour des aspects différents de ton code. En
218 particulier, dans les dict, j'ai un canal pour l'ajout, le retrait, le
219 netoyage du code après suppression et ainsi de suite. De cette façon, je
220 peux choisir qui m'interresse.
223 Pour utiliser les logs, tu déjà faire, non ? Tu colle sur la ligne de
224 commande un ou plusieurs arguments de la forme
225 --gras-log="<réglage> [<reglage>+]" (ou sans " si t'as pas d'espace)
226 chaque réglage étant de la forme:
227 <canal>.thres=<priorité>
228 Les différents réglages sont lus de gauche à droite.
229 "root.thres=debug root.thres=critical" ferme tout, normalement.