Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
[surf] Don't define variable "platform_filename" twice.
[simgrid.git] / README.coding
index 1f31d9c..2a8302a 100644 (file)
@@ -3,26 +3,29 @@
 **
 ******************************************************
 
-There is projects in the tree:
+There is at least 5 sub-projects in the tree:
 
- - GROS: no fancy name yet (low-level toolbox: logging, datatypes).
+ - XBT: eXtended Bundle of Tools (low-level toolbox: logging, datatypes).
+ - SURF: a SimUlation aRtiFact. This is the simulation kernel.
+ - MSG:  originally MetaSimGrid, MSG is a simple distributed application
+         simulator.
  - GRAS: Grid Reality And Simulation (message passing API with two
          implementations allowing to compile programs on top of the
          simulator or for the real life without code modification)
- - SURF: Server for the Use of Resource Fictions (the simulator used 
-         in GRAS and more)
  - AMOK: Advanced Metacomputing Overlay Kit (high level toolbox; Grid
          application elements such as distributed database, topology
          discovery service, and so on)
 
-They are all in the same tree because GRAS depends on SURF which depends on
-GRAS (that's the only cycle here, we're not *that* vicious).
+They are all in the same tree because they are complementary tools and
+having all of them in the same package makes the installation easier
+for end-users. Moreover, it enables to share the compilation chain and
+eases the development.
 
 The tree is not splited on projects, but on file finality:
  include/            -> all *public* headers
- include/gros/*.h    -> one file per module
- include/gros.h      -> file including all modules headers
-  (same for gras, surf and amok instead of gros)
+ include/xbt/*.h     -> one file per module
+ include/gras.h      -> file including all modules headers
+  (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.
@@ -39,7 +42,10 @@ The tree is not splited on projects, but on file finality:
    So, the modules have 3 levels of publicity for their interface. 
    Private, internal to GRAS, public. Of course, I try to keep as much stuff
    private as possible.
-  
+
+ src/include -> another location for protected headers. Used by SURF, and
+                other should be converted, since this is the Right Thing.
+
  testsuite/ -> The more test the better. 
                Same organization than src/ and include/
                Tests are allowed to load some headers of the module they test.
@@ -52,6 +58,19 @@ The tree is not splited on projects, but on file finality:
  examples/ -> Supposed to be copy/pastable by the user, so keep it clear and
                 avoid any kind of trick. In particular, do only include the
                 public headers here.
+**
+** Indentation standard
+**
+*****************************************************
+
+Most files use the Kernighan & Ritchie coding style with 2 spaces of
+indentation. The indent program can help you to stick to it:
+
+indent -kr -br -brs -ce -bbo --dont-break-procedure-type --no-tabs
+--cuddle-do-while --cuddle-else --indent-level2 --leave-preprocessor-space
+--no-space-after-function-call-names <myfile>
+
+FIXME: this list of arguments is still to be discussed, maybe
 
 **
 ** Type naming standard
@@ -90,12 +109,11 @@ bug. Please report it (or fix it yourself if you can).
 *****************************************************
 
 MALLOC:
- You must cast the result of malloc on AIX. 
It's even better to use gras_new when possible.
+ Don't use it, or you'll have to check the result (and do some dirty stuff
on AIX). Use xbt_malloc (or even better, xbt_new) instead.
 
 SIZE_T
  If possible, avoid size_t and use unsigned long instead. If not,
-
  #include <sys/types.h> in all files manipulating size_t
  do cast it to unsigned long before printing (and use %lu)
  
@@ -104,162 +122,75 @@ PRINTF pointer difference
   
 
 **             
-** Commenting the source
+** Commenting the source: doxygen
 **
 ****************************************************
 
-Le format pour cela est :
-
-/**                              (très important, la deuxieme étoile)
- * nomDeFonction:                (faut les deux points)
- * @param1: blabla               (faut le @ et les deux points, et ca peut
- *                                courir sur plusieurs lignes)
- * @param2: blabla
- *                               (fin des paramètres: ligne vide)
- * blabla sur la fonction        (autant de lignes que tu veux)
- */
-
-Si tu met () apres un nom de fonction, il essaye d'ajouter un lien
-automatiquement, il me semble.
-
-
-Ensuite, quand tu fais "make -C doc", il ne se passe rien de particulier ;)
-Avant que ca marche, il faut créer une nouvelle section dans
-doc/gras-sections.txt Attention, on dirait du xml, mais le parseur est
-stupide. Je me suis arraché les cheveux plusieurs heures pour un "<SECTION<"
-
-Tout ce qui n'est pas dans une section se trouve listé dans gras-unused.txt
-Pour éviter que ca ne soit le cas sans pour autant les documenter, place les
-symboles après <SUBSECTION Standard> (regarde tbx_log dans le fichier pour
-un exemple).
-
-Une fois la section crée, un "make -C doc" crée un bout de doc, mais ne
-l'inclue pas dans la documentation finale. Pour cela, il faut éditer le
-fichier gras-docs.sgml (qui est un fichier xml de bon aloi, malgré son
-nom). Il te faut ajouter une entité système dans le prologue (avant "]>")
-style: <!ENTITY tbx-cfg SYSTEM "xml/tbx_cfg.xml">
-Ensuite dans le corps du document, tu colles: &tbx-cfg; et t'es arrivé. Au
-milleu du gras-docs.sgml, y'a un bout de code mort en commentaire. Autant le
-laisser, je nettoyerais un jour, peut etre.
-
-
-Il te faut maintenant mettre un titre long et une description de module.
-Pour cela, édite le fichier "tmpl/<nom_de_section>.sgml". Juste en haut, les
-parties "SECTION Title", "SECTION Short_Description", "SECTION
-Long_Description" et "SECTION See_Also". Pr les deux premiers, faut mettre
-une seule ligne et pas de tags. Pour les autres, il faut faire des
-paragraphes. Donc, tout ce que t'as le droit de mettre dans un <para> passe.
-
-Attention, les fichiers dans doc/xml sont les morceaux prêts à être intégrés
-par gras-doc.sgml. Ils sont donc générés et écrasés à tout bout de champ.
-Mais les fichiers de doc/tmpl (templates) sont aussi partiellement générés.
-Les doc de fonction extraites du code y sont placées, et les modification
-que t'y a fait (titre, desc_courte/longue, voir_aussi) sont préservées,
-normalement.
-
-
-Voila, une fois ceci fait, la doc devrait être bonne. Comme tu peux le voir,
-gtk-doc est bien plus bordelique à utiliser que doxygen (j'utilise souvent
-"make clean all" car il semble manquer des dépendances). Mais je préfere car
-on peut faire exactement ce qu'on veut. Et pis rose bonbon, c'est plus joli
-que bleu triste.
+The global structure of the documentation is in doc/modules.doc 
+
+The structure of each module (xbt, gras, etc) is in doc/module-<module>.doc
+
+The structure of a module is in its public header. This way, you're sure to
+see all the public interface (and only it). The different parts of the
+interface are grouped using the @name construct, even if it's buggy. Since
+parts often get reordered, it's better to add numbers to the parts (so that
+users can see the intended order).
+
+The documentation of each type and macro are also in the public header since
+this is were they live.
+
+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="<réglage> [<reglage>+]" (ou sans " si t'as pas d'espace)
-chaque réglage étant de la forme:
-  <canal>.thres=<priorité>
-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_<module>_<func>(): functions working both in SG and RL  
+  - xbt_os_<module>_<func>(): 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_<module>.c: native implementation (xbt_<module>_<func>()).
+    Simply call the corresponding xbt_os_<module>_<func>.     
+    Part only of libgras.so
+    
+  - xbt_sg_<module>.c: SIMIX implementation xbt_<module>_<func>()).
+    Simply call the corresponding SIMIX implementation. 
+    Part only of libsimgrid.so
+    
+  - xbt_os_<module>.c: body of the functions implementing natively the
+    stuff (xbt_os_<module>_<func>()).
+    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