A. BACKGROUND

1. What is serel?

   Serel is software that makes your computer boot faster.  serel provides
   synchronisation services to the operating system initialisation
   processes.  Unrelated services start in parallel, which allows
   a computer to reach it's "ready" state as quickly as possible.

2. Why was serel created?

   Serel was created by people who wanted computers to boot faster.
   Primarily, this means efficient parallelism amongst the things
   that a computer does when it starts.  Important considerations
   also include low maintenance costs for developers and vendors,
   wide portability, and low-risk to end-users.

3. Why the name serel?

   The name "serel" derives from "SErvice-RELationship".  The expression
   of dependency relationships among the services allows them to be safely
   started in parallel.


B. USERS

1. How do I use serel once it's installed?

   Even after installing serel, your system wll still boot as normal. 

   To run your boot scripts in parallel with serel under RedHat 7.x,
   you must pass an environment variable to /etc/init.d/rc.

   You can do this at the boot prompt, for example:

	   This enables serel in runlevel 3:

	   lilo> linux SEREL_RUNLEVELS=3

	   This turns on lots of logging, look in /tmp for the output:

	   lilo> linux SEREL_RUNLEVELS=3 SEREL_DEBUG=on

2. How can I test serel without rebooting?

   To test serel without rebooting, set SEREL_RUNLEVELS by
   editing /etc/rc.d/rc and uncommenting the relevent line.
   Then change to another run level with:

		   telinit 1

	   and change runlevels again:

		   telinit 3

   Whether you are rebooting or changing runlevels, you should notice
   that serel helps your system reach it's "ready" state faster.

3. How do I turn serel off?

   If you don't explicitly turn serel on using the SEREL_* environment
   variables, your computer will boot the way it did prior to serel
   installation.
   
4. How do I restore my init scripts after serel-install-lsb has modified them?

   serel-install-lsb renames the original directory by adding a .bak suffix,
   and makes changes to a copy.
   eg. /etc/rc.d/init.d would have been renamed as /etc/rc.d/init.d.bak

5. How much faster does my computer boot?

   There are three phases to boot:
   a. hardware initialisation
   b. operating system kernel loading
   c. service initialisation

   Serel only makes (c) faster.  In fact, it currently just makes the runlevel
   part of (c) faster.  Grab a stopwatch, boot with and without serel, and let
   us know the results!


C. DEVELOPERS

1. How does serel integrate with my operating system boot mechanisms?

   The operating system boot mechanism (eg. /etc/rc.d/rc under RedHat 7.x)
   first starts the serel daemon and then starts the boot services in
   parallel.  Services synchronise with each other as the dependencies
   emerge (below).

   Note that serel does not start processes.

   Dependencies emerge in one of two ways:
   a. Declared dependencies.
      eg. special comments inside init scripts.
      Declared dependencies are parsed from scripts and go into effect
	  before a boot-script executes.  Declared dependencies make for easy
	  maintenance on the part of script developers and vendors.

   b. Run-time dependencies.
      Boot scripts can execute the serel synchronisation primitives
      at run time.  This idiom allows scripts to get work done before
      blocking, and offers flexibility of expression, for example,
      "network depends on either iptables or ipchains".  Script developers
      seeking optimal performance will use run-time dependencies.

   The system is ready to use when all the initialisation services have
   terminated.

2. How does serel work?

   The core function of serel is the run-time management of dependencies.
   The daemon manages an acyclic directed graph where Nodes are services
   and Edges are relationships.  To co-ordinate their activities, boot
   services request operations on the graph:
      - provide   - add a node
      - need      - add an edge
      - unprovide - remove a node and related edges

   Nodes are also finite state machines, changes in state result from
   the exit status of boot services.

   Nodes are also finite state machines, so that success or failure in
   one service has a corresponding impact on related services.

   The serel core uses only kernel-supplied interprocess communication
   services, which allows the serel synchronisation primitives to be used
   as early in the boot-cycle as possible.

3. What's syntax of the special comments in the init scripts?

   serel expects the syntax referenced in the Linux Standards Base:
   http://www.linuxbase.org/spec/refspecs/LSB_1.0.0/gLSB.html#INITSCRCOMCONV

4. Wouldn't things be simpler if serel started processes?

   There are a wide variety of process-starting styles in the world,
   including various flavours of System V, BSD, and so on.
   Creating parallel versions of each style in order to make them
   boot fast is a big job.  It's simpler to offer a small set of
   synchonisation services across all these platforms.

5. Can you point me to related work of this sort?

   NetBSD illustrates dependencies declared via the boot-script headers:
   http://www.cs.rmit.edu.au/~lukem/papers/rc.d.pdf)

   Richard Gooch has implemented a system of "need" and "provide" that's
   bundled with a special-purpose init, called "simpleinit".  See:
   http://www.atnf.csiro.au/~rgooch/linux/boot-scripts/.
