
HACKING GUIDE for VFsys.knews V0.001
====================================
This document will be updated as time permits.

The software has been compiled under the WCC 10.6 beta compiler and
works with the QNX 4.23 beta operating system.  No warranties are
provided with this product.

Overview of directory structure and contents
--------------------------------------------
VFsys.knews, as shipped, consists of three main directories:

	./lib
	./news
	./vfsys

The lib directory contains miscellaneous utilities.  It is hoped that
sometime in the future, I'll get around to converting some of these
utilities to C++ -- LPTRT and StringArrayT types are ideal candidates.

The news directory contains the newsfeeder program.  It is a very simple
minded NNTP client that just requests the list of articles that have
changed since the last time it ran, and stashes this list of article IDs
into a tempfile in the current directory.  Then, a second pass comes along,
reading each article ID, and requesting it from the NNTP server.  The
article is then appended to the Expiry Ordered Heap (EOH) file, and an
IPC message is sent to VFsys.knews, telling it about the new article.

The vfsys directory contains the actual virtual filesystem.  This is the
tricky part :-).  It basically implements a QNX 4 resource manager, which
is a server that knows about certain message types.  The messages that
it can receive generally deal with things like file operations (open,
read, write, lseek, that kind of thing) and directory operations (open,
readdir, rewinddir, close), etc.  The individual message handlers are
all stored in resmgr.c, rm_io (for the I/O resource manager handlers)
and rm_news (for the KNews specific ones).  The KNews specific ones
are very simple -- they just unpack the IPC message structure, and call
a worker routine that does the work.  The rm_io ones are a little more
tricky.  Generally what happens in a resource manager is that the open
call (io_open, or io_handle) associates some context that will then
follow the request around.  The next message that comes in from that
particular client will use the context.  So functions like io_read,
for example, depend upon the io_open having set up a context (which
tells it things like what position in the file it is currently at,
the file descriptor for the opened EOH file, etc) for their correct
operation.

Overview of code structure
--------------------------

Most of the code that you see is organized around a starter and an
ender concept.  The starter is responsible for initializing any
environment that might be required.  Then, the actual code runs.
Finally, the ender comes around and releases any unneeded resources.

