X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/8bdb339e3cb7e979b364c44e653752d8edfd0392..4b3728c65b4c8fbd3eb81eb273f5a40d83117d33:/README.coding diff --git a/README.coding b/README.coding index 7ff0e4ab46..791d365839 100644 --- a/README.coding +++ b/README.coding @@ -25,7 +25,7 @@ The tree is not splited on projects, but on file finality: include/ -> all *public* headers include/xbt/*.h -> one file per module include/gras.h -> file including all modules headers - (same for xbt instead of gros) + (same for xbt instead of gras) src/Makefile.am -> main makefile. All projects should fit in only one library (I mean 2, RL+SG), which is compiled here. @@ -64,7 +64,13 @@ The tree is not splited on projects, but on file finality: ***************************************************** Most files use the Kernighan & Ritchie coding style with 2 spaces of -indentation. The indent program can help you to stick to it. :) +indentation. The indent program can help you to stick to it: + +indent -kr -l80 -nut -i2 -lps -npcs -br -brs -ce -cdw -bbo -npsl + +The script ./tools/indent runs indent with the appropriate options. + +FIXME: this list of arguments is still to be discussed, maybe ** ** Type naming standard @@ -137,103 +143,54 @@ The documentation of each function must be in the C file were it lives. Any public element (function, type and macro) must have a @brief part. - -** -** Using the logs +** +** XBT virtualization mecanism ** **************************************************** -Dans gras, tu ne te contente pas d'écrire des choses à l'écran, mais tu -écris sur un sujet particulier (notion de canal) des choses d'une gravité -particulière. Il y a 7 niveaux de gravité. - trace: tracer les entrées dans une fonction, retour de fonction - (famille de macros XBT_IN/XBT_OUT) - debug: pour t'aider à mettre au point le module, potentiellement tres bavard - verbose: quelques infos succintes sur les internals du module - info: niveau normal, ton de la conversation - warning: problème potentiel, mais auquel on a su faire face - error: problème qui t'as empêché de faire ton job - critical: juste avant de mourir - -Quand on compile avec -DNDEBUG (par défaut dans le paquet Debian), tout ce -qui est '>= verbose' est supprimé au moment de la compilation. Retiré du -binaire, killé. - -Ensuite, tu écris dans un canal particulier. Tous les canaux sont rangés en -arbre. Il faudrait faire un ptit script qui fouille les sources à la -recherche des macros XBT_LOG_NEW_* utilisées pour créer des canaux. Le -dernier argument de ces macros est ignoré dans le source. Il est destiné à -être la documentation de la chose en une ligne. En gros, ca fait: -root - +--xbt - | +--config - | +--dict - | | +--dict_cursor - | | +--dict_elm - | | ... - | +--dynar - | +--set - | +--log - | +--module - +--gras - +--datadesc - | +--ddt_cbps - | +--ddt_convert - | +--ddt_exchange - | +--ddt_parse - | +--lexer - +--msg - +--transport - +--raw_trp (Je devrais tuer ce module, un jour) - +--trp_buf - +--trp_sg - +--trp_file - +--trp_tcp - -Et ensuite les utilisateurs peuvent choisir le niveau de gravité qui les -interresse sur tel ou tel sujet. - -Toute la mécanique de logging repose sur des variables statiques dont le nom -dépend du nom du canal. - => attention aux conflits de nom de canal - => il faut une macro XBT_LOG dans chaque fichier où tu fais des logs. - -XBT_LOG_NEW_CATEGORY: nouveau canal sous "root". Rare, donc. -XBT_LOG_NEW_SUBCATEGORY: nouveau canal dont on précise le père. -XBT_LOG_DEFAULT_CATEGORY: indique quel est le canal par défaut dans ce fichier -XBT_LOG_NEW_DEFAULT_CATEGORY: Crèe un canal et l'utilise par défaut -XBT_LOG_NEW_DEFAULT_SUBCATEGORY: devine -XBT_LOG_EXTERNAL_CATEGORY: quand tu veux utiliser par défaut un canal créé - dans un autre fichier. - -Une fois que ton canal est créé, tu l'utilise avec les macros LOG, DEBUG, -VERB, WARN, ERROR et CRITICAL. Il faut que tu donne le nombre d'arguments -après le nom de macro. Exemple: LOG2("My name is %s %s","Martin","Quinson") -Si tu veux préciser explicitement le canal où écrire, ajoute un C devant le -nom de la macro. Exemple: CCRITICAL0(module, "Cannot initialize GRAS") - -Toutes ces macros (enfin, ce en quoi elles se réécrivent) vérifient leurs -arguments comme printf le fait lorsqu'on compile avec gcc. -LOG1("name: %d","toto"); donne un warning, et donc une erreur en mode -mainteneur. - -Enfin, tu peux tester si un canal est ouvert à une priorité donnée (pour -préparer plus de débug, par exemple. Dans le parseur, je fais du pretty -printing sur ce qu'il faut parser dans ce cas). -XBT_LOG_ISENABLED(catName, priority) Le second argument doit être une valeur -de e_xbt_log_priority_t (log.h). Par exemple: xbt_log_priority_verbose - -Voila sur comment mettre des logs dans ton code. N'hesite pas à faire pleins -de canaux différents pour des aspects différents de ton code. En -particulier, dans les dict, j'ai un canal pour l'ajout, le retrait, le -netoyage du code après suppression et ainsi de suite. De cette façon, je -peux choisir qui m'interresse. - - -Pour utiliser les logs, tu déjà faire, non ? Tu colle sur la ligne de -commande un ou plusieurs arguments de la forme - --gras-log=" [+]" (ou sans " si t'as pas d'espace) -chaque réglage étant de la forme: - .thres= -Les différents réglages sont lus de gauche à droite. -"root.thres=debug root.thres=critical" ferme tout, normalement. +There is some functionnalities that we want to virtualize in XBT. We +want xbt_time to give the simulated clock when running on top of the +simulator, and the host clock when running on a real system. This +could be placed in GRAS (and was, historically), but there is some +reason to lower it down to XBT. + +Here is the used naming scheme: + + - xbt__(): functions working both in SG and RL + - xbt_os__(): RL functions usable even in simulator + + That way, in libsimgrid, we still can use native functions if we + want to. It may for example be useful to get the real time when + implementing the simulator. Think of the SIGINT handler, which + wants to see if the user pressed the key twice in a 5 seconds + interval. This is of little use to check the simulated time here. + +Here is the file layout: + + - xbt_rl_.c: native implementation (xbt__()). + Simply call the corresponding xbt_os__. + Part only of libgras.so + + - xbt_sg_.c: SIMIX implementation xbt__()). + Simply call the corresponding SIMIX implementation. + Part only of libsimgrid.so + + - xbt_os_.c: body of the functions implementing natively the + stuff (xbt_os__()). + Part of both libgras.so and libsimgrid.so + +Since there is almost nothing in xbt_rl_module.c and xbt_sg_module.c, +it'd be better to use symbol aliasing here (to declare in the object +code that the same function have two names), but I'm still +investigating the portability of the thing to windows. + + +* +* SimGrid Hacker Survival Guide (FIXME: should be betterly placed) +******************************** + +* If you break the logs (for example while hacking in the dynars), you + want to define XBT_LOG_MAYDAY at the beginning of log.h. It will + desactivate the whole logging mecanism, switching to printfs + instead. SimGrid becomes incredibly verbose when doing so, but it + you let you fixing the dynars. \ No newline at end of file