Why write a resource manager?

Here are a few reasons why you may want to write a resource manager:

• The client API is POSIX.

  The API for communicating with the resource manager is for the most part, POSIX. All C programmers are familiar with the open(), read(), and write() functions. Training costs are minimized, and so is the need to document the interface to your server.

• You can reduce the number of interface types.

  If you have many server processes, writing each server as a resource manager keeps the number of different interfaces that clients need to use to a minimum.

  For example, suppose you have a team of programmers building your overall application, and each programmer is writing one or more servers for that application. These programmers may work directly for your company, or they may belong to partner companies who are developing addon hardware for your modular platform.

  If the servers are resource managers, then the interface to all of those servers is the POSIX functions: open(), read(), write(), and whatever else makes sense. For control-type messages that don't fit into a read/write model, there's devctl() (although devctl() isn't POSIX).

• Command-line utilities can communicate with resource managers.

  Since the API for communicating with a resource manager is the POSIX set of functions, and since standard POSIX utilities use this API, you can use the utilities for communicating with the resource managers.

  For instance, suppose a resource manager registers the name /proc/my_stats. If you open this name and read from it, the resource manager responds with a body of text that describes its statistics.

  The cat utility takes the name of a file and opens the file, reads from it, and displays whatever it reads to standard output (typically the screen). As a result, you could type:

  cat /proc/my_stats
    

  and the resource manager would respond with the appropriate statistics.

  You could also use command-line utilities for a robot-arm driver. The driver could register the name, /dev/robot/arm/angle, and interpret any writes to this device as the angle to set the robot arm to. To test the driver from the command line, you'd type:

  echo 87 >/dev/robot/arm/angle
    

  The echo utility opens /dev/robot/arm/angle and writes the string (“87”) to it. The driver handles the write by setting the robot arm to 87 degrees. Note that this was accomplished without writing a special tester program.

  Another example would be names such as /dev/robot/registers/r1, r2, and so on. Reading from these names returns the contents of the corresponding registers; writing to these names sets the corresponding registers to the given values.

  Even if all of your other IPC is done via some non-POSIX API, it's still worth having one thread written as a resource manager for responding to reads and writes for doing things as shown above.