dev_server
(v1.0.0 Release)


0. Index

  1. Name
  2. Installation
  3. Synopses
  4. Description
  5. Options
  6. Files
  7. Bugs and Test Notes
  8. Diagnostics
  9. To Do...
  10. Release History
  11. Legal Crap

1. Name

dev_server

A server to provide an interface between kernel-space and the rest of the world.

quit_dvsrvr

A program to quit the dev_server in a semi-friendly way.

2. Installation

To install the dev_server, just run the installer script install.sh that came with the installation. This will place the dev_server files where they need to go.

You can put dev_server add-ons in any directory listed in your ADDON_PATH environment variable (e.g., ~/config/add-ons/). The dev_server will look in those directories as well as the dev_server/ sub-directory in those directories (e.g., ~/config/add-ons/dev_server/).

For a guide to developing dev_server add-ons, please see the documentation for the accompanying add-on example (see the Files section below).

3. Synopses

dev_server [ OPTION ] ...

quit_dvsrvr

4. Description

dev_server is a server and a set of tools designed specifically for kernel add-ons that wish (for convenience, etc.) to be able to access things not available in kernel-space (e.g., the app_server, net_server, etc.). It is meant as a convenience mainly to eliminate two awkward cases:

  1. The 1-to-1 Device/Server Ratio

    Without the dev_server, each kernel add-on developer who wishes for his kernel add-on to interact with non-kernel-space entities must create his own gateway. The easiest route would be to create a server specifically for that kernel add-on.

    For example, take the developer who wishes to write an NFS kernel file system add-on. NFS needs access to networking calls, but can't get to them from the kernel. Since ports ARE available in the kernel, one solution might be to create a server which runs all the time and listens for connections from the file system add-on on a certain port. Then a connection can be made, and bingo, the file system add-on now has (indirect) access to the rest of the world.

    If two or three developers take this route, pretty soon, you've got two or three additional servers running on your machine, each with a specific purpose. From the user's perspective things begin to get cluttered. From the developers' perspectives a lot of work is being repeated in creating each server.

  2. The Incredible Replicating Interface

    In the case of the thruput monitor example, if we wanted to create a thruput monitor without using a server, we would have to build it into any application which wished to use it (forget about adding it to the net_server or the PPP add-on). Suddenly we've got three or four different implementations or versions of the same thing.

The dev_server eliminates the first case by providing one common server (and one common interface) with the capacity for expansion via add-ons. Developers can concentrate on the protocols and drivers instead of server construction. Granted, this only saves one to two days worth of work, but hey, that's one or two more days ahead of schedule....

The dev_server eliminates the second case by allowing for a thruput monitor (or any such device) to exist in the port device space, and hence may be attached to anything which uses a port device. It makes a connection to the dev_server and uses the same code (and has the same interface) each time it's used. Also, if you don't like it, you can write a new one and replace it...everywhere.

5. Options

-v, --verbose

Output additional diagnostics to stdout.

-?, --help

Display this help and exit.

-V, --version

Output version information and exit.

6. Files

The following files are included with this distribution:

doc/README.html

This file.

install.sh

The dev_server installer script.

include/AddOn.h

A header file for the AddOn abstract base class found in dev_server.

include/Arrayomatic.h

A header file for the Arrayomatic template class used by the AddOn class.

include/Benaphore.h

A header file for the Benaphore class found in dev_server.

include/DevBenaphore.h

A header file for the DevBenaphore class found in libdev_server.a.

include/DevCnnctn.h

A header file for the DevCnnctn class found in libdev_server.a.

include/KThread.h

A header file for the KThread abstract base class found in dev_server.

include/PortThread.h

A header file for the PortThread abstract class found in dev_server.

include/dev_server.h

A header file containing several miscellaneous dev_server constants and functions found in libdev_server.a.

lib/libdev_server.a

The development library for writing dev_server drivers.

thruput_example/

A dev_server example add-on and driver to monitor thruput on a port device.

thruput_example/doc/README.html

Documentation on how to create dev_server add-ons and drivers.

quit_dvsrvr.cpp

A source file containing a program to quit the running dev_server in a semi-nice way.

7. Bugs and Test Notes

I tried to make the server pretty robust, but it's still possible to screw it up by writing a bad add-on or driver (there, I've now shirked any and all responsibility off on other programmers).

Seriously, the server's simple enough that it alone should be fine. All it's there for is to provide an interface between drivers and the rest of the world. During the development of the thruput add-on and driver, I found that many interesting (and not necessarily good or useful) states are possible by running an add-on or driver that misbehaves (but that's no different from developing add-ons and drivers for other things). If you're planning on developing an add-on or driver for the dev_server, just be careful and you should be fine.

There are no known bugs at this time, but if an add-on should crash the server, other devices may be left in weird states. In other words, don't write something that will crash the server and everything should be fine. In the event you should find a bug, something you don't like or something you would like but is missing, please feel free to e-mail me (Matt Bogosian <mbogosian@usa.net>). Please let me know which version you have (listed at the top of this document).

8. Diagnostics

An exit status of 0 indicates a successful operation.

An exit status of -1 indicates a critical execution error of some kind.

An exit status of -2 indicates a critical command-line parsing error of some kind.

An exit status of -3 indicates a critical memory allocation error of some kind.

An exit status of -4 indicates a critical file I/O error of some kind.

9. To Do...

There are some things I'm working on and some features I'd like to add in future versions of the dev_server, some of which are as follows:

10. Release History

v1.0.0

Initial release (this version).

11. Legal Crap

The dev_server package (including any and all documentation) is freeware and is provided as-is with no warranty of correctness or usefulness. If you have any comments, requests, questions or complaints, please email me (Matt Bogosian <mbogosian@usa.net>). If I am notified of a bug, I will do my best to correct it, but I guarantee nothing.

The dev_server package (including any sample code) is not freely distributable. Distribution may occur with written permission from the author and with the provision that all files (including this documentation) remain intact and with the distributed package.

Neither any warranty nor restrictions which apply to the dev_server package are transferable to third-party add-ons and code written which make use of the dev_server package. In other words, I'm not responsible for poorly-written dev_server add-ons (unless, of course, they're mine).


© 1998, Matt Bogosian <mbogosian@usa.net>. All rights reserved.