The base plugin mechanism is a simple abstraction of an `execution environment'. This environment, termed the plugin runtime, registers, handles, and manipulates the kernel plugins of a single extensible entity. It can be thought of as defining a streamlined abstraction of a tiny virtual machine. As our aim is not to emulate a particular systems platform but to create a clean and efficient extension environment, we are able to design for simplicity and reap the benefits of efficiency.
Each runtime has a restricted, but well-defined API providing the means to add new plugin functions, as well as to execute and delete existing ones. Multiple runtimes may exist simultaneously at any given time, each managing the extension functionality of a single client or client instance. Each instance of an extensible entity creates its own runtime and dynamically populates it with client-supplied plugins. The resulting multiplicity of runtimes serves a threefold purpose. It allows extensibility on a per-instance basis, prevents plugin namespace pollution, and isolates related or cooperating plugin functions within a single runtime. Actual coordination and cooperation of plugin functions of a single client is left to the client itself, with the runtime only providing the glue primitives to enable it.
As an illustration, consider two separate kernel services: a kernel http daemon (as in our sample application), and a kernel NFS server. Each server instance creates a runtime for its plugins and populates it upon its clients' request. The http daemon's threads might install any number of image manipulation plugins, whereas the NFS daemon's threads might install various data compression algorithms. The separate runtimes ensure that the namespaces of unrelated plugins belonging to different clients are disjoint and that unrelated data and symbols cannot be named or invoked.
Built-in Plugins
Sometimes application-specific plugin code
will need to call on certain kernel functions to achieve its goals,
e.g. enqueuing a packet or reading/writing a block from/to disk. To
accommodate such callbacks seamlessly within our framework they
are represented as a kind of plugin. These `built-in' plugins are
explicitly added to the runtime by the kernel service it extends. Even
though they act as kernel callbacks, within the restricted plugin
environment they are indistinguishable from a regular `dynamic' or
user-supplied plugin. That is to say that they are invoked and used in
exactly the same fashion. Immediately after its creation, a runtime's
namespace contains only a default set of available built-ins listed in
Figure 1. They perform basic namespace maintenance
expected from the dynamic linker: create(), lookup(), and
delete().
The availability of callbacks poses the question of how to handle kernel resources acquired through them in the event that a plugin needs to be terminated. Because of the rich variety of kernel resources, we considered building a system that tracks all of them to be impractical. We believe that the runtime's owner service is able to handle the cleanup of the limited number of kernel resources it makes available to its plugins in a much more efficient way, if at all needed, e.g. through callback wrappers tracing resource usage, etc.