A significant motivation for providing server programs is to isolate device-specific operations within separate components, thus preventing each component from having too broad access to low-level system functionality. The combination of components is then encouraged to achieve configuration objectives.
For example, two computing systems that employ the same LCD controller might each employ different screen types and have different ways of controlling display behaviour. By defining explicit mechanisms for combining access to these different aspects of the hardware, common elements (such as the LCD controller) may be encapsulated by a device server that can be reused, with differing elements (such as the screen type) being described by separate resources or components that can be introduced as required.
Here is how the Ben NanoNote's framebuffer is supported by components:
And here is how the Letux 400's framebuffer is supported:
Note that fb-drv links to the same generic JZ4740 LCD controller library in both cases
Here, the CPM device provides access to the clock and power management functionality, the display device provides access to the backlight and is responsible for configuring pins for the display. Device servers are connected using capabilities (object references).
Meanwhile, panel information is provided via a dynamically-loaded library:
This method of obtaining a configured library name in order to load it dynamically is effectively equivalent to having a symbolic link identifying the library referencing the desired, specific library to be used. Since the "rom" virtual filesystem does not appear to support symbolic links, this method is used instead.
By providing well-defined interfacing mechanisms, the behaviour of driver code can be parameterised using external components, and a proliferation of specially-constructed device drivers is hopefully avoided.