From: mquinson Date: Thu, 23 Jun 2005 20:26:03 +0000 (+0000) Subject: cleanups X-Git-Tag: v3.3~3949 X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/commitdiff_plain/ac90ceb451c8d228a7de1a9a9cc3821b2cc8b09a cleanups git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/simgrid/simgrid/trunk@1406 48e7efb5-ca39-0410-a469-dd3cf9ba447f --- diff --git a/cruft/doc/Makefile.am b/cruft/doc/Makefile.am deleted file mode 100644 index 4ba6ae7987..0000000000 --- a/cruft/doc/Makefile.am +++ /dev/null @@ -1,65 +0,0 @@ -## Process this file with automake to produce Makefile.in - -# This is a blank Makefile.am for using gtk-doc. -# Copy this to your project's API docs directory and modify the variables to -# suit your project. See the GTK+ Makefiles in gtk+/docs/reference for examples -# of using the various options. - -# The name of the module, e.g. 'glib'. -DOC_MODULE=gras -TARGET_DIR = @htmldir@ - -# The top-level SGML file. Change it if you want. -DOC_MAIN_SGML_FILE=$(DOC_MODULE)-docs.sgml - -# The directory containing the source code. Relative to $(srcdir). -# gtk-doc will search all .c & .h files beneath here for inline comments -# documenting functions and macros. -DOC_SOURCE_DIR=.. -#/src - -# Extra options to pass to gtkdoc-scanobj or gtkdoc-scangobj. -SCANOBJ_OPTIONS= - -# Extra options to supply to gtkdoc-scan. -SCAN_OPTIONS= - -# Extra options to supply to gtkdoc-mkdb. -MKDB_OPTIONS=--sgml-mode --output-format=xml --ignore-files="ddt_parse.yy.c" - -# Extra options to supply to gtkdoc-fixref. -FIXXREF_OPTIONS= - -# Used for dependencies. -HFILE_GLOB=$(shell find $(top_srcdir)/src -name "*.h") \ - $(shell find $(top_srcdir)/include -name "*.h") -CFILE_GLOB=$(shell find $(top_srcdir)/src -name "*.c"|grep -v ddt_parse.yy.c) -#CFILE_GLOB=$(top_srcdir)/src/core/*.c - -# Header files to ignore when scanning. -IGNORE_HFILES=ddt_parse.yy.h - -# Images to copy into HTML directory. -HTML_IMAGES = - -# Extra SGML files that are included by $(DOC_MAIN_SGML_FILE). -content_files = overview.xml faq.xml - -# Other files to distribute. -extra_files = - -# CFLAGS and LDFLAGS for compiling scan program. Only needed if your app/lib -# contains GtkObjects/GObjects and you want to document signals and properties. -GTKDOC_CFLAGS = -GTKDOC_LIBS = - -#GTKDOC_CC=$(LIBTOOL) --mode=compile $(CC) -#GTKDOC_LD=$(LIBTOOL) --mode=link $(CC) - -# If you need to override some of the declarations, place them in the -# $(DOC_MODULE)-overrides.txt file and uncomment the second line here. -DOC_OVERRIDES = -#DOC_OVERRIDES = $(DOC_MODULE)-overrides.txt - - -include gtk-doc.make diff --git a/cruft/doc/README b/cruft/doc/README deleted file mode 100644 index e82cb1c8a0..0000000000 --- a/cruft/doc/README +++ /dev/null @@ -1,29 +0,0 @@ -This directory contains the reference documentation -for GRAS. For more information about it see: - - http://www.ens-lyon.fr/~mquinson/hacking.html - - -REQUIREMENTS -============ - -To build the documentation, you must have the gtk-doc -package installed. To rebuild the template files, -you must have the current version of the GRAS -header files installed. - - -BUILD -===== - -First, run configure to generate the makefiles for this -module. There is one option specific to this package - - --with-html-dir=DIR top of installed HTML documentation tree - -To build and install the documentation, do: - - make - - make install - diff --git a/cruft/doc/Roadmap.gnumeric b/cruft/doc/Roadmap.gnumeric deleted file mode 100644 index 23bcd7129d..0000000000 Binary files a/cruft/doc/Roadmap.gnumeric and /dev/null differ diff --git a/cruft/doc/faq.xml b/cruft/doc/faq.xml deleted file mode 100644 index 2a821d4e8f..0000000000 --- a/cruft/doc/faq.xml +++ /dev/null @@ -1,48 +0,0 @@ - - -GRAS frequently asked questions -3 -GRAS Library - - - -FAQFAQ on the GRAS library - - - -Introduction -This document contains random bits about the most beloved traps of -GRAS users, and (hopefully) a way to escape them.. - - -My code segfault in the communication process - -Remember that GRAS expect the passed variable to match exactly the -passed type description. The most often issue is that you pass a structure -description, and you pass the address of a pointer to such a structure. If -you want to handle pointer to structures (as most of us do), please use -gras_datadesc_declare_ref() to construct the correct type description. - - - - - - - - diff --git a/cruft/doc/gras-docs.sgml b/cruft/doc/gras-docs.sgml deleted file mode 100644 index 6d1c556240..0000000000 --- a/cruft/doc/gras-docs.sgml +++ /dev/null @@ -1,332 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - -]> - - - Grid Reality And Simulation Reference Manual - - - - GRAS overview - &overview; - &faq; - - - - Communication facilities - &comm-datadesc; - &comm-socks; - &comm-messages; - - - - Virtualization - &virtu-globals; - &virtu-syscall; - - - - - - - GRAS toolbox - &xbt-error; - &xbt-log; - &xbt-dynar; - &xbt-dict; - &xbt-set; - &xbt-swag; - &xbt-heap; - &xbt-config; - - - - SURF - &surf-maxmin; - - - - diff --git a/cruft/doc/gras-overrides.txt b/cruft/doc/gras-overrides.txt deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/cruft/doc/gras-overview.fig b/cruft/doc/gras-overview.fig deleted file mode 100644 index 8f3ac8bdee..0000000000 --- a/cruft/doc/gras-overview.fig +++ /dev/null @@ -1,187 +0,0 @@ -#FIG 3.2 -Landscape -Center -Metric -A4 -100.00 -Single --2 -1200 2 -6 8797 2835 9877 3150 -4 1 0 40 -1 2 13 0.0000 6 135 1005 9336 2970 Conditional\001 -4 1 0 40 -1 2 13 0.0000 6 135 810 9336 3150 execution\001 --6 -6 7605 3465 8370 3690 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5 - 7620 3465 8340 3465 8340 3690 7620 3690 7620 3465 -4 1 0 40 -1 0 12 0.0000 6 120 75 7979 3645 ?\001 --6 -6 8640 3330 10035 3555 -6 9360 3330 10035 3555 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 9360 3330 10035 3330 10035 3555 9360 3555 9360 3330 -4 1 0 40 -1 0 12 0.0000 6 120 465 9720 3502 Simul.\001 --6 -6 8640 3330 9315 3555 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 8640 3330 9315 3330 9315 3555 8640 3555 8640 3330 -4 1 0 40 -1 0 12 0.0000 6 165 495 8977 3502 Reality\001 --6 --6 -6 3510 4365 4320 4635 -2 2 0 1 0 7 50 -1 17 0.000 0 0 -1 0 0 5 - 3510 4365 4320 4365 4320 4635 3510 4635 3510 4365 -4 1 0 40 -1 0 12 0.0000 6 165 360 3915 4545 Logs\001 --6 -6 9135 4230 9945 4770 -6 9135 4230 9945 4500 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 9135 4230 9945 4230 9945 4500 9135 4500 9135 4230 -4 1 0 40 -1 0 12 0.0000 6 120 600 9540 4410 Forecast\001 --6 -6 9135 4500 9945 4770 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 9135 4500 9945 4500 9945 4770 9135 4770 9135 4500 -4 1 0 40 -1 0 12 0.0000 6 120 495 9540 4680 RRDB\001 --6 --6 -6 4455 4365 5265 4635 -2 2 0 1 0 7 50 -1 17 0.000 0 0 -1 0 0 5 - 4455 4365 5265 4365 5265 4635 4455 4635 4455 4365 -4 1 0 40 -1 0 12 0.0000 6 120 450 4860 4545 Errors\001 --6 -6 5400 4365 6210 4635 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 5400 4365 6210 4365 6210 4635 5400 4635 5400 4365 -4 1 0 40 -1 0 12 0.0000 6 165 540 5805 4545 Config.\001 --6 -6 6345 4365 7155 4635 -2 2 0 1 0 7 50 -1 17 0.000 0 0 -1 0 0 5 - 6345 4365 7155 4365 7155 4635 6345 4635 6345 4365 -4 1 0 40 -1 0 12 0.0000 6 120 420 6750 4545 Dicos\001 --6 -6 7290 4365 8100 4635 -2 2 0 1 0 7 50 -1 17 0.000 0 0 -1 0 0 5 - 7290 4365 8100 4365 8100 4635 7290 4635 7290 4365 -4 1 0 40 -1 0 12 0.0000 6 165 495 7695 4545 Arrays\001 --6 -6 8235 4365 9045 4635 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 8235 4365 9045 4365 9045 4635 8235 4635 8235 4365 -4 1 0 40 -1 0 12 0.0000 6 120 480 8640 4545 Hooks\001 --6 -6 6240 3465 6390 3497 -1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 6315 3481 9 9 6315 3481 6324 3481 -1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 6256 3481 9 9 6256 3481 6265 3481 -1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 6374 3481 9 9 6374 3481 6383 3481 --6 -6 5400 3330 6030 3600 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 5418 3330 6011 3330 6011 3600 5418 3600 5418 3330 -4 1 0 40 -1 0 12 0.0000 6 120 405 5714 3527 XML\001 --6 -6 3465 3015 6660 3285 -2 2 0 1 0 7 50 -1 17 0.000 0 0 -1 0 0 5 - 3465 3015 6660 3015 6660 3285 3465 3285 3465 3015 -4 1 0 40 -1 0 12 0.0000 6 165 1485 5062 3207 Message dispatching\001 --6 -6 5445 3645 6660 3915 -6 5445 3645 6255 3870 -2 2 0 1 0 7 50 -1 17 0.000 0 0 -1 0 0 5 - 5453 3645 6232 3645 6232 3870 5453 3870 5453 3645 -4 1 0 40 -1 0 12 0.0000 6 120 615 5842 3817 SimGrid\001 --6 -6 6255 3645 6660 3915 -2 2 0 1 0 7 50 -1 17 0.000 0 0 -1 0 0 5 - 6284 3647 6644 3647 6644 3872 6284 3872 6284 3647 -4 1 0 40 -1 0 12 0.0000 6 120 270 6464 3819 File\001 --6 --6 -6 5220 3735 5370 3767 -1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 5295 3751 9 9 5295 3751 5304 3751 -1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 5236 3751 9 9 5236 3751 5245 3751 -1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 5354 3751 9 9 5354 3751 5363 3751 --6 -6 4050 3600 4590 3870 -6 4050 3600 4590 3870 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 4079 3641 4550 3641 4550 3866 4079 3866 4079 3641 --6 -4 1 0 40 -1 0 12 0.0000 6 120 375 4314 3813 UDP\001 --6 -6 4635 3600 5175 3870 -6 4635 3600 5175 3870 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 4664 3641 5135 3641 5135 3866 4664 3866 4664 3641 --6 -4 1 0 40 -1 0 12 0.0000 6 120 345 4899 3813 SSH\001 --6 -2 4 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5 - 10125 1800 10125 1215 3375 1215 3375 1800 10125 1800 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 3060 2025 3060 4815 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 3060 1800 3060 1215 -2 4 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5 - 10125 2655 10125 2070 3375 2070 3375 2655 10125 2655 -2 2 0 1 0 7 50 -1 17 0.000 0 0 -1 0 0 5 - 8550 2250 9855 2250 9855 2520 8550 2520 8550 2250 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 4815 2250 6075 2250 6075 2520 4815 2520 4815 2250 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 6232 2250 6772 2250 6772 2520 6232 2520 6232 2250 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 6930 2250 8415 2250 8415 2520 6930 2520 6930 2250 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 8550 1395 9360 1395 9360 1665 8550 1665 8550 1395 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 7425 1395 8235 1395 8235 1665 7425 1665 7425 1395 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 6300 1395 7110 1395 7110 1665 6300 1665 6300 1395 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 5175 1395 5985 1395 5985 1665 5175 1665 5175 1395 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 4050 1395 4860 1395 4860 1665 4050 1665 4050 1395 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5 - 3645 2250 4680 2250 4680 2520 3645 2520 3645 2250 -2 4 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5 - 10125 4860 10125 4140 3375 4140 3375 4860 10125 4860 -2 4 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5 - 8460 3780 8460 2790 6840 2790 6840 3780 8460 3780 -2 4 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5 - 10125 3780 10125 2790 8505 2790 8505 3780 10125 3780 -2 4 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5 - 6750 3960 6750 2790 3375 2790 3375 3960 6750 3960 -2 2 0 1 0 7 50 -1 17 0.000 0 0 -1 0 0 5 - 3465 3641 3936 3641 3936 3866 3465 3866 3465 3641 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 - 3465 3330 5265 3330 5265 3600 3465 3600 3465 3330 -2 2 0 1 0 7 40 -1 -1 0.000 0 0 7 0 0 5 - 6946 3195 7540 3195 7540 3420 6946 3420 6946 3195 -2 2 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5 - 7620 3195 8340 3195 8340 3420 7620 3420 7620 3195 -2 2 0 1 0 7 40 -1 -1 0.000 0 0 7 0 0 5 - 6946 3465 7540 3465 7540 3690 6946 3690 6946 3465 -4 1 0 40 -1 2 13 0.0000 6 135 1440 4522 2970 Communications\001 -4 1 0 40 -1 2 13 1.5708 6 135 525 2970 3330 GRAS\001 -4 1 0 40 -1 2 13 1.5708 6 135 615 2970 1530 AMOK\001 -4 1 0 40 -1 2 13 1.5708 6 135 405 3285 3375 Base\001 -4 1 0 40 -1 2 13 1.5708 6 135 720 3285 2385 Modules\001 -4 1 0 40 -1 0 12 0.0000 6 165 1275 7694 2445 Host management\001 -4 1 0 40 -1 0 12 0.0000 6 120 435 6501 2445 Locks\001 -4 1 0 40 -1 0 12 0.0000 6 120 1065 5444 2445 Leader election\001 -4 1 0 40 -1 0 12 0.0000 6 165 900 4162 2445 Logs control\001 -4 1 0 40 -1 0 12 0.0000 6 120 1065 9202 2445 Bandwidth test\001 -4 1 0 40 -1 0 12 0.0000 6 120 615 8954 1590 ALNeM\001 -4 1 0 40 -1 0 12 0.0000 6 120 450 7830 1590 APST\001 -4 1 0 40 -1 0 12 0.0000 6 120 300 6705 1590 GIS\001 -4 1 0 40 -1 0 12 0.0000 6 120 300 5580 1590 PKI\001 -4 1 0 40 -1 0 12 0.0000 6 120 405 4454 1590 NWS\001 -4 1 0 40 -1 2 13 0.0000 6 180 675 7649 2970 Syscalls\001 -4 1 0 40 -1 2 13 0.0000 6 135 1170 7650 3150 virtualization\001 -4 1 0 40 -1 0 12 0.0000 6 120 420 7230 3367 Linux\001 -4 1 0 40 -1 0 12 0.0000 6 120 615 7979 3367 SimGrid\001 -4 1 0 40 -1 0 12 0.0000 6 120 495 7242 3637 Solaris\001 -4 1 0 40 -1 2 13 1.5708 6 135 420 3285 4500 Core\001 -4 1 0 40 -1 0 12 0.0000 6 120 330 3729 3813 TCP\001 -4 1 0 40 -1 0 12 0.0000 6 165 1575 4365 3527 Binary Representation\001 diff --git a/cruft/doc/gras-sections.txt b/cruft/doc/gras-sections.txt deleted file mode 100644 index 9498b05629..0000000000 --- a/cruft/doc/gras-sections.txt +++ /dev/null @@ -1,444 +0,0 @@ -
-xbt_error -errors -xbt_error_t -xbt_error_name -
- -
-xbt_log -logging -xbt_log_priority_t - -xbt_log_control_set - -XBT_LOG_NEW_CATEGORY -XBT_LOG_NEW_SUBCATEGORY -XBT_LOG_NEW_DEFAULT_CATEGORY -XBT_LOG_NEW_DEFAULT_SUBCATEGORY - -XBT_LOG_DEFAULT_CATEGORY -XBT_LOG_EXTERNAL_CATEGORY - -XBT_LOG_ISENABLED -XBT_LOG_STATIC_THRESHOLD - -xbt_log_appender_set -xbt_log_default_appender - -CDEBUG6 -CVERB6 -CINFO6 -CWARN6 -CERROR6 -CCRITICAL6 - - -DEBUG6 -VERB6 -INFO6 -WARN6 -ERROR6 -CRITICAL6 - - -XBT_LOG_ROOT_CAT -xbt_log_parent_set -xbt_log_threshold_set - -CLOG0 -CLOG1 -CLOG2 -CLOG3 -CLOG4 -CLOG5 -CLOG6 -CDEBUG0 -CDEBUG1 -CDEBUG2 -CDEBUG3 -CDEBUG4 -CDEBUG5 -CVERB0 -CVERB1 -CVERB2 -CVERB3 -CVERB4 -CVERB5 -CINFO0 -CINFO1 -CINFO2 -CINFO3 -CINFO4 -CINFO5 -CWARN0 -CWARN1 -CWARN2 -CWARN3 -CWARN4 -CWARN5 -CERROR0 -CERROR1 -CERROR2 -CERROR3 -CERROR4 -CERROR5 -CCRITICAL0 -CCRITICAL1 -CCRITICAL2 -CCRITICAL3 -CCRITICAL4 -CCRITICAL5 - -LOG0 -LOG1 -LOG2 -LOG3 -LOG4 -LOG5 -LOG6 -DEBUG0 -DEBUG1 -DEBUG2 -DEBUG3 -DEBUG4 -DEBUG5 -VERB0 -VERB1 -VERB2 -VERB3 -VERB4 -VERB5 -INFO0 -INFO1 -INFO2 -INFO3 -INFO4 -INFO5 -WARN0 -WARN1 -WARN2 -WARN3 -WARN4 -WARN5 -ERROR0 -ERROR1 -ERROR2 -ERROR3 -ERROR4 -ERROR5 -CRITICAL0 -CRITICAL1 -CRITICAL2 -CRITICAL3 -CRITICAL4 -CRITICAL5 -
- -
-xbt_dynar -dynamic arrays -xbt_dynar_new -xbt_dynar_free -xbt_dynar_free_container -xbt_dynar_length -xbt_dynar_reset -xbt_dynar_get -xbt_dynar_set -xbt_dynar_replace -xbt_dynar_insert_at -xbt_dynar_remove_at -xbt_dynar_map -xbt_dynar_push -xbt_dynar_pop -xbt_dynar_shift -xbt_dynar_unshift -xbt_dynar_foreach -xbt_dynar_cursor_rm - -xbt_dynar_cursor_first -xbt_dynar_cursor_get -xbt_dynar_cursor_step -
- -
-xbt_dict -dictionaries -xbt_dict_new -xbt_dict_free -xbt_dict_set -xbt_dict_set_ext -xbt_dict_get -xbt_dict_get_ext -xbt_dict_remove -xbt_dict_remove_ext -xbt_dict_dump -xbt_dict_print -xbt_dict_prints -xbt_dict_cursor_get_data -xbt_dict_cursor_get_key -xbt_dict_foreach - -xbt_dict_cursor_new -xbt_dict_cursor_free -xbt_dict_cursor_rewind - - -xbt_dictelm_remove_ext -xbt_dictelm_insert_ext -xbt_dictelm_remove -xbt_dictelm_print_fct -xbt_dictelm_insert -xbt_dictelm_free -xbt_dictelm_retrieve -xbt_dictelm_dump -xbt_dictelm_retrieve_ext -
- -
-xbt_set -xbt-set -xbt_set_new -xbt_set_free - -xbt_set_add -xbt_set_get_by_name -xbt_set_get_by_name_ext -xbt_set_get_by_id - -xbt_set_foreach - - -xbt_set_cursor_step -xbt_set_cursor_get_or_free -xbt_set_cursor_first -
- -
-xbt_swag -xbt-swag -xbt_swag_new -xbt_swag_free -xbt_swag_init -xbt_swag_insert -xbt_swag_remove -xbt_swag_extract -xbt_swag_size -xbt_swag_belongs - -xbt_swag_foreach -xbt_swag_foreach_safe -xbt_swag_offset - -xbt_swag_getFirst -xbt_swag_getNext -xbt_swag_getPrev -
- -
-xbt_heap -xbt-heap -xbt_swag_hookup -xbt_swag - -xbt_heap_new -xbt_heap_free -xbt_heap_size - -xbt_heap_push -xbt_heap_pop - -xbt_heap_maxkey -xbt_heap_maxcontent -
- -
-surf_maxmin -surf-maxmin -lmm_variable_t -lmm_constraint_t -lmm_system_t -lmm_system_new -lmm_system_free -lmm_variable_disable -lmm_constraint_new -lmm_constraint_free -lmm_variable_new -lmm_variable_free -lmm_variable_getvalue -lmm_expand -lmm_get_cnst_from_var -lmm_get_number_of_cnst_from_var -lmm_get_var_from_cnst -lmm_constraint_id -lmm_variable_id -lmm_update -lmm_update_variable_bound -lmm_update_variable_weight -lmm_update_constraint_bound -lmm_constraint_used -lmm_solve -
- - -
-Configuration management -xbt_config -xbt_cfg_new -xbt_cfg_cpy -xbt_cfg_free -xbt_cfg_dump - -xbt_cfg_register -xbt_cfg_register_str -xbt_cfg_check - -xbt_cfg_set_parse -xbt_cfg_set -xbt_cfg_set_vargs - -xbt_cfg_set_int -xbt_cfg_set_double -xbt_cfg_set_string -xbt_cfg_set_host - -xbt_cfg_rm_int -xbt_cfg_rm_double -xbt_cfg_rm_string -xbt_cfg_rm_host -xbt_cfg_empty - -xbt_cfg_get_int -xbt_cfg_get_double -xbt_cfg_get_string -xbt_cfg_get_host -xbt_cfg_get_dynar - - -xbt_cfgelm_type_t -xbt_cfg_get_type -
- -
-comm_datadesc -Data description -gras_datadesc_type_t - -gras_datadesc_type_cb_int_t -gras_datadesc_type_cb_void_t - -gras_datadesc_by_name -GRAS_DEFINE_TYPE -gras_datadesc_by_symbol - -gras_datadesc_array_fixed -gras_datadesc_array_dyn -gras_datadesc_ref -gras_datadesc_ref_generic -gras_datadesc_struct -gras_datadesc_struct_append -gras_datadesc_struct_close -gras_datadesc_union -gras_datadesc_union_append -gras_datadesc_union_close -gras_datadesc_ref_pop_arr - -gras_datadesc_cb_send -gras_datadesc_cb_recv - -gras_cbps_i_pop -gras_cbps_i_push - -gras_cbps_v_pop -gras_cbps_v_push -gras_cbps_v_set -gras_cbps_v_get -gras_cbps_block_begin -gras_cbps_block_end - -gras_arch_selfid -
- -
-comm_socks -Sockets -gras_socket_client -gras_socket_server -gras_socket_client_ext -gras_socket_server_ext -gras_socket_client_from_file -gras_socket_server_from_file -gras_socket_close -gras_socket_peer_name -gras_socket_peer_port -gras_socket_my_port -
- -
-comm_messages -Messages -gras_msgtype_declare -gras_msgtype_declare_v -gras_msgtype_by_name -gras_msgtype_by_namev - -gras_cb_t -gras_cb_register -gras_cb_unregister - -gras_msg_send -gras_msg_wait -gras_msg_handle - - -gras_msg_recv -gras_msg_init -gras_msg_exit -
- -
-virtu_globals -Globals -gras_userdata_get -gras_userdata_set -gras_userdata_new -
- -
-virtu_syscall -System calls abstraction layer -gras_os_time -gras_os_sleep -
- -
-virtu_fs -File system -gras_fs_fopen -
- -
-cruft -Cruft to ignore in the documentation - -BEGIN_DECL -END_DECL -PACKAGE -PACKAGE_BUGREPORT -PACKAGE_NAME -PACKAGE_STRING -PACKAGE_TARNAME -PACKAGE_VERSION -VERSION -HAVE_UNISTD_H -HAVE_STDLIB_H -HAVE_DLFCN_H -HAVE_STDINT_H -HAVE_STRING_H -HAVE_STRINGS_H -HAVE_MEMORY_H -HAVE_SYS_STAT_H -HAVE_INTTYPES_H -HAVE_SYS_TYPES_H -STDC_HEADERS -
diff --git a/cruft/doc/gtk-doc.make b/cruft/doc/gtk-doc.make deleted file mode 100644 index 59c115bb0c..0000000000 --- a/cruft/doc/gtk-doc.make +++ /dev/null @@ -1,134 +0,0 @@ -# -*- mode: makefile -*- - -#################################### -# Everything below here is generic # -#################################### -htmldir = $(shell if test "x$(TARGET_DIR)" = x ; then echo @htmldir@/$(DOC_MODULE) ; else echo $(TARGET_DIR) ; fi) -html_DATA = $(wildcard html/*) - -if GTK_DOC_USE_LIBTOOL -GTKDOC_CC = $(LIBTOOL) --mode=compile $(CC) $(INCLUDES) $(AM_CFLAGS) $(CFLAGS) -GTKDOC_LD = $(LIBTOOL) --mode=link $(CC) $(AM_CFLAGS) $(CFLAGS) $(LDFLAGS) -else -GTKDOC_CC = $(CC) $(INCLUDES) $(AM_CFLAGS) $(CFLAGS) -GTKDOC_LD = $(CC) $(AM_CFLAGS) $(CFLAGS) $(LDFLAGS) -endif - -# We set GPATH here; this gives us semantics for GNU make -# which are more like other make's VPATH, when it comes to -# whether a source that is a target of one rule is then -# searched for in VPATH/GPATH. -# -GPATH = $(srcdir) - -EXTRA_DIST = $(wildcard \ - $(content_files) \ - $(HTML_IMAGES) \ - $(DOC_MAIN_SGML_FILE) \ - $(DOC_MODULE).types \ - $(DOC_MODULE)-sections.txt \ - $(DOC_MODULE)-overrides.txt ) - -DOC_STAMPS=scan-build.stamp tmpl-build.stamp sgml-build.stamp html-build.stamp \ - $(srcdir)/tmpl.stamp $(srcdir)/sgml.stamp $(srcdir)/html.stamp - -SCANOBJ_FILES = \ - $(DOC_MODULE).args \ - $(DOC_MODULE).hierarchy \ - $(DOC_MODULE).interfaces \ - $(DOC_MODULE).prerequisites \ - $(DOC_MODULE).signals - -CLEANFILES = $(SCANOBJ_FILES) $(DOC_MODULE)-unused.txt $(DOC_STAMPS) - -if ENABLE_GTK_DOC -all-local: html-build.stamp - -#### scan #### - -scan-build.stamp: $(HFILE_GLOB) - @echo '*** Scanning header files ***' - @-chmod -R u+w $(srcdir) - if grep -l '^..*$$' $(srcdir)/$(DOC_MODULE).types > /dev/null ; then \ - CC="$(GTKDOC_CC)" LD="$(GTKDOC_LD)" CFLAGS="$(GTKDOC_CFLAGS)" LDFLAGS="$(GTKDOC_LIBS)" gtkdoc-scangobj $(SCANGOBJ_OPTIONS) --module=$(DOC_MODULE) --output-dir=$(srcdir) ; \ - else \ - cd $(srcdir) ; \ - for i in $(SCANOBJ_FILES) ; do \ - test -f $$i || touch $$i ; \ - done \ - fi - cd $(srcdir) && \ - gtkdoc-scan --module=$(DOC_MODULE) --source-dir=$(DOC_SOURCE_DIR) --ignore-headers="$(IGNORE_HFILES)" $(SCAN_OPTIONS) $(EXTRA_HFILES) - touch scan-build.stamp - -$(DOC_MODULE)-decl.txt $(SCANOBJ_FILES): scan-build.stamp - @true - -#### templates #### - -tmpl-build.stamp: $(DOC_MODULE)-decl.txt $(SCANOBJ_FILES) $(DOC_MODULE)-sections.txt $(DOC_MODULE)-overrides.txt - @echo '*** Rebuilding template files ***' - @-chmod -R u+w $(srcdir) - cd $(srcdir) && gtkdoc-mktmpl --module=$(DOC_MODULE) - touch tmpl-build.stamp - -tmpl.stamp: tmpl-build.stamp - @true - -#### xml #### - -sgml-build.stamp: tmpl.stamp $(CFILE_GLOB) $(srcdir)/tmpl/*.sgml - @echo '*** Building XML ***' - @-chmod -R u+w $(srcdir) - cd $(srcdir) && \ - gtkdoc-mkdb --module=$(DOC_MODULE) --source-dir=$(DOC_SOURCE_DIR) --output-format=xml $(MKDB_OPTIONS) - touch sgml-build.stamp - -sgml.stamp: sgml-build.stamp - @true - -#### html #### - -html-build.stamp: sgml.stamp $(DOC_MAIN_SGML_FILE) $(content_files) - @echo '*** Building HTML ***' - @-chmod -R u+w $(srcdir) - rm -rf $(srcdir)/html - mkdir $(srcdir)/html - cd $(srcdir)/html && gtkdoc-mkhtml $(DOC_MODULE) ../$(DOC_MAIN_SGML_FILE) - test "x$(HTML_IMAGES)" = "x" || ( cd $(srcdir) && cp $(HTML_IMAGES) html ) - @echo '-- Fixing Crossreferences' - cd $(srcdir) && gtkdoc-fixxref --module-dir=html --html-dir=$(HTML_DIR) $(FIXXREF_OPTIONS) - touch html-build.stamp -else -all-local: -endif - -############## - -clean-local: - rm -f *~ *.bak - rm -rf .libs - -maintainer-clean-local: clean - cd $(srcdir) && rm -rf xml html $(DOC_MODULE)-decl-list.txt $(DOC_MODULE)-decl.txt - -# -# Require gtk-doc when making dist -# -if ENABLE_GTK_DOC -dist-check-gtkdoc: -else -dist-check-gtkdoc: - @echo "*** gtk-doc must be installed and enabled in order to make dist" - @false -endif - -dist-hook: dist-check-gtkdoc dist-hook-local - mkdir $(distdir)/tmpl - mkdir $(distdir)/xml - mkdir $(distdir)/html - -cp $(srcdir)/tmpl/*.sgml $(distdir)/tmpl - -cp $(srcdir)/xml/*.xml $(distdir)/xml - -cp $(srcdir)/html/* $(distdir)/html - -.PHONY : dist-hook-local diff --git a/cruft/doc/overview.xml b/cruft/doc/overview.xml deleted file mode 100644 index 2f757b3488..0000000000 --- a/cruft/doc/overview.xml +++ /dev/null @@ -1,109 +0,0 @@ - - -Overview -3 -GRAS Library - - - -OverviewOverview on the GRAS library - - - -Introduction -This document introduce the GRAS library (Grid Reality And - Simulation, or according to my english dictionary, - Generally Recognized As Safe ;). - -Here are the problems when you want to do so: - - - Communication in SG is done by passing tasks, while in - RL, you have to deal with sockets (or any wrapper to it). - - In RL, each process should provide a main() - function, and it's obviously not the case in SG. - - - - - - - Application class target - If you want to run your code both in RL and in SG, you won't be - able to use the full set of features offered by any of those two - worlds. GRAS tries to provide a suffisent set of features to develop - your application, and implement them in both worlds. - - GRAS uses the paradigm of event-driven - programming, which is an extension to the message-passing - one. Any process of a typical event-driven application declares - callback to incoming events, which can be messages from other - processes, timers or others. - - All messages have an header, specifying its type, and attached - data, represented as one or several C structures. In order to send the - data over the network in RL, a type-description mecanism is provided, and - the RL version of GRAS implements XDR functionnalities. That is to say - that the data are converted to a intermediate representation before being - sent. A possible extension would be to use CDR, where data are sent in - the native format of the sender host, and converted on the destination - host only if needed, but this is still to do. - - In order to not reimplement the wheel, GRAS use existing code, and - adapt them to make them work together. The SG version naturally use the - SimGrid toolkit, while the RL version is based over the communication - library used in NWSOnly the actual sending/receiving - features and formattypes features were taken from NWS. GRAS messaging - stuff is quite different from the NWS one, which was not easily adaptable - in SG as is.. That's why we will now present the NWS - project in order to give you a better understanding of its internals used - here. - - - - The Network Weather Service and its "portability" library - - The purpose of the NWS project is to provide any kind of usefull - information about the availability of a Grid platform. like the CPU load, - free memory and disk of all hosts, the bandwidth and latency between each - host pair, and so on. It is also able to predict the future trend of each - value by applying some statistical treatement to the measurements. - - In order to achieve this goal, the NWS system is composed of four - kind of processes: - - Sensors: those process are in charge or realizing the - actual measurement needed by the system. - - Memory servers: they store on disk the result of the experiments - conducted by the sensors for a later use. - - Forecasters: when a client application asks to, the - forecasters retrieves the measurements from the memory servers, apply - the needed statistical treatement, and then inform the client of the - predicted variations. - - NameServer: Every process in the NWS system have to - register itself to the nameserver, so that any process looks for another - element, it can find the answer by asking to the nameserver. - - - As you can see, this system is distributed by nature, and its - authors builded a specific toolbox they call the portability library. It - contains a great quantity of cool stuff to do various kind of things. The - main part is a very high level messaging library, where processes declare - callbacks to strongly typed messages sent from other processes. - - One of the limitation of this system is that even if processes can - ear to several sockets, all messages received from the different sources - are mixed together and handled by the same control loop. GRAS inherit - this limitation, but in fact, we don't think that it's really limitating, - thanks to the fact that messages are strongly typed. - - The philosophy of this library constitues the heart of GRAS, which - actually provide the same kind of features. - - - - diff --git a/cruft/doc/tmpl/comm_datadesc.sgml b/cruft/doc/tmpl/comm_datadesc.sgml deleted file mode 100644 index 23ccc3a93b..0000000000 --- a/cruft/doc/tmpl/comm_datadesc.sgml +++ /dev/null @@ -1,297 +0,0 @@ - -Data description - - -Describing data to be exchanged - - - - - - - - - - - - - - - - -@vars: -@data: -@Returns: - -@p_type: - - - - - - - -@vars: -@data: - -@p_type: - - - - - - - -@name: -@Returns: - -@type: - - - - - - - -@name: -@def: - - - - - - - -@name: - - - - - - - -@name: -@element_type: -@fixed_size: -@Returns: - -@dst: - - - - - - - -@name: -@element_type: -@dynamic_size: -@Returns: - -@dst: - - - - - - - -@name: -@referenced_type: -@Returns: - -@dst: - - - - - - - -@name: -@selector: -@Returns: - -@dst: -@discriminant: - - - - - - - -@name: -@Returns: - -@dst: - - - - - - - -@struct_type: -@name: -@field_type: - -@Returns: - - - - - - - -@struct_type: - - - - - - - -@name: -@selector: -@Returns: - -@dst: - - - - - - - -@union_type: -@name: -@field_type: - -@Returns: - - - - - - - -@union_type: - - - - - - - -@element_type: -@Returns: - -@dst: - - - - - - - -@type: -@pre: - - - - - - - -@type: -@post: - - - - - - - -@ps: -@Returns: - - - - - - - -@ps: -@val: - - - - - - - -@ps: -@name: -@ddt: -@res: -@Returns: - - - - - - - -@ps: -@name: -@data: -@ddt: -@Returns: - - - - - - - -@ps: -@name: -@data: -@ddt: - - - - - - - -@ps: -@name: -@ddt: - - - - - - - -@ps: - - - - - - - -@ps: - - - - - - - -@Returns: - - diff --git a/cruft/doc/tmpl/comm_dd_cbps.sgml b/cruft/doc/tmpl/comm_dd_cbps.sgml deleted file mode 100644 index 7093c855b6..0000000000 --- a/cruft/doc/tmpl/comm_dd_cbps.sgml +++ /dev/null @@ -1,74 +0,0 @@ - -Data description callbacks persistant state - - - - - - - - - - - - - - - - - - - -@ps: - - - - - - - -@ps: - - - - - - - -@ps: -@name: -@ddt: - - - - - - - -@ps: -@name: -@ddt: - - - - - - - -@ps: -@name: -@data: -@ddt: - - - - - - - -@ps: -@name: -@data: -@ddt: - - diff --git a/cruft/doc/tmpl/comm_messages.sgml b/cruft/doc/tmpl/comm_messages.sgml deleted file mode 100644 index 8ea25b652c..0000000000 --- a/cruft/doc/tmpl/comm_messages.sgml +++ /dev/null @@ -1,139 +0,0 @@ - -Messages - - -Defining messages and callbacks, and sending/receiving messages. - - - - - - - - - - - - - - - - -@name: -@payload: - -@Returns: -@dst: - - - - - - - -@name: -@version: -@payload: - -@Returns: -@dst: - - - - - - - -@name: -@Returns: - -@dst: - - - - - - - -@name: -@version: -@Returns: - -@dst: - - - - - - - -@expeditor: -@payload: -@Returns: - -@payload_type: -@payload_data: -@msg: - - - - - - - -@msgtype: -@cb: - -@Returns: -@message: -@TTL: - - - - - - - -@msgtype: -@cb: - - - - - - - -@sock: -@msgtype: -@payload: -@Returns: - -@sd: -@msg: -@freeDirective: - - - - - - - -@timeout: -@msgt_want: -@expeditor: -@payload: -@Returns: - -@id: -@message: - - - - - - - -@timeOut: -@Returns: - - diff --git a/cruft/doc/tmpl/comm_socks.sgml b/cruft/doc/tmpl/comm_socks.sgml deleted file mode 100644 index fe3dee977d..0000000000 --- a/cruft/doc/tmpl/comm_socks.sgml +++ /dev/null @@ -1,127 +0,0 @@ - -Sockets - - -Open/close sockets, and get info on peer. - - - - - - - - - - - - - - - - -@host: -@Param2: -@dst: -@Returns: - -@bufSize: -@sock: - - - - - - - -@Param1: -@dst: -@Returns: - -@bufSize: - - - - - - - -@host: -@Param2: -@bufSize: -@raw: -@dst: -@Returns: - - - - - - - -@Param1: -@bufSize: -@raw: -@dst: -@Returns: - - - - - - - -@path: -@dst: -@Returns: - - - - - - - -@path: -@dst: -@Returns: - - - - - - - -@sd: - -@sock: -@Returns: - - - - - - - -@sock: -@Returns: - -@sd: - - - - - - - -@sock: -@Returns: - - - - - - - -@sock: -@Returns: - - diff --git a/cruft/doc/tmpl/cruft.sgml b/cruft/doc/tmpl/cruft.sgml deleted file mode 100644 index a387d76dfa..0000000000 --- a/cruft/doc/tmpl/cruft.sgml +++ /dev/null @@ -1,16 +0,0 @@ - -Cruft to ignore in the documentation - - - - - - - - - - - - - - diff --git a/cruft/doc/tmpl/gras-overview.sgml b/cruft/doc/tmpl/gras-overview.sgml deleted file mode 100644 index 38741835b7..0000000000 --- a/cruft/doc/tmpl/gras-overview.sgml +++ /dev/null @@ -1,121 +0,0 @@ - -Overview - - -Overview of the GRAS library - - - This document introduce the GRAS library (Grid Reality - And Simulation, or according to my english dictionary, - Generally Recognized As Safe ;). - - - Overview - The purpose of the GRAS is to allow the developpement of - distributed programs which will work with as few as possible - modification both on the SimGrid simulator (SG), and in the Real Life - (RL). - - Here are the problems when you want to do so: - - - Communication in SG is done by passing tasks, while in - RL, you have to deal with sockets (or any wrapper to it). - - In RL, each process should provide a main() - function, and it's obviously not the case in SG. - - - - - - Application class target - If you want to run your code both in RL and in SG, you won't be - able to use the full set of features offered by any of those two - worlds. GRAS tries to provide a suffisent set of features to develop - your application, and implement them in both worlds. - - GRAS uses the paradigm of event-driven - programming, which is an extension to the message-passing - one. Any process of a typical event-driven application declares - callback to incoming events, which can be messages from other - processes, timers or others. - - All messages have an header, specifying its type, and attached - data, represented as one or several C structures. In order to send - the data over the network in RL, a type-description mecanism is - provided, and the RL version of GRAS implements CDR - functionnalities. That is to say that the data are sent in the native - format of the sender host, and converted on the destination host only - if needed. - - In order to not reimplement the wheel, GRAS use existing code, - and adapt them to make them work together. The SG version naturally - use the SimGrid toolkit, while the RL version is based over the - communication library used in NWS (note that this library was somehow - modified, since the previous version use XDR, ie both the sender and - the receiver convert the data from/to a so called network - format). That's why some basic knowledge about how NWS work is - supposed in this document. But don't worry, you only have to know the - basics about NWS, the internals needed to understand the document - will be presented when needed. - - - - - - - - - - - - -@CHAR_TYPE: -@DOUBLE_TYPE: -@FLOAT_TYPE: -@INT_TYPE: -@LONG_TYPE: -@SHORT_TYPE: -@UNSIGNED_INT_TYPE: -@UNSIGNED_LONG_TYPE: -@UNSIGNED_SHORT_TYPE: -@STRUCT_TYPE: - - - - - - -@type: -@repetitions: - - - - - - - -@type: -@repetitions: -@offset: - - - - - - - -@structType: -@lastMember: -@memberType: -@repetitions: - - - - - - - - - diff --git a/cruft/doc/tmpl/gras-unused.sgml b/cruft/doc/tmpl/gras-unused.sgml deleted file mode 100644 index 13fc99c080..0000000000 --- a/cruft/doc/tmpl/gras-unused.sgml +++ /dev/null @@ -1,4301 +0,0 @@ - -In order to allow GRAS to send data over the network (or simply to -dupplicate it in SG), you have to describe the structure of data attached -with each message. This mecanism is stolen from NWS message passing -interface. - -For each message, you have to declare a structure representing the -data to send as payload with the message. - - - Sending (or receiving) simple structures - Let's imagin you want to declare a STORE_STATE - message, which will send some data to the memory server for inclusion in - the database. Here is the structure we want to send: - - - struct state { - char id[STATE_NAME_SIZE]; - int rec_size; - int rec_count; - double seq_no; - double time_out; - }; - - - And here is the structure description GRAS needs to be able to send - this over the network: - - - const static DataDescriptor stateDescriptor[] = - {SIMPLE_MEMBER(CHAR_TYPE, STATE_NAME_SIZE, offsetof(struct state, id)), - SIMPLE_MEMBER(INT_TYPE, 1, offsetof(struct state, rec_size)), - SIMPLE_MEMBER(INT_TYPE, 1, offsetof(struct state, rec_count)), - SIMPLE_MEMBER(DOUBLE_TYPE, 1, offsetof(struct state, seq_no)), - SIMPLE_MEMBER(DOUBLE_TYPE, 1, offsetof(struct state, time_out))}; - - - Contrary to what one could think when you first see it, it's pretty - easy. A structure descriptor is a list of descriptions, describing each - field of the structure. For example, for the first field, you say that - the base type is CHAR_TYPE, that there is - STATE_NAME_SIZE element of this type and that it's - position in the structure is computed by offsetof(struct state, - id). This leads to two remarks: - - - - it's impossible to send dynamic sized strings that way. It's a - known limitation, but I think we can live with it. - - - Yes, the offsetof(struct state, id) - construction is C ANSI and is portable. - - - - - - Sending (or receiving) complex structure - How to send non-flat structures, do you ask? It's not harder. Let's - imagin you want to send the following structure: - - - typedef struct { - unsigned long address; - unsigned long port; - } CliqueMember; - - typedef struct { - char name[MAX_CLIQUE_NAME_SIZE]; - double whenGenerated; - double instance; - char skill[MAX_SKILL_SIZE]; - char options[MAX_OPTIONS_SIZE]; - double period; - double timeOut; - CliqueMember members[MAX_MEMBERS]; - unsigned int count; - unsigned int leader; - } Clique; - - - As you can see, this structure contains an array of another user - defined structure. To be able to send struct Clique, - you have to describe each structures that way: - - - static const DataDescriptor cliqueMemberDescriptor[] = - {SIMPLE_MEMBER(UNSIGNED_LONG_TYPE, 1, offsetof(CliqueMember, address)), - SIMPLE_MEMBER(UNSIGNED_LONG_TYPE, 1, offsetof(CliqueMember, port))}; - - static const DataDescriptor cliqueDescriptor[] = - {SIMPLE_MEMBER(CHAR_TYPE, MAX_CLIQUE_NAME_SIZE, offsetof(Clique, name)), - SIMPLE_MEMBER(DOUBLE_TYPE, 1, offsetof(Clique, whenGenerated)), - SIMPLE_MEMBER(DOUBLE_TYPE, 1, offsetof(Clique, instance)), - SIMPLE_MEMBER(CHAR_TYPE, MAX_SKILL_SIZE, offsetof(Clique, skill)), - SIMPLE_MEMBER(CHAR_TYPE, MAX_OPTIONS_SIZE, offsetof(Clique, options)), - SIMPLE_MEMBER(DOUBLE_TYPE, 1, offsetof(Clique, period)), - SIMPLE_MEMBER(DOUBLE_TYPE, 1, offsetof(Clique, timeOut)), - {STRUCT_TYPE, MAX_MEMBERS, offsetof(Clique, members), - (DataDescriptor *)&cliqueMemberDescriptor, cliqueMemberDescriptorLength, - PAD_BYTES(CliqueMember, port, unsigned long, 1)}, - SIMPLE_MEMBER(UNSIGNED_INT_TYPE, 1, offsetof(Clique, count)), - SIMPLE_MEMBER(UNSIGNED_INT_TYPE, 1, offsetof(Clique, leader))}; - - - So, even if less natural, it is possible to send structures - containing structures with these tools. - - You can see that it's not only impossible to send dynamic-sized - strings, it impossible to send dynamic-sized arrays. Here, - MAX_MEMBERS is the maximum of members a clique can - contain. In NWS, this value is defined to 100. I'm not - sure, but I think that all the 100 values are sent each time, even if - there is only 3 non-null members. Yes, that's - bad. - - The DataDescriptor_t MUST be const. Malloc'ing them and - then casting them on argument passing IS NOT OK. This is because we get - the number of elements in the array with the sizeof(dd)/sizeof(dd[0]). - - - - - - - - - - - -Describing the data - - - -DataDescriptor API - - - - - - - - - - - - - - - - - - - -Dynamic arrays - - - - - - - - - - - - - - - - - - - -ErrLog - - - - - - - - - - - - - - - -Handling sockets - - - -Sockets API - - - - - - - - - - - - - - - - - - - -comm_callbacks - - - - - - - - - - - - - - - - - - - -comm_cb - - - - - - - - - - - - - - - -Advanced ways to describe data (for experts) - - - -Advanced Data description - - - - - - - - - - - - - - - - - - - -Data description callbacks persistant state - - - - - - - - - - - - - - - - - - - -config - - - - - - - - - - - - - - - - - - - -Data description callbacks persistant state - - - - - - - - - - - - - - - - - - - -Implementation of data description - - - - - - - - - - - - - - - - - - - -dico - - - - -This module provide the quite usual dynamic array facility. - - - - - - - - - - -Dynamic array - - - -dynar - - - - This document introduce the GRAS library (Grid Reality - And Simulation, or according to my english dictionary, - Generally Recognized As Safe ;). - - - Overview - The purpose of the GRAS is to allow the developpement of - distributed programs which will work with as few as possible - modification both on the SimGrid simulator (SG), and in the Real Life - (RL). - - Here are the problems when you want to do so: - - - Communication in SG is done by passing tasks, while in - RL, you have to deal with sockets (or any wrapper to it). - - In RL, each process should provide a main() - function, and it's obviously not the case in SG. - - - - - - Application class target - If you want to run your code both in RL and in SG, you won't be - able to use the full set of features offered by any of those two - worlds. GRAS tries to provide a suffisent set of features to develop - your application, and implement them in both worlds. - - GRAS uses the paradigm of event-driven - programming, which is an extension to the message-passing - one. Any process of a typical event-driven application declares - callback to incoming events, which can be messages from other - processes, timers or others. - - All messages have an header, specifying its type, and attached - data, represented as one or several C structures. In order to send - the data over the network in RL, a type-description mecanism is - provided, and the RL version of GRAS implements CDR - functionnalities. That is to say that the data are sent in the native - format of the sender host, and converted on the destination host only - if needed. - - In order to not reimplement the wheel, GRAS use existing code, - and adapt them to make them work together. The SG version naturally - use the SimGrid toolkit, while the RL version is based over the - communication library used in NWS (note that this library was somehow - modified, since the previous version use XDR, ie both the sender and - the receiver convert the data from/to a so called network - format). That's why some basic knowledge about how NWS work is - supposed in this document. But don't worry, you only have to know the - basics about NWS, the internals needed to understand the document - will be presented when needed. - - - - - - - - - - -Overview of the GRAS library - - - -Overview - - - - - - - - - - - - - - - - - - - -./gras-sections.txt.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml - - - - - - - - - - - - - - - - - - - -./gras-sections.txt.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml - - - - - - - - - - - - - - - - - - - -./gras-sections.txt.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml - - - - - - - - - - - - - - - - - - - -./gras-sections.txt.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml - - - - - - - - - - - - - - - - - - - -./gras-sections.txt.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml - - - - - - - - - - - - - - - - - - - -./gras-sections.txt.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml - - - - - - - - - - - - - - - - - - - -./gras-sections.txt.sgml.sgml.sgml.sgml.sgml.sgml.sgml - - - - - - - - - - - - - - - - - - - -./gras-sections.txt.sgml.sgml.sgml.sgml.sgml.sgml - - - - - - - - - - - - - - - - - - - -./gras-sections.txt.sgml.sgml.sgml.sgml.sgml - - - - - - - - - - - - - - - - - - - -./gras-sections.txt.sgml.sgml.sgml.sgml - - - - - - - - - - - - - - - - - - - -./gras-sections.txt.sgml.sgml.sgml - - - - - - - - - - - - - - - - - - - -./gras-sections.txt.sgml.sgml - - - - - - - - - - - - - - - - - - - -./gras-sections.txt.sgml - - - - - - - - - - - - - - - - - - - -./gras-sections.txt - - - - - - - - - - - - - - - - - - - -gras - - - - - - - - - - - - - - - - - - - -gras_private - - - - - - - - - - - - - - - -Implementation of GRAS suited for real life. - - - -RL - - - - - SimGrid was designed to ease the comparison of algorithms and - heuristics. That way, a lot of complicated notion from the system layer - were volontary left off. For example, migrating a process from an host to - another is as easy as: MSG_process_change_host(process, new_host). - - - - No need to tell that performing this operation on real platform is really - harder. This simplification is a very good thing when you want to rapidly - prototype code, but makes things somehow more complicated in GRAS since - we want to have a realistic API, since it have to be implemented in - reality also. - - - - The best example of complexity in GRAS_SG induced by simplicity in - SimGrid is the sockets handling. There is no "socket" in SG, but only - m_channel_t. In contrary to sockets from RL, no special treatment is - needed for a process before writing or reading on/from a channel. So, a - given channel can be pooled by more than one process. Likewise, you can - send data to a channel that nobody is actually listening to. - - - - The SG implementation of GRAS repport as an error the fact that nobody is - listening to the socket when trying to open a socket, or send stuff using - a previously openned socket. That way, the SG version can be used to - debug all syncronization issues. For that, we store mainly the PID of - both the sender and the receiver in the socket structure, and then - resolve PID->process at the lastest moment. This search is a bit - expensive, but as long as there is no real garbage collection in SG, with - the information "dead process" within the structure, it's the only - solution to make sure that we won't dereference pointers to an old freed - structure when the process on the other side of the structure did finish - since the creation of the socket. - - - - As said in the overview, the processes can declare to hear on several - sockets, but all incoming messages are handled by the same loop. So, we - can use only one channel per process, and use a table on each host to - determine to which process a message should be delivered depending on the - socket number provided by the sender. - - - - - -RL, the implementation suited for real life. - - - - - - -Implementation of GRAS on top of the simulator. - - - -SG - - - - - - - - - - - - - - - - - - - -nws_comm - - - - - - - - - - - - - - - -Configuration facilities. - - - -Config - - - - - - - - - - - - - - - -Data container associating data to a string key. - - - -Dictionnary - - - - -This module provide the quite usual dynamic array facility. - - - - - - - - - - -Use arrays, forget about malloc - - - -Dynamic array - - - - - - - - - - - - - - - -Error reporting - - - -Errors handling - - - - - This is an adaptation of the log4c project, which is dead upstream, and which - I was given the permission to fork under the LGPL licence by the authors. log4c - itself was loosely based on the Apache project's Log4J, Log4CC, - etc. project. Because C is not object oriented, a lot had to change. - - - - Overview - - - There is 3 main concepts: category, priority and appender. These three - concepts work together to enable developers to log messages according to - message type and priority, and to control at runtime how these messages are - formatted and where they are reported. - - - - - Category hierarchy - - - The first and foremost advantage of any logging API over plain printf() - resides in its ability to disable certain log statements while allowing - others to print unhindered. This capability assumes that the logging space, - that is, the space of all possible logging statements, is categorized - according to some developer-chosen criteria. - - - - This observation led to choosing category as the central concept of the - system. Every category is declared by providing a name and an optional - parent. If no parent is explicitly named, the root category, LOG_ROOT_CAT - is the category's parent. - - - - A category is created by a macro call at the top level of a file. A - category can be created with any one of the following macros: - - - - - @GRAS_LOG_NEW_CATEGORY(MyCat); - create a new root - - - - @GRAS_LOG_NEW_SUBCATEGORY(MyCat, ParentCat); - Create a new category being child of the category ParentCat - - - - @GRAS_LOG_NEW_DEFAULT_CATEGORY(MyCat); - Like GRAS_LOG_NEW_CATEGORY, but the new category is the default one - in this file - - - - @GRAS_LOG_NEW_DEFAULT_SUBCATEGORY(MyCat, ParentCat); - Like GRAS_LOG_NEW_SUBCATEGORY, but the new category is the default one - in this file - - - - - The parent cat can be defined in the same file or in another file, but each - category may have only one definition. - - - - Typically, there will be a Category for each module and sub-module, so you - can independently control logging for each module. - - - - - Priority - - - A category may be assigned a threshold priorty. The set of priorites are - defined by the @gras_log_priority_t enum. Their values are DEBUG, VERBOSE, - INFO, WARNING, ERROR and CRITICAL. - - - - If a given category is not assigned a threshold priority, then it inherits - one from its closest ancestor with an assigned threshold. - - - - To ensure that all categories can eventually inherit a threshold, the root - category always has an assigned threshold priority. - - - - Logging requests are made by invoking a logging macro on a category. All - of the macros have a printf-style format string followed by arguments. - Because most C compilers do not support vararg macros, there is a version - of the macro for any number of arguments from 0 to 6. The macro name ends - with the total number of arguments. - - - - Here is an example of the most basic type of macro: - - - CLOG5(MyCat, gras_log_priority_warning, "Values are: %d and '%s'", 5, "oops"); - - This is a logging request with priority WARN. - - - A logging request is said to be enabled if its priority is higher than or - equal to the threshold priority of its category. Otherwise, the request is - said to be disabled. A category without an assigned priority will inherit - one from the hierarchy. - - - - It is possible to use any non-negative integer as a priority. If, as in the - example, one of the standard priorites is used, then there is a convenience - macro that is typically used instead. For example, the above example is - equivalent to the shorter: - - - CWARN4(MyCat, "Values are: %d and '%s'", 5, "oops"); - - - - Default category - - - If @GRAS_LOG_NEW_DEFAULT_SUBCATEGORY(MyCat, Parent) or - @GRAS_LOG_NEW_DEFAULT_CATEGORY(MyCat) is used to create the category, then - the even shorter form can be used: - - - WARN3("Values are: %d and '%s'", 5, "oops"); - - - Only one default category can be created per file, though multiple - non-defaults can be created and used. - - - - - Example - - Here is a more complete example: - - - #include "gras.h" - - /* create a category and a default subcategory */ - GRAS_LOG_NEW_CATEGORY(VSS); - GRAS_LOG_NEW_DEFAULT_SUBCATEGORY(SA, VSS); - - main() { - /* Now set the parent's priority. - (the string would typcially be a runtime option) */ - gras_log_control_set("SA.thresh=3"); - - /* This request is enabled, because WARNING >= INFO. */ - CWARN2(VSS, "Low fuel level."); - - /* This request is disabled, because DEBUG < INFO. */ - CDEBUG2(VSS, "Starting search for nearest gas station."); - - /* The default category SA inherits its priority from VSS. Thus, - the following request is enabled because INFO >= INFO. */ - INFO1("Located nearest gas station."); - - /* This request is disabled, because DEBUG < INFO. */ - DEBUG1("Exiting gas station search"); - } - - - - Configuration - - - Configuration is typically done during program initialization by invoking - the gras_log_control_set() method. The control string passed to it - typically comes from the command line. Look at the doucmentation for that - function for the format of the control string. - - - - - Performance - - - Clever design insures efficiency. Except for the first invocation, a - disabled logging request requires an a single comparison of a static - variable to a constant. - - - - There is also compile time constant, @GRAS_LOG_STATIC_THRESHOLD, which - causes all logging requests with a lower priority to be optimized to 0 cost - by the compiler. By setting it to gras_log_priority_infinite, all logging - requests are statically disabled and cost nothing. Released executables - might typically be compiled with - "-DGRAS_LOG_STATIC_THRESHOLD=gras_log_priority_infinite". - - - - - Appenders - - - Each category has an optional appender. An appender is a pointer to a - structure whcih starts with a pointer to a doAppend() function. DoAppend() - prints a message to a log. - - - - WHen a category is passed a message by one of the logging macros, the - category performs the following actions: - - - - - - if the category has an appender, the message is passed to the - appender's doAppend() function, - - - - - - if 'willLogToParent' is true for the category, the message is passed - to the category's parent. - - - - By default, all categories except root have no appender and - 'willLogToParent' is true. This situation causes all messages to be - logged by the root category's appender. - - - - Typically, you would only change the root category's appender when you - wanted, say, a different output format. Copying defaultLogAppender.c - would be a good start. - - - - The default appender function currently prints to stderr, but more - would be needed, like the one able to send the logs to a remote - dedicated server. - - - - - - - Misc and Caveats - - - Do not use any of the macros that start with '_'. - - - - The current set of macros force each file to use categories declared in - that file. This is intentional. Make the category a child of the file's - module category. - - - - Log4J has a 'rolling file appender' which you can select with a run-time - option and specify the max file size. This would be a nice default for - non-kernel applications. - - - - Careful, category names are global variables. - - - - - - - - - - - -An easy-to-use, fast and flexible message logging architecture. - - - -Logging facilities - - - - - - - - - - - - - - - -Data storage for very quick retrieve - - - -Data set - - - - - - - - - - - - - - - - - - - -Sockets - - - - - - - - - - - - - - - - - - - -xbt_cfg - - - - - - - - - - - - - - - - - - - -xbt_dico - - - - - - - - - - - - - - - - - - - -Errors - - - - - - - - - - - - - - - - - - - -xbt_swag.sgml.sgml.sgml.sgml.sgml.sgml.sgml.sgml - - - - - - - - - - - - - - - - - - - -xbt_swag.sgml.sgml.sgml.sgml.sgml.sgml.sgml - - - - - - - - - - - - - - - - - - - -xbt_swag.sgml.sgml.sgml.sgml.sgml.sgml - - - - - - - - - - - - - - - - - - - -xbt_swag.sgml.sgml.sgml.sgml.sgml - - - - - - - - - - - - - - - - - - - -xbt_swag.sgml.sgml.sgml.sgml - - - - - - - - - - - - - - - - - - - -xbt_swag.sgml.sgml.sgml - - - - - - - - - - - - - - - - - - - -xbt_swag.sgml.sgml - - - - - - - - - - - - - - - - - - - -xbt_swag.sgml - - - - - - - - - - - - - -@c: -@f: - - - - - - -@c: -@f: -@a1: - - - - - - -@c: -@f: -@a1: -@a2: - - - - - - -@c: -@f: -@a1: -@a2: -@a3: - - - - - - -@c: -@f: -@a1: -@a2: -@a3: -@a4: - - - - - - -@c: -@f: -@a1: -@a2: -@a3: -@a4: -@a5: - - - - - - -@c: -@f: - - - - - - -@c: -@f: -@a1: - - - - - - -@c: -@f: -@a1: -@a2: - - - - - - -@c: -@f: -@a1: -@a2: -@a3: - - - - - - -@c: -@f: -@a1: -@a2: -@a3: -@a4: - - - - - - -@c: -@f: -@a1: -@a2: -@a3: -@a4: -@a5: - - - - - - -@c: -@f: - - - - - - -@c: -@f: -@a1: - - - - - - -@c: -@f: -@a1: -@a2: - - - - - - -@c: -@f: -@a1: -@a2: -@a3: - - - - - - -@c: -@f: -@a1: -@a2: -@a3: -@a4: - - - - - - -@c: -@f: -@a1: -@a2: -@a3: -@a4: -@a5: - - - - - - -@c: -@f: - - - - - - -@c: -@f: -@a1: - - - - - - -@c: -@f: -@a1: -@a2: - - - - - - -@c: -@f: -@a1: -@a2: -@a3: - - - - - - -@c: -@f: -@a1: -@a2: -@a3: -@a4: - - - - - - -@c: -@f: -@a1: -@a2: -@a3: -@a4: -@a5: - - - - - - -@c: -@p: -@f: - - - - - - -@c: -@p: -@f: -@a1: - - - - - - -@c: -@p: -@f: -@a1: -@a2: - - - - - - -@c: -@p: -@f: -@a1: -@a2: -@a3: - - - - - - -@c: -@p: -@f: -@a1: -@a2: -@a3: -@a4: - - - - - - -@c: -@p: -@f: -@a1: -@a2: -@a3: -@a4: -@a5: - - - - - - -@c: -@p: -@f: -@a1: -@a2: -@a3: -@a4: -@a5: -@a6: - - - - - - -@f: - - - - - - -@f: -@a1: - - - - - - -@f: -@a1: -@a2: - - - - - - -@f: -@a1: -@a2: -@a3: - - - - - - -@f: -@a1: -@a2: -@a3: -@a4: - - - - - - -@f: -@a1: -@a2: -@a3: -@a4: -@a5: - - - - - - -@c: -@f: -@a1: -@a2: -@a3: -@a4: -@a5: -@a6: - - - - - - -@addr: -@Param2: -@sock: -@timeOut: -@Returns: - - - - - - -@sock: -@waitForPeer: -@Returns: - - - - - - -@destination: -@source: -@description: -@length: -@sourceFormat: - - - - - - -@pid: -@parentToChild: -@childToParent: -@Returns: - - - - - - -@sock: -@Returns: - - - - - - -@description: -@length: -@format: -@Returns: - - - - - - -@CHAR_TYPE: -@DOUBLE_TYPE: -@FLOAT_TYPE: -@INT_TYPE: -@LONG_TYPE: -@SHORT_TYPE: -@UNSIGNED_INT_TYPE: -@UNSIGNED_LONG_TYPE: -@UNSIGNED_SHORT_TYPE: -@STRUCT_TYPE: -@LAST_TYPE: - - - - - - -@whatType: -@Returns: - - - - - - -@Returns: - - - - - - -@whatType: -@Returns: - - - - - - - - - - - - - - - - - - -@Param1: -@Param2: -@ear: -@earPort: -@Returns: - - - - - - -@HOST_FORMAT: -@NETWORK_FORMAT: - - - - - - -@cname: - - - - - - -@cname: - - - - - - -@catName: -@priority: - - - - - - - - - - - - -@catName: -@desc: - - - - - - -@cname: -@desc: - - - - - - -@cname: -@parent: -@desc: - - - - - - -@catName: -@parent: -@desc: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -@destination: -@source: -@whatType: -@repetitions: -@sourceFormat: - - - - - - -@whatType: -@repetitions: -@format: -@Returns: - - - - - - - - - - - - -@addr: -@Returns: - - - - - - -@addr: -@Returns: - - - - - - -@addr: -@Returns: - - - - - - -@addr: -@Returns: - - - - - - -@machineOrAddress: -@address: - - - - - - -@machineOrAddress: -@addressList: -@atMost: -@Returns: - - - - - - -@timeOut: -@sd: -@ldap: -@Returns: - - - - - - -@sd: -@Returns: - - - - - - -@sd: -@Returns: - - - - - - -@machineOrAddress: - - - - - - -@p: -@f: -@a1: -@a2: -@a3: -@a4: -@a5: -@a6: - - - - - - -@Returns: - - - - - - - - - - - - -@notifyFn: - - - - - - -@addr: -@Param2: -@sock: -@Returns: - - - - - - -@Param1: -@Param2: -@ear: -@earPort: -@Returns: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -@structType: -@lastMember: -@memberType: -@repetitions: - - - - - - -@sock: -@child: -@Returns: - - - - - - -@sd: -@Returns: - - - - - - -@sd: -@Returns: - - - - - - -@sd: -@Returns: - - - - - - -@destination: -@source: -@whatType: -@repetitions: -@format: - - - - - - -@type: -@repetitions: - - - - - - -@type: -@repetitions: -@offset: - - - - - - - - - - - - - - - - - - - - - - - - -@sig: - - - - - - -@Param1: - - - - - - -@sd: -@Returns: - - - - - - -@sd: -@Returns: - - - - - - - - - - - - -@f: -@a1: -@a2: -@a3: -@a4: -@a5: -@a6: - - - - - - -@sd: -@msgType: -@vdata: - - - - - - -@sock: -@Returns: - - - - - - -@dd1: -@c1: -@dd2: -@c2: -@Returns: -@description: - - - - - - -@description: -@Returns: - - - - - - -@sd: -@data: -@description: -@description_length: -@repetition: -@Returns: - - - - - - -@sd: -@data: -@description: -@description_length: -@repetition: -@Returns: - - - - - - -@description: -@ft: -@Returns: - - - - - - -@no_error: -@malloc_error: -@mismatch_error: -@sanity_error: -@system_error: -@network_error: -@timeout_error: -@thread_error: -@unknown_error: - - - - - - -@Returns: - - - - - - - - - - - - -@sd: -@size: - - - - - - -@id: -@Returns: - - - - - - - - - - - - -@msg: - - - - - - -@timeOut: - - - - - - -@msgId: -@dataSize: -@seqCount: -@Returns: - - - - - - -@msgId: -@free_data_on_free: -@seqCount: -@Varargs: -@Returns: - - - - - - -@msg: -@timeout: -@Returns: -@sd: - - - - - - -@message: -@name: -@sequence_count: -@Varargs: -@Returns: - - - - - - -@sd: -@message: -@sequence_count: -@Varargs: -@Returns: - - - - - - -@sd: -@timeout: -@message: -@sequence_count: -@Varargs: -@Returns: - - - - - - -@Returns: - - - - - - -@host: -@Param2: -@sock: -@Returns: - - - - - - -@Param1: -@Param2: -@sock: -@Returns: - - - - - - - - - - - - -@sd: -@Returns: - - - - - - -@sd: -@Returns: - - - - - - -@sd: -@data: -@description: -@Returns: - - - - - - -@message: -@TTL: -@cb: - - - - - - -@sd: -@data: -@description: -@Returns: - - - - - - -@Returns: - - - - - - - - - - - - -@type: - - - - - - -@ud: - - - - - - -@cfg: -@Returns: - - - - - - -@tocopy: -@whereto: -@Returns: - - - - - - -@name: -@indent: -@cfg: - - - - - - -@cfg: -@name: -@Returns: - - - - - - -@cfg: - - - - - - -@cfg: -@name: -@val: -@Returns: - - - - - - -@cfg: -@name: -@dynar: -@Returns: - - - - - - -@cfg: -@name: -@host: -@port: -@Returns: - - - - - - -@cfg: -@name: -@val: -@Returns: - - - - - - -@cfg: -@name: -@val: -@Returns: - - - - - - -@Returns: -@whereto: - - - - - - -@cfg: -@name: -@type: -@min: -@max: -@Returns: - - - - - - -@cfg: -@entry: -@Returns: - - - - - - -@cfg: -@name: -@val: -@Returns: - - - - - - -@cfg: -@name: -@host: -@port: -@Returns: - - - - - - -@cfg: -@name: -@val: -@Returns: - - - - - - -@cfg: -@name: -@val: -@Returns: - - - - - - -@cfg: -@Varargs: -@Returns: - - - - - - -@cfg: -@name: -@val: -@Returns: - - - - - - -@cfg: -@name: -@host: -@port: -@Returns: - - - - - - -@cfg: -@name: -@val: -@Returns: - - - - - - -@cfg: -@options: -@Returns: - - - - - - -@cfg: -@name: -@val: -@Returns: - - - - - - -@cfg: -@pa: -@Returns: - - - - - - -@type: -@post: - - - - - - -@type: -@pre: - - - - - - -@d1: -@d2: -@Returns: -@dd1: -@c1: -@dd2: -@c2: - - - - - - -@dd: -@c: -@data: - - - - - - -@name: -@elm_type: -@size: -@code: - - - - - - -@name: -@element_type: -@fixed_size: -@dynamic_size: -@post: -@code: -@Returns: - - - - - - -@name: -@element_type: -@dynamic_size: -@dst: -@Returns: -@elm_type: -@code: - - - - - - -@name: -@element_type: -@fixed_size: -@dst: -@Returns: - - - - - - -@name: -@referenced_type: -@dst: -@Returns: -@ref_type: -@code: - - - - - - -@name: -@referenced_type: -@discriminant: -@post: -@code: -@Returns: - - - - - - -@name: -@discriminant: -@code: - - - - - - -@name: -@discriminant: -@dst: -@Returns: - - - - - - -@name: -@dst: -@Returns: -@code: - - - - - - -@struct_code: -@field_name: -@field_type_code: - - - - - - -@struct_code: -@field_name: -@field_code: -@pre_cb: -@post_cb: -@Returns: - - - - - - -@struct_code: -@field_name: -@field_type_name: - - - - - - -@struct_code: -@field_name: -@field_type_name: -@pre_cb: -@post_cb: -@Returns: - - - - - - -@struct_type: -@name: -@field_type: -@Returns: - - - - - - -@struct_type: -@name: -@field_type_name: -@Returns: - - - - - - -@name: -@pre_cb: -@post_cb: -@code: -@Returns: - - - - - - -@struct_type: - - - - - - -@name: -@selector: -@dst: -@Returns: -@code: - - - - - - -@union_code: -@field_name: -@field_type_code: - - - - - - -@union_code: -@field_name: -@field_code: -@pre_cb: -@post_cb: -@Returns: - - - - - - -@union_code: -@field_name: -@field_type_name: - - - - - - -@union_code: -@field_name: -@field_type_name: -@pre_cb: -@post_cb: -@Returns: - - - - - - -@union_type: -@name: -@field_type: -@Returns: - - - - - - -@union_type: -@name: -@field_type_name: -@Returns: - - - - - - -@name: -@field_count: -@post: -@code: -@Returns: - - - - - - -@union_type: - - - - - - -@name: -@desc: -@howmany: -@code: -@Returns: -@dst: - - - - - - -@name: -@desc: -@howmany: -@dst: -@Returns: - - - - - - -@name: -@Cdefinition: -@dst: -@Returns: -@code: -@def: - - - - - - -@ps: - - - - - - -@ps: - - - - - - -@ps: -@name: -@ddt: - - - - - - -@ps: -@name: -@ddt: - - - - - - -@ps: -@name: -@data: -@ddt: - - - - - - -@ps: -@name: -@data: -@ddt: - - - - - - -@type: - - - - - - -@code: -@type: -@Returns: - - - - - - -@name: -@type: -@Returns: - - - - - - -@name: -@element_type: -@fixed_size: -@dynamic_size: -@post: -@dst: -@Returns: - - - - - - -@name: -@desc: -@howmany: -@dst: -@Returns: - - - - - - -@name: -@default_value: -@free_func: -@size: -@alignment: -@post: -@dst: -@Returns: - - - - - - -@name: -@C_definition: -@dst: -@Returns: - - - - - - -@name: -@referenced_type: -@discriminant: -@post: -@dst: -@Returns: - - - - - - -@name: -@type: -@Returns: - - - - - - -@name: -@pre: -@post: -@dst: -@Returns: - - - - - - -@struct_type: -@name: -@field_type: -@pre: -@post: -@Returns: - - - - - - -@name: -@field_count: -@post: -@dst: -@Returns: - - - - - - -@union_type: -@name: -@field_type: -@pre: -@post: -@Returns: - - - - - - -@type: -@Returns: - - - - - - -@cursor: -@Returns: - - - - - - -@cursor: -@data: -@Returns: - - - - - - -@cursor: -@key: -@Returns: - - - - - - -@head: -@Returns: -@cursor: - - - - - - -@cursor: -@Returns: - - - - - - -@cursor: -@Returns: - - - - - - -@head: -@output: -@Returns: - - - - - - -@dict: -@cursor: -@key: -@data: - - - - - - -@dict: -@Returns: - - - - - - -@head: -@key: -@data: -@Returns: - - - - - - -@head: -@key: -@key_len: -@data: -@Returns: - - - - - - -@head: -@key: -@data: -@free_ctn: -@Returns: - - - - - - -@head: -@key: -@key_len: -@data: -@free_ctn: -@Returns: - - - - - - -@Returns: -@dict: - - - - - - -@data: - - - - - - -@data: - - - - - - -@head: -@key: -@Returns: - - - - - - -@head: -@key: -@key_len: -@Returns: - - - - - - -@head: -@key: -@data: -@Returns: - - - - - - -@head: -@key: -@key_len: -@data: -@Returns: - - - - - - -@head: -@key: -@data: -@free_ctn: -@Returns: - - - - - - -@head: -@key: -@key_len: -@data: -@free_ctn: -@Returns: - - - - - - -@dynar: -@cursor: - - - - - - -@dynar: -@cursor: -@whereto: -@Returns: - - - - - - -@dynar: -@cursor: - - - - - - -@dynar: -@cursor: - - - - - - -@dynar: -@cursor: -@Returns: - - - - - - -@_dynar: -@_cursor: -@_data: -@_whereto: - - - - - - -@dynar: -@Returns: - - - - - - -@dynar: -@Returns: - - - - - - -@dynar: -@idx: -@dst: -@whereto: -@Returns: - - - - - - -@dynar: -@idx: -@src: -@Returns: -@object: - - - - - - -@dynar: -@Returns: - - - - - - -@dynar: -@operator: -@Returns: - - - - - - -@Param1: -@free_func: -@Returns: -@whereto: -@elm_size: - - - - - - -@dynar: -@cursor: -@whereto: -@Returns: - - - - - - -@dynar: -@dst: -@whereto: - - - - - - -@dynar: -@src: -@Returns: -@object: - - - - - - -@dynar: -@idx: -@object: -@Returns: - - - - - - -@dynar: -@idx: -@object: -@Returns: - - - - - - -@dynar: -@Returns: - - - - - - -@dynar: -@idx: -@src: -@Returns: -@object: - - - - - - -@dynar: -@dst: -@whereto: -@Returns: - - - - - - -@dynar: -@src: -@Returns: -@object: - - - - - - -@no_error: no error -@mismatch_error: Not found -@system_error: a syscall did fail -@network_error: error while sending/receiving data -@timeout_error: not quick enough, dude -@thread_error: error while [un]locking -@unknown_error: no idea - - - - - - -@Returns: - - - - - - -@cat: -@app: - - - - - - -@cs: -@Returns: - - - - - - - - - - - - -@cat: -@parent: - - - - - - -@gras_log_priority_none: -@gras_log_priority_trace: -@gras_log_priority_debug: -@gras_log_priority_verbose: -@gras_log_priority_info: -@gras_log_priority_warning: -@gras_log_priority_error: -@gras_log_priority_critical: -@gras_log_priority_infinite: -@gras_log_priority_uninitialized: - - - - - - -@cat: -@thresholdPriority: - - - - - - -@sd: -@size: - - - - - - -@msg: - - - - - - -@msgId: -@free_data_on_free: -@seqCount: -@Varargs: -@Returns: - - - - - - -@msgId: -@name: -@sequence_count: -@Varargs: -@Returns: - - - - - - -@set: -@elm: -@free_func: -@Returns: - - - - - - -@set: -@cursor: -@elm: - - - - - - -@set: - - - - - - -@set: -@id: -@dst: -@Returns: - - - - - - -@set: -@key: -@dst: -@Returns: - - - - - - -@set: -@name: -@name_len: -@dst: -@Returns: - - - - - - -@Returns: -@dst: - - - - - - -@Param1: -@Param2: - - - - - - -@host: -@Param2: -@sock: -@Returns: - - - - - - -@sock: -@Returns: - - - - - - -@sd: -@Returns: - - - - - - -@sd: -@Returns: - - - - - - -@Param1: -@Param2: -@sock: -@Returns: - - - - - - -@Returns: - - - - - - -@Returns: - - - - - - -@no_error: -@mismatch_error: -@system_error: -@network_error: -@timeout_error: -@thread_error: -@unknown_error: -@remote_mismatch_error: -@remote_system_error: -@remote_network_error: -@remote_timeout_error: -@remote_thread_error: -@remote_unknown_error: - diff --git a/cruft/doc/tmpl/gras.sgml b/cruft/doc/tmpl/gras.sgml deleted file mode 100644 index 3312fb1f2b..0000000000 --- a/cruft/doc/tmpl/gras.sgml +++ /dev/null @@ -1,221 +0,0 @@ - -gras - - - - - - - - - - - - - - - - - - - -@CHAR_TYPE: -@DOUBLE_TYPE: -@FLOAT_TYPE: -@INT_TYPE: -@LONG_TYPE: -@SHORT_TYPE: -@UNSIGNED_INT_TYPE: -@UNSIGNED_LONG_TYPE: -@UNSIGNED_SHORT_TYPE: -@STRUCT_TYPE: -@LAST_TYPE: - - - - - - -@type: -@repetitions: - - - - - - - -@type: -@repetitions: -@offset: - - - - - - - -@structType: -@lastMember: -@memberType: -@repetitions: - - - - - - - - - - - - - - -@host: -@Param2: -@sock: -@Returns: - - - - - - - -@Param1: -@Param2: -@sock: -@Returns: - - - - - - - -@sock: -@Returns: - - - - - - - -@sd: -@Returns: - - - - - - - -@sd: -@Returns: - - - - - - - -@Returns: - - - - - - - - - - - - - -@message: -@name: -@sequence_count: -@Varargs: -@Returns: - - - - - - - -@sd: -@msgType: -@vdata: - - - - - - - -@message: -@TTL: -@cb: - - - - - - - -@timeOut: - - - - - - - -@sd: -@message: -@sequence_count: -@Varargs: -@Returns: - - - - - - - -@sd: -@timeout: -@message: -@sequence_count: -@Varargs: -@Returns: - - - - - - - - - - - - - - -@ud: - - - - - - - -@type: - - diff --git a/cruft/doc/tmpl/gras_private.sgml b/cruft/doc/tmpl/gras_private.sgml deleted file mode 100644 index 0fe64db20b..0000000000 --- a/cruft/doc/tmpl/gras_private.sgml +++ /dev/null @@ -1,32 +0,0 @@ - -gras_private - - - - - - - - - - - - - - - - - - - -@sd: -@size: - - - - - - - - - diff --git a/cruft/doc/tmpl/gras_rl.sgml b/cruft/doc/tmpl/gras_rl.sgml deleted file mode 100644 index 5e633a53a3..0000000000 --- a/cruft/doc/tmpl/gras_rl.sgml +++ /dev/null @@ -1,89 +0,0 @@ - -RL - - -Implementation of GRAS suited for real life. - - - - - - - - - - - - - - - - -@destination: -@source: -@description: -@length: -@sourceFormat: - - - - - - - -@whatType: -@Returns: - - - - - - - -@Returns: - - - - - - - -@whatType: -@Returns: - - - - - - - -@destination: -@source: -@whatType: -@repetitions: -@sourceFormat: - - - - - - - -@whatType: -@repetitions: -@format: -@Returns: - - - - - - - -@destination: -@source: -@whatType: -@repetitions: -@format: - - diff --git a/cruft/doc/tmpl/gras_sg.sgml b/cruft/doc/tmpl/gras_sg.sgml deleted file mode 100644 index 925dc0bd64..0000000000 --- a/cruft/doc/tmpl/gras_sg.sgml +++ /dev/null @@ -1,75 +0,0 @@ - -SG - - -Implementation of GRAS on top of the simulator. - - - - SimGrid was designed to ease the comparison of algorithms and - heuristics. That way, a lot of complicated notion from the system layer - were volontary left off. For example, migrating a process from an host to - another is as easy as: MSG_process_change_host(process, new_host). - - - - No need to tell that performing this operation on real platform is really - harder. This simplification is a very good thing when you want to rapidly - prototype code, but makes things somehow more complicated in GRAS since - we want to have a realistic API, since it have to be implemented in - reality also. - - - - The best example of complexity in GRAS_SG induced by simplicity in - SimGrid is the sockets handling. There is no "socket" in SG, but only - m_channel_t. In contrary to sockets from RL, no special treatment is - needed for a process before writing or reading on/from a channel. So, a - given channel can be pooled by more than one process. Likewise, you can - send data to a channel that nobody is actually listening to. - - - - The SG implementation of GRAS repport as an error the fact that nobody is - listening to the socket when trying to open a socket, or send stuff using - a previously openned socket. That way, the SG version can be used to - debug all syncronization issues. For that, we store mainly the PID of - both the sender and the receiver in the socket structure, and then - resolve PID->process at the lastest moment. This search is a bit - expensive, but as long as there is no real garbage collection in SG, with - the information "dead process" within the structure, it's the only - solution to make sure that we won't dereference pointers to an old freed - structure when the process on the other side of the structure did finish - since the creation of the socket. - - - - As said in the overview, the processes can declare to hear on several - sockets, but all incoming messages are handled by the same loop. So, we - can use only one channel per process, and use a table on each host to - determine to which process a message should be delivered depending on the - socket number provided by the sender. - - - - -RL, the implementation suited for real life. - - - - diff --git a/cruft/doc/tmpl/nws_comm.sgml b/cruft/doc/tmpl/nws_comm.sgml deleted file mode 100644 index 88570e2037..0000000000 --- a/cruft/doc/tmpl/nws_comm.sgml +++ /dev/null @@ -1,85 +0,0 @@ - -nws_comm - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -@CHAR_TYPE: -@DOUBLE_TYPE: -@FLOAT_TYPE: -@INT_TYPE: -@LONG_TYPE: -@SHORT_TYPE: -@UNSIGNED_INT_TYPE: -@UNSIGNED_LONG_TYPE: -@UNSIGNED_SHORT_TYPE: -@STRUCT_TYPE: -@LAST_TYPE: - - - - - - -@HOST_FORMAT: -@NETWORK_FORMAT: - - - - - - -@type: -@repetitions: - - - - - - - -@type: -@repetitions: -@offset: - - - - - - - -@structType: -@lastMember: -@memberType: -@repetitions: - - diff --git a/cruft/doc/tmpl/surf_maxmin.sgml b/cruft/doc/tmpl/surf_maxmin.sgml deleted file mode 100644 index 11c193cccb..0000000000 --- a/cruft/doc/tmpl/surf_maxmin.sgml +++ /dev/null @@ -1,211 +0,0 @@ - -Max-min linear solver - - -A linear program solver where the constraints are positive and the -objective function is max-min. - - - - - - - - - - - - - - - - -@Returns: - - - - - - - -@sys: - - - - - - - -@sys: -@var: - - - - - - - -@sys: -@id: -@bound_value: -@Returns: - - - - - - - -@sys: -@cnst: - - - - - - - -@sys: -@id: -@weight_value: -@bound: -@number_of_constraints: -@Returns: - - - - - - - -@sys: -@var: - - - - - - - -@var: -@Returns: - - - - - - - -@sys: -@cnst: -@var: -@value: - - - - - - - -@sys: -@var: -@num: -@Returns: - - - - - - - -@sys: -@var: -@Returns: - - - - - - - -@sys: -@cnst: -@var: -@Returns: - - - - - - - -@cnst: - - - - - - - -@var: - - - - - - - -@sys: -@cnst: -@var: -@value: - - - - - - - -@sys: -@var: -@bound: - - - - - - - -@sys: -@var: -@weight: - - - - - - - -@sys: -@cnst: -@bound: - - - - - - - -@sys: -@cnst: -@Returns: - - - - - - - -@sys: - - diff --git a/cruft/doc/tmpl/virtu_fs.sgml b/cruft/doc/tmpl/virtu_fs.sgml deleted file mode 100644 index 487323256e..0000000000 --- a/cruft/doc/tmpl/virtu_fs.sgml +++ /dev/null @@ -1,16 +0,0 @@ - -File System - - -File system abstraction layer (TODO) - - - -This module is only planned for now. - - - - - - - diff --git a/cruft/doc/tmpl/virtu_globals.sgml b/cruft/doc/tmpl/virtu_globals.sgml deleted file mode 100644 index 1a63025bfc..0000000000 --- a/cruft/doc/tmpl/virtu_globals.sgml +++ /dev/null @@ -1,43 +0,0 @@ - -Globals - - -Handling global variables so that it works on simulator - - -In GRAS, using globals is forbidden since the daemons will -sometimes run as a thread inside the same process. So, you have to put -all globals in a structure, and tell GRAS that it's your globals. - -Use the grasUserdataNew() macro to create a new user data (or malloc it -yourself and use grasUserdataSet yourself), and grasUserdataGet() to -retrive a reference to it. - - - - - - - - - - - - - - - - - - -@ud: - - - - - - - -@type: - - diff --git a/cruft/doc/tmpl/virtu_syscall.sgml b/cruft/doc/tmpl/virtu_syscall.sgml deleted file mode 100644 index 03f4b4aec2..0000000000 --- a/cruft/doc/tmpl/virtu_syscall.sgml +++ /dev/null @@ -1,33 +0,0 @@ - -System Calls - - -System call abstraction layer. - - - - - - - - - - - - - - - - -@Returns: - - - - - - - -@Param1: -@Param2: - - diff --git a/cruft/doc/tmpl/xbt_config.sgml b/cruft/doc/tmpl/xbt_config.sgml deleted file mode 100644 index c7f6f0addb..0000000000 --- a/cruft/doc/tmpl/xbt_config.sgml +++ /dev/null @@ -1,268 +0,0 @@ - -Config - - -Configuration facilities. - - - - - - - - - - - - - - - - -@Returns: - - - - - - - -@tocopy: -@whereto: - - - - - - - -@cfg: - - - - - - - -@name: -@indent: -@cfg: - - - - - - - -@cfg: -@name: -@type: -@min: -@max: - - - - - - - -@cfg: -@entry: -@Returns: - - - - - - - -@cfg: -@Returns: - - - - - - - -@cfg: -@options: -@Returns: - - - - - - - -@cfg: -@Varargs: -@Returns: - - - - - - - -@cfg: -@pa: -@Returns: - - - - - - - -@cfg: -@name: -@val: -@Returns: - - - - - - - -@cfg: -@name: -@val: -@Returns: - - - - - - - -@cfg: -@name: -@val: -@Returns: - - - - - - - -@cfg: -@name: -@host: -@port: -@Returns: - - - - - - - -@cfg: -@name: -@val: -@Returns: - - - - - - - -@cfg: -@name: -@val: -@Returns: - - - - - - - -@cfg: -@name: -@val: -@Returns: - - - - - - - -@cfg: -@name: -@host: -@port: -@Returns: - - - - - - - -@cfg: -@name: -@Returns: - - - - - - - -@cfg: -@name: -@val: -@Returns: - - - - - - - -@cfg: -@name: -@val: -@Returns: - - - - - - - -@cfg: -@name: -@val: -@Returns: - - - - - - - -@cfg: -@name: -@host: -@port: -@Returns: - - - - - - - -@cfg: -@name: -@dynar: -@Returns: - - diff --git a/cruft/doc/tmpl/xbt_dico.sgml b/cruft/doc/tmpl/xbt_dico.sgml deleted file mode 100644 index 552b162e4a..0000000000 --- a/cruft/doc/tmpl/xbt_dico.sgml +++ /dev/null @@ -1,180 +0,0 @@ - -xbt_dico - - - - - - - - - - - - - - - - - - - -@Returns: - - - - - - - -@dict: - - - - - - - -@head: -@key: -@data: -@free_ctn: - - - - - - - -@head: -@key: -@key_len: -@data: -@free_ctn: - - - - - - - -@head: -@key: -@data: -@Returns: - - - - - - - -@head: -@key: -@key_len: -@data: -@Returns: - - - - - - - -@head: -@key: -@Returns: - - - - - - - -@head: -@key: -@key_len: -@Returns: - - - - - - - -@head: -@output: - - - - - - - -@data: - - - - - - - -@data: - - - - - - - -@cursor: -@data: -@Returns: - - - - - - - -@cursor: -@key: -@Returns: - - - - - - - -@dict: -@cursor: -@key: -@data: - - - - - - - -@head: -@Returns: - - - - - - - -@cursor: - - - - - - - -@cursor: - - diff --git a/cruft/doc/tmpl/xbt_dict.sgml b/cruft/doc/tmpl/xbt_dict.sgml deleted file mode 100644 index d5217fc480..0000000000 --- a/cruft/doc/tmpl/xbt_dict.sgml +++ /dev/null @@ -1,180 +0,0 @@ - -Dictionaries - - -Data container associating data to a string key. - - - - - - - - - - - - - - - - -@Returns: - - - - - - - -@dict: - - - - - - - -@head: -@key: -@data: -@free_ctn: - - - - - - - -@head: -@key: -@key_len: -@data: -@free_ctn: - - - - - - - -@head: -@key: -@data: -@Returns: - - - - - - - -@head: -@key: -@key_len: -@data: -@Returns: - - - - - - - -@head: -@key: -@Returns: - - - - - - - -@head: -@key: -@key_len: -@Returns: - - - - - - - -@head: -@output: - - - - - - - -@data: - - - - - - - -@data: - - - - - - - -@cursor: -@data: -@Returns: - - - - - - - -@cursor: -@key: -@Returns: - - - - - - - -@dict: -@cursor: -@key: -@data: - - - - - - - -@head: -@Returns: - - - - - - - -@cursor: - - - - - - - -@cursor: - - diff --git a/cruft/doc/tmpl/xbt_dynar.sgml b/cruft/doc/tmpl/xbt_dynar.sgml deleted file mode 100644 index fb88956c5d..0000000000 --- a/cruft/doc/tmpl/xbt_dynar.sgml +++ /dev/null @@ -1,192 +0,0 @@ - -Dynamic array - - -Use arrays, forget about malloc - - - -This module provide the quite usual dynamic array facility. - - - - - - - - - - - - -@Param1: -@free_func: -@Returns: - - - - - - - -@dynar: - - - - - - - -@dynar: - - - - - - - -@dynar: -@Returns: - - - - - - - -@dynar: - - - - - - - -@dynar: -@idx: -@src: - - - - - - - -@dynar: -@idx: -@object: - - - - - - - -@dynar: -@idx: -@src: - - - - - - - -@dynar: -@idx: -@object: - - - - - - - -@dynar: -@operator: - - - - - - - -@dynar: -@src: - - - - - - - -@dynar: -@dst: - - - - - - - -@dynar: -@dst: - - - - - - - -@dynar: -@src: - - - - - - - -@_dynar: -@_cursor: -@_data: - - - - - - - -@dynar: -@cursor: - - - - - - - -@dynar: -@cursor: - - - - - - - -@dynar: -@cursor: -@whereto: -@Returns: - - - - - - - -@dynar: -@cursor: - - diff --git a/cruft/doc/tmpl/xbt_error.sgml b/cruft/doc/tmpl/xbt_error.sgml deleted file mode 100644 index e283b6a340..0000000000 --- a/cruft/doc/tmpl/xbt_error.sgml +++ /dev/null @@ -1,16 +0,0 @@ - -Errors handling - - -Error reporting - - - - - - - - - - - diff --git a/cruft/doc/tmpl/xbt_heap.sgml b/cruft/doc/tmpl/xbt_heap.sgml deleted file mode 100644 index f34856d305..0000000000 --- a/cruft/doc/tmpl/xbt_heap.sgml +++ /dev/null @@ -1,78 +0,0 @@ - -Heap - - -A simple heap with O(log(n)) access. - - - - - - - - - - - - - - - - -@num: -@free_func: -@Returns: - - - - - - - -@H: - - - - - - - -@H: -@Returns: - - - - - - - -@H: -@content: -@key: - - - - - - - -@H: - - - - - - - -@H: -@Returns: - - - - - - - -@H: - - diff --git a/cruft/doc/tmpl/xbt_log.sgml b/cruft/doc/tmpl/xbt_log.sgml deleted file mode 100644 index 09091fc996..0000000000 --- a/cruft/doc/tmpl/xbt_log.sgml +++ /dev/null @@ -1,559 +0,0 @@ - -Logging facilities - - -An easy-to-use, fast and flexible message logging architecture. - - - - This is an adaptation of the log4c project, which is dead upstream, and which - I was given the permission to fork under the LGPL licence by the authors. log4c - itself was loosely based on the Apache project's Log4J, Log4CC, - etc. project. Because C is not object oriented, a lot had to change. - - - - Overview - - - There is 3 main concepts: category, priority and appender. These three - concepts work together to enable developers to log messages according to - message type and priority, and to control at runtime how these messages are - formatted and where they are reported. - - - - - Category hierarchy - - - The first and foremost advantage of any logging API over plain printf() - resides in its ability to disable certain log statements while allowing - others to print unhindered. This capability assumes that the logging space, - that is, the space of all possible logging statements, is categorized - according to some developer-chosen criteria. - - - - This observation led to choosing category as the central concept of the - system. Every category is declared by providing a name and an optional - parent. If no parent is explicitly named, the root category, LOG_ROOT_CAT - is the category's parent. - - - - A category is created by a macro call at the top level of a file. A - category can be created with any one of the following macros: - - - - - @GRAS_LOG_NEW_CATEGORY(MyCat); - create a new root - - - - @GRAS_LOG_NEW_SUBCATEGORY(MyCat, ParentCat); - Create a new category being child of the category ParentCat - - - - @GRAS_LOG_NEW_DEFAULT_CATEGORY(MyCat); - Like GRAS_LOG_NEW_CATEGORY, but the new category is the default one - in this file - - - - @GRAS_LOG_NEW_DEFAULT_SUBCATEGORY(MyCat, ParentCat); - Like GRAS_LOG_NEW_SUBCATEGORY, but the new category is the default one - in this file - - - - - The parent cat can be defined in the same file or in another file, but each - category may have only one definition. - - - - Typically, there will be a Category for each module and sub-module, so you - can independently control logging for each module. - - - - - Priority - - - A category may be assigned a threshold priorty. The set of priorites are - defined by the @gras_log_priority_t enum. Their values are DEBUG, VERBOSE, - INFO, WARNING, ERROR and CRITICAL. - - - - If a given category is not assigned a threshold priority, then it inherits - one from its closest ancestor with an assigned threshold. - - - - To ensure that all categories can eventually inherit a threshold, the root - category always has an assigned threshold priority. - - - - Logging requests are made by invoking a logging macro on a category. All - of the macros have a printf-style format string followed by arguments. - Because most C compilers do not support vararg macros, there is a version - of the macro for any number of arguments from 0 to 6. The macro name ends - with the total number of arguments. - - - - Here is an example of the most basic type of macro: - - - CLOG5(MyCat, gras_log_priority_warning, "Values are: %d and '%s'", 5, "oops"); - - This is a logging request with priority WARN. - - - A logging request is said to be enabled if its priority is higher than or - equal to the threshold priority of its category. Otherwise, the request is - said to be disabled. A category without an assigned priority will inherit - one from the hierarchy. - - - - It is possible to use any non-negative integer as a priority. If, as in the - example, one of the standard priorites is used, then there is a convenience - macro that is typically used instead. For example, the above example is - equivalent to the shorter: - - - CWARN4(MyCat, "Values are: %d and '%s'", 5, "oops"); - - - - Default category - - - If @GRAS_LOG_NEW_DEFAULT_SUBCATEGORY(MyCat, Parent) or - @GRAS_LOG_NEW_DEFAULT_CATEGORY(MyCat) is used to create the category, then - the even shorter form can be used: - - - WARN3("Values are: %d and '%s'", 5, "oops"); - - - Only one default category can be created per file, though multiple - non-defaults can be created and used. - - - - - Example - - Here is a more complete example: - - - #include "gras.h" - - /* create a category and a default subcategory */ - GRAS_LOG_NEW_CATEGORY(VSS); - GRAS_LOG_NEW_DEFAULT_SUBCATEGORY(SA, VSS); - - main() { - /* Now set the parent's priority. - (the string would typcially be a runtime option) */ - gras_log_control_set("SA.thresh=3"); - - /* This request is enabled, because WARNING >= INFO. */ - CWARN2(VSS, "Low fuel level."); - - /* This request is disabled, because DEBUG < INFO. */ - CDEBUG2(VSS, "Starting search for nearest gas station."); - - /* The default category SA inherits its priority from VSS. Thus, - the following request is enabled because INFO >= INFO. */ - INFO1("Located nearest gas station."); - - /* This request is disabled, because DEBUG < INFO. */ - DEBUG1("Exiting gas station search"); - } - - - - Configuration - - - Configuration is typically done during program initialization by invoking - the gras_log_control_set() method. The control string passed to it - typically comes from the command line. Look at the doucmentation for that - function for the format of the control string. - - - - - Performance - - - Clever design insures efficiency. Except for the first invocation, a - disabled logging request requires an a single comparison of a static - variable to a constant. - - - - There is also compile time constant, @GRAS_LOG_STATIC_THRESHOLD, which - causes all logging requests with a lower priority to be optimized to 0 cost - by the compiler. By setting it to gras_log_priority_infinite, all logging - requests are statically disabled and cost nothing. Released executables - might typically be compiled with - "-DGRAS_LOG_STATIC_THRESHOLD=gras_log_priority_infinite". - - - - - Appenders - - - Each category has an optional appender. An appender is a pointer to a - structure whcih starts with a pointer to a doAppend() function. DoAppend() - prints a message to a log. - - - - WHen a category is passed a message by one of the logging macros, the - category performs the following actions: - - - - - - if the category has an appender, the message is passed to the - appender's doAppend() function, - - - - - - if 'willLogToParent' is true for the category, the message is passed - to the category's parent. - - - - By default, all categories except root have no appender and - 'willLogToParent' is true. This situation causes all messages to be - logged by the root category's appender. - - - - Typically, you would only change the root category's appender when you - wanted, say, a different output format. Copying defaultLogAppender.c - would be a good start. - - - - The default appender function currently prints to stderr, but more - would be needed, like the one able to send the logs to a remote - dedicated server. - - - - - - - Misc and Caveats - - - Do not use any of the macros that start with '_'. - - - - The current set of macros force each file to use categories declared in - that file. This is intentional. Make the category a child of the file's - module category. - - - - Log4J has a 'rolling file appender' which you can select with a run-time - option and specify the max file size. This would be a nice default for - non-kernel applications. - - - - Careful, category names are global variables. - - - - - - - - - - - - - -@cs: - - - - - - - -@catName: -@desc: - - - - - - - -@catName: -@parent: -@desc: - - - - - - - -@cname: -@desc: - - - - - - - -@cname: -@parent: -@desc: - - - - - - - -@cname: - - - - - - - -@cname: - - - - - - - -@catName: -@priority: - - - - - - - - - - - - - - -@cat: -@app: - - - - - - - - - - - - - -@c: -@f: -@a1: -@a2: -@a3: -@a4: -@a5: -@a6: - - - - - - - -@c: -@f: -@a1: -@a2: -@a3: -@a4: -@a5: -@a6: - - - - - - - -@c: -@f: -@a1: -@a2: -@a3: -@a4: -@a5: -@a6: - - - - - - - -@c: -@f: -@a1: -@a2: -@a3: -@a4: -@a5: -@a6: - - - - - - - -@c: -@f: -@a1: -@a2: -@a3: -@a4: -@a5: -@a6: - - - - - - - -@c: -@f: -@a1: -@a2: -@a3: -@a4: -@a5: -@a6: - - - - - - - -@f: -@a1: -@a2: -@a3: -@a4: -@a5: -@a6: - - - - - - - -@f: -@a1: -@a2: -@a3: -@a4: -@a5: -@a6: - - - - - - - -@f: -@a1: -@a2: -@a3: -@a4: -@a5: -@a6: - - - - - - - -@f: -@a1: -@a2: -@a3: -@a4: -@a5: -@a6: - - - - - - - -@f: -@a1: -@a2: -@a3: -@a4: -@a5: -@a6: - - - - - - - -@f: -@a1: -@a2: -@a3: -@a4: -@a5: -@a6: - - diff --git a/cruft/doc/tmpl/xbt_set.sgml b/cruft/doc/tmpl/xbt_set.sgml deleted file mode 100644 index a7737fb243..0000000000 --- a/cruft/doc/tmpl/xbt_set.sgml +++ /dev/null @@ -1,86 +0,0 @@ - -Data set based on dictionnaries - - -Data storage for very quick retrieve - - - - - - - - - - - - - - - - -@Returns: - - - - - - - -@set: - - - - - - - -@set: -@elm: -@free_func: - - - - - - - -@set: -@key: -@dst: -@Returns: - - - - - - - -@set: -@name: -@name_len: -@dst: -@Returns: - - - - - - - -@set: -@id: -@dst: -@Returns: - - - - - - - -@set: -@cursor: -@elm: - - diff --git a/cruft/doc/tmpl/xbt_swag.sgml b/cruft/doc/tmpl/xbt_swag.sgml deleted file mode 100644 index 2119f6dc28..0000000000 --- a/cruft/doc/tmpl/xbt_swag.sgml +++ /dev/null @@ -1,117 +0,0 @@ - -Swag - - -valuable goods : a O(1) set based on linked lists - - - -Warning, this module is done to be efficient and performs tons of cast -and dirty things. So avoid using it unless you really know what you -are doing. - - - - - - - - - - - - -@offset: -@Returns: - - - - - - - -@swag: - - - - - - - -@swag: -@offset: - - - - - - - -@obj: -@swag: - - - - - - - -@obj: -@swag: - - - - - - - -@swag: - - - - - - - -@swag: -@Returns: - - - - - - - -@obj: -@swag: -@Returns: - - - - - - - -@obj: -@swag: - - - - - - - -@obj: -@obj_next: -@swag: - - - - - - - -@var: -@field: - -