release prep: clean-up obsolete information
This commit is contained in:
parent
888099466f
commit
2cfc7030c0
13 changed files with 52 additions and 133 deletions
|
|
@ -1,60 +0,0 @@
|
|||
|
||||
NoBug debugging flags hierachy
|
||||
==============================
|
||||
|
||||
NoBug logging is controlled by flags which can be configured with the
|
||||
NOBUG_LOG environment variable. This flags can be hierachically
|
||||
organized.
|
||||
|
||||
The documentation about this hierachy is maintained here:
|
||||
|
||||
(PLANNED, not all are implemented yet)
|
||||
|
||||
all # global logging
|
||||
lumiera # standard
|
||||
library # all support library
|
||||
plugin # plugin loader
|
||||
backend # all backend
|
||||
file_all # filehandling subsystem
|
||||
file # file access
|
||||
filedescriptor # internal filedescriptors
|
||||
filehandle # posix filehandles
|
||||
filehandlecache # mrucache for filehandles
|
||||
mmap_all # file mapping subsystem
|
||||
mmap # mmap objects
|
||||
mmapings # mmap range containers
|
||||
mmapcache # mmap range containers
|
||||
cache_all # caching subsystem
|
||||
scheduler_all # all scheduler
|
||||
threads # threadpool management
|
||||
tasks # work requests
|
||||
hard # high priority queue
|
||||
idle # low priority queue
|
||||
proc # all proc
|
||||
gui # all gui
|
||||
detail # highly expensive logging
|
||||
profiler # performance stats
|
||||
|
||||
event # controling events
|
||||
ui # by user interface
|
||||
script # by script
|
||||
|
||||
Explanation
|
||||
-----------
|
||||
|
||||
We have 2 main log flag hierachies, 'all' and 'event'.
|
||||
* 'all' reflects the application progress and will be used for
|
||||
debugging the application by the programmers. This is exposed in 2
|
||||
subgroups: 'lumiera' which is used for normal application logging
|
||||
and, 'detail' which contains logging which might be time critical,
|
||||
expensive or of very high volume.
|
||||
* 'event' logs user actions like GUI clicking, menu selections giving
|
||||
an idea how a bug was triggered.
|
||||
|
||||
Later on this main hierachies will run in different ringbuffers.
|
||||
|
||||
In Short
|
||||
--------
|
||||
|
||||
use NOBUG_LOG=lumiera
|
||||
|
||||
|
|
@ -24,6 +24,7 @@ t;h=74471e255e6ebfedb642e450bdfd3f79e346c600;hb=backend[NoBug_flags]
|
|||
I've added the things I planning for the backend, others might add their own
|
||||
plans there too. So far this is an early draft, comments welcome.
|
||||
|
||||
NOTE: outdated information. Have a look at `include/logging.h`
|
||||
|
||||
Tasks
|
||||
~~~~~
|
||||
|
|
@ -43,12 +44,23 @@ Rationale
|
|||
We need some easy way to control logging, later on when lumiera runs in beta
|
||||
tests it must be easy to tell a tester how to create useable debugging logs.
|
||||
|
||||
|
||||
Comments
|
||||
--------
|
||||
//comments: append below
|
||||
|
||||
cehteh will care for further integration
|
||||
-- link:ct[] [[DateTime(2008-07-26T09:11:29Z)]]
|
||||
|
||||
|
||||
ct:: '2008-07-26T09:11:29Z'
|
||||
|
||||
The basic idea is still valid, but information in this RfC is quite outdated.
|
||||
Meanwhile, we have a somewhat different and largely extended log hierarchy.
|
||||
And it turned out, that it isn't practical to scatter the NOBUG_FLAG_PARENT
|
||||
definitions all over the code base. Rather, we use a single include file
|
||||
`include/logging.h` to define all flags in a systematic way
|
||||
|
||||
Ichthyostega:: 'Di 29 Okt 2013 05:52:34 CET' ~<prg@ichthyostega.de>~
|
||||
|
||||
|
||||
//endof_comments:
|
||||
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]
|
||||
|
|
|
|||
|
|
@ -1,8 +1,16 @@
|
|||
The incomplete Guide to Lumiera Configuration
|
||||
==============================================
|
||||
=============================================
|
||||
:author: ct
|
||||
:date: 8/2008
|
||||
|
||||
DONT EDIT THE CONFIG IF YOU DONT KNOW WHAT YOU ARE DOING!
|
||||
Misconfiguration will break Lumiera and may destroy all your data!
|
||||
WARNING: this is a draft from the early days of Lumiera +
|
||||
IMHO, the whole topic ``Configuration'' requires further
|
||||
discussion and design.
|
||||
+
|
||||
-- -- Ichthyo
|
||||
|
||||
'''''''''''''
|
||||
'''''''''''''
|
||||
|
||||
Order is roughly alphabetically, depending on the mood of the writer.
|
||||
Defaults are noted if present. Not all are implemented yet.
|
||||
|
|
@ -10,22 +10,22 @@ it seems natural to care for the debian packaging of Lumiera ourselves. Moreover
|
|||
Debian/Stable to be our *reference platform* -- we'll provide any additionally required, more recent
|
||||
packages through our own link:http://Lumiera.org/debian[Debian Apt-Repository] (Debian depot).
|
||||
|
||||
TIP: readers new to debian packages may want to have a look into our
|
||||
TIP: readers new to Debian packages may want to have a look into our
|
||||
link:{ldoc}/user/tutorials/DebianBuilding.html[Debian build tutorial],
|
||||
describing the commands for building and the structure of a debian
|
||||
describing the commands for building and the structure of a Debian
|
||||
(source) package in general
|
||||
|
||||
|
||||
Package build process
|
||||
---------------------
|
||||
As our whole infrastructure relies heavily on the Git version management tool, it's only natural
|
||||
also to organise the (debian) packaging with the help of Git. Fortunatlely, there is a nifty tool
|
||||
also to organise the (debian) packaging with the help of Git. Fortunately, there is a nifty tool
|
||||
called link:https://honk.sigxcpu.org/piki/projects/git-buildpackage/[git-buildpackage], written
|
||||
by Guido Günther exactly for this purpuse: It treats the _debianisation_ as a branch in the
|
||||
by Guido Günther exactly for this purpose: It treats the _debianisation_ as a branch in the
|
||||
Git repository, forking off the mainline at the release point.
|
||||
|
||||
For Lumiera, this _debianisation branch_ is called 'deb' and can be found in the
|
||||
link:http://git.lumiera.org/gitweb?p=lumiera/debian;a=summary[git:/git.lumiera.org/lumiera/debian] repository.
|
||||
link:http://git.lumiera.org/gitweb?p=debian/lumiera;a=summary[git:/git.lumiera.org/debian/lumiera] repository.
|
||||
|
||||
Installing Lumiera
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -33,38 +33,48 @@ The link:SCons.html[SCons build] generates a relocatable distribution directory
|
|||
holding the main executable, additional tools and utilities, plus the core libraries and resources.
|
||||
Here _relocatable_ means that this subtree can be moved and placed anywhere on the system.
|
||||
As long as the relative directory layout remains intact, the executables will be able to find
|
||||
and load the accompanying libraries and resources. By invoking the +scons install+ target,
|
||||
and load the accompanying libraries and resources. By invoking the `scons install` target,
|
||||
this directory structure is placed into the installation target directory.
|
||||
|
||||
Actually, this lookup process at application startup is performed in two phases
|
||||
|
||||
- in the first phase the main application locates the directly linked shared libraries.
|
||||
- in the first phase the main application locates the explicitly linked shared libraries.
|
||||
footnote:[generally speaking, we have to distinguish between dynamic libraries explicitly
|
||||
linked as part of the application, libraries linked as direct library dependencies, other
|
||||
transitive library dependencies, and finally shared objects, which are loaded at runtime
|
||||
through the `dlopen()` call.]
|
||||
Especially those libraries belonging first class to the Lumiera application are built
|
||||
with a relative searche path ('rpath' with $ORIGIN token). These libraries are placed
|
||||
with a relative search path ('rpath' with $ORIGIN token). These libraries are placed
|
||||
into the +modules/+ subfolder
|
||||
|
||||
- after successfully launching the executable, the second phase performes a lookup programatically,
|
||||
starting from the path location of the executable, trying to find a +setup.ini+ which defines
|
||||
- after successfully launching the executable, the second phase performs a lookup programmatically,
|
||||
starting from the path location of the executable. The goal is to find a +setup.ini+ which defines
|
||||
additional plug-ins and resources to load. Notably, the GUI to launch is loaded as a
|
||||
plug-in through this mechanism. Moreover, this bootstrap configuration defines the
|
||||
plug-in through this mechanism. Moreover, this *bootstrap configuration* defines the
|
||||
additional platform and user configuration to load for further outfitting of the system.
|
||||
|
||||
LSB Installation Layout
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
This organisation is used as foundation for packaging and installing. The primariy application
|
||||
This organisation is used as foundation for packaging and installing. The primary application
|
||||
distribution structure will be located into a subfolder below +/usr/lib/+. Only the main application
|
||||
executable will be symlinked into +/usr/bin/+. The LSB explicitly allows for such a layout, which is
|
||||
typically used by large application bundles (OpenOffice, Gimp, Eclipse). Since the application
|
||||
startup encompasses two phases, loading the extended configuration programmatically after
|
||||
launching the application, such extended resources can easily be relocated into a separate
|
||||
folder below +/usr/share/+, as required by LSB.
|
||||
launching the application, extended resources from the application bundle can easily be
|
||||
relocated into a separate folder below `/usr/share/`, as required by LSB.
|
||||
|
||||
|
||||
Releases, Branches and Conventions
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Official releases are marked by a tag on the master branch. Usually, we'll also fork a
|
||||
*release branch* at that point, featuring bugfixes only. From here we'll merge to the
|
||||
*debian branch*
|
||||
Official releases are marked by a tag on the master branch. At that point, master should be
|
||||
in good shape, release documentation is polished; experimental features are removed or disabled.
|
||||
Usually, we'll also fork a *release branch* at that point, featuring bugfixes only.
|
||||
From here we'll merge to the *debian branch*
|
||||
|
||||
Typically the release will lead to the discovery of more or less serious bugs, which are
|
||||
fixed on the release branch and backported to master. The result is a sequence of point
|
||||
releases. At the end of a stable release series, the release branch will be upgraded
|
||||
with a single merge commit to the level of the next major release.
|
||||
|
||||
|
||||
Package build commands
|
||||
|
|
|
|||
|
|
@ -36,21 +36,6 @@
|
|||
#include <unistd.h>
|
||||
#include <sys/resource.h>
|
||||
|
||||
//NOBUG_DEFINE_FLAG_PARENT (backend, lumiera); TODO
|
||||
//NOBUG_DEFINE_FLAG (backend);
|
||||
//NOBUG_DEFINE_FLAG_PARENT (file_all, backend);
|
||||
//NOBUG_DEFINE_FLAG_PARENT (filehandle, file_all);
|
||||
|
||||
//NOBUG_DEFINE_FLAG_PARENT (mmapings, mmap_all);
|
||||
|
||||
|
||||
|
||||
//NOBUG_DECLARE_FLAG (file);
|
||||
|
||||
//NOBUG_DECLARE_FLAG (mmap_all);
|
||||
//NOBUG_DECLARE_FLAG (mmap);
|
||||
//NOBUG_DECLARE_FLAG (mmapings);
|
||||
//NOBUG_DECLARE_FLAG (mmapcache);
|
||||
|
||||
|
||||
|
||||
|
|
@ -70,14 +55,6 @@ size_t lumiera_backend_pagesize;
|
|||
int
|
||||
lumiera_backend_init (void)
|
||||
{
|
||||
//NOBUG_INIT_FLAG (backend);
|
||||
//NOBUG_INIT_FLAG (file_all);
|
||||
//NOBUG_INIT_FLAG (file);
|
||||
//NOBUG_INIT_FLAG (filehandle);
|
||||
//NOBUG_INIT_FLAG (mmap_all);
|
||||
//NOBUG_INIT_FLAG (mmap);
|
||||
//NOBUG_INIT_FLAG (mmapings);
|
||||
//NOBUG_INIT_FLAG (mmapcache);
|
||||
|
||||
TRACE (backend_dbg);
|
||||
lumiera_mutex_init (&lumiera_filecreate_mutex, "fileaccess", &NOBUG_FLAG (mutex_dbg), NOBUG_CONTEXT);
|
||||
|
|
|
|||
|
|
@ -37,7 +37,6 @@
|
|||
#include <errno.h>
|
||||
|
||||
|
||||
//NOBUG_DEFINE_FLAG_PARENT (filedescriptor, file_all);
|
||||
|
||||
/* lookup and creation of files, initialized in backend.c */
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,6 @@
|
|||
#include "backend/filedescriptor.h"
|
||||
#include "backend/filedescriptorregistry.h"
|
||||
|
||||
//NOBUG_DEFINE_FLAG_PARENT (filedescriptorregistry, file_all);
|
||||
|
||||
/*
|
||||
Filedescriptor registry
|
||||
|
|
|
|||
|
|
@ -25,7 +25,6 @@
|
|||
#include "backend/file.h"
|
||||
#include "backend/filehandlecache.h"
|
||||
|
||||
//NOBUG_DEFINE_FLAG_PARENT (filehandlecache, file_all);
|
||||
|
||||
/* errors */
|
||||
|
||||
|
|
@ -40,7 +39,6 @@ lumiera_filehandlecache_new (int max_entries)
|
|||
{
|
||||
REQUIRE (!lumiera_fhcache, "Filehandlecache already initialized");
|
||||
|
||||
//NOBUG_INIT_FLAG (filehandlecache);
|
||||
lumiera_fhcache = lumiera_malloc (sizeof (lumiera_filehandlecache));
|
||||
lumiera_mrucache_init (&lumiera_fhcache->cache, lumiera_filehandle_destroy_node);
|
||||
lumiera_fhcache->available = max_entries;
|
||||
|
|
|
|||
|
|
@ -35,7 +35,6 @@
|
|||
*
|
||||
*/
|
||||
|
||||
//NOBUG_DEFINE_FLAG_PARENT (fileheader, /*TODO insert parent flag here */);
|
||||
|
||||
LUMIERA_ERROR_DEFINE (FILEHEADER_NOWRITE, "File is not writeable");
|
||||
LUMIERA_ERROR_DEFINE (FILEHEADER_HEADER, "Error in header");
|
||||
|
|
|
|||
|
|
@ -35,8 +35,6 @@
|
|||
*
|
||||
*/
|
||||
|
||||
//NOBUG_DEFINE_FLAG_PARENT (mmap_all, backend);
|
||||
//NOBUG_DEFINE_FLAG_PARENT (mmap, mmap_all);
|
||||
|
||||
|
||||
LUMIERA_ERROR_DEFINE (MMAP_NWRITE, "Backing file not writable");
|
||||
|
|
|
|||
|
|
@ -29,7 +29,6 @@
|
|||
*
|
||||
*/
|
||||
|
||||
//NOBUG_DEFINE_FLAG_PARENT (mmapcache, mmap_all);
|
||||
|
||||
LumieraMMapcache lumiera_mcache = NULL;
|
||||
|
||||
|
|
|
|||
|
|
@ -41,12 +41,6 @@
|
|||
*
|
||||
*/
|
||||
|
||||
//NOBUG_DEFINE_FLAG_PARENT (config_all, lumiera_all);
|
||||
//NOBUG_DEFINE_FLAG_PARENT (configsys, config_all);
|
||||
//NOBUG_DEFINE_FLAG_PARENT (config_typed, config_all);
|
||||
//NOBUG_DEFINE_FLAG_PARENT (config_file, config_all);
|
||||
//NOBUG_DEFINE_FLAG_PARENT (config_item, config_all);
|
||||
//NOBUG_DEFINE_FLAG_PARENT (config_lookup, config_all);
|
||||
|
||||
LUMIERA_ERROR_DEFINE (CONFIG_SYNTAX, "syntax error in configfile");
|
||||
LUMIERA_ERROR_DEFINE (CONFIG_SYNTAX_KEY, "syntax error in key");
|
||||
|
|
@ -99,12 +93,6 @@ lumiera_config_init (const char* path)
|
|||
REQUIRE (!lumiera_global_config, "Configuration subsystem already initialized");
|
||||
REQUIRE (path);
|
||||
|
||||
//NOBUG_INIT_FLAG (config_all);
|
||||
//NOBUG_INIT_FLAG (configsys);
|
||||
//NOBUG_INIT_FLAG (config_typed);
|
||||
//NOBUG_INIT_FLAG (config_file);
|
||||
//NOBUG_INIT_FLAG (config_item);
|
||||
//NOBUG_INIT_FLAG (config_lookup);
|
||||
|
||||
lumiera_global_config = lumiera_malloc (sizeof (*lumiera_global_config));
|
||||
lumiera_config_lookup_init (&lumiera_global_config->keys);
|
||||
|
|
|
|||
|
|
@ -39,10 +39,6 @@
|
|||
* by their name and major version.
|
||||
*/
|
||||
|
||||
//NOBUG_DEFINE_FLAG_PARENT (interface_all, lumiera_all);
|
||||
//NOBUG_DEFINE_FLAG_PARENT (plugin, interface_all);
|
||||
//NOBUG_DEFINE_FLAG_PARENT (interfaceregistry, interface_all);
|
||||
//NOBUG_DEFINE_FLAG_PARENT (interface, interface_all);
|
||||
|
||||
PSplay lumiera_interfaceregistry;
|
||||
PSplay lumiera_pluginregistry;
|
||||
|
|
@ -91,10 +87,6 @@ lumiera_interfacenode_delete (LumieraInterfacenode self)
|
|||
void
|
||||
lumiera_interfaceregistry_init (void)
|
||||
{
|
||||
//NOBUG_INIT_FLAG (interface_all);
|
||||
//NOBUG_INIT_FLAG (interfaceregistry);
|
||||
//NOBUG_INIT_FLAG (interface);
|
||||
//NOBUG_INIT_FLAG (plugin);
|
||||
|
||||
TRACE (interfaceregistry_dbg);
|
||||
REQUIRE (!lumiera_interfaceregistry);
|
||||
|
|
|
|||
Loading…
Reference in a new issue