ALFS documentation

Neven Has haski at sezampro.yu
Wed May 15 15:16:46 PDT 2002


On Wed, May 15, 2002 at 06:40:51PM +0200, Tanja E.J. Vos wrote:
> * what to read? (nobody has yet written something about  ALFS and possible 
> implementations ??)

Yeah, we need some docs. Actually, we need _someone_ to write them. ;)
For now, reading those messages from this list is the best you can do.

> * how to read their source code (global workings (architecture) and ideas 
> behind these two ALFS)

The first thing nALFS does is parsing a profile given on the command
line. element_t (defined in src/parser.h) is used to represent every XML
element. They are then connected to form a tree-like structure. All
this is done by the code in src/libXML-tree.c, which is called by
parse_profile() (defined in src/parser.c).

browse() in src/nalfs.c is the main input loop. It's the ultimate source
for the available commands. ;)

When you start the execution, start_executing_*() functions are first
called to mark the elements that will run (by setting
element->should_run).

Then, a new process (a backend) is created (by start_executing()) which
is responsible for the actual execution. The main process continues to
serve the user input.

A backend (code in src/backend.c, which will be separated to a different
program one day) traverse the tree (execute_children() in
src/backend.c), and checks each element if it has should_run set. If it
does, it calls the main function (a handler) for that element
(<element>_main() in src/handlers/<element>.c).

All handlers are declared in src/elements.h (by HANDLER()). parameters[]
(also found in src/elements.h) are elements too, but only in a XML
sense. In program's, they just hold some info which is used by handlers
individually. XML elements not mentioned in src/elements.h are ignored.

For now, in handler, nALFS just uses the appropriate system commands to
do the job (execute_command() in src/backend.c). In the future it might
use the system calls to implement the handlers, although that would be
just a faster and independent reinvented wheel. ;)

Frontend and backend communicate constantly (when executing, since
that's the only time then backend exists). There are two "channels"
of communication.

One is used only by the backend to send all its output (pstatus_backend()
in src/backend.c) to the main process. When that data arrives, it is
read by the frontend (handle_data_msg() in src/nalfs.c) and printed in
the status window. Those are the messages prefixed with "-: ".

The other "channel" (a Unix socket actually, as the first one) is
a "control socket". It is used for controlling the backend (pausing,
stopping, changing various options etc.). It is also used by backend to
send the information (to the frontend) about which element is
currently being executed (so that the frontend can follow the execution
and print those lovely color marks ;).

ctrl_msg_type_t in src/utility.h is a list of all those "control"
messages. They are in the form of:

    SIZE|TYPE|BODY

SIZE is a number used for reading the full message from the socket.
TYPE is a number from ctrl_msg_type_t (enumeration). BODY is not used
much, depending of the type of message.

A simple protocol, but it works for now. ;) It will have to be greatly
improved however, when frontend and backend are split in the future. And
probably standardized (not this one of course, that has yet to be
discussed here) to allow different frontend/backend implementations,
communicating with each other.

Anyway, I'm not very good at being perfectly understandable in these
kind of things ;), so if you have some specific questions drop me a
mail.


Neven

-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe alfs-discuss' in the subject header of the message



More information about the alfs-discuss mailing list