Be Driven
  Device Drivers in the Be Os
     
    Add-Ons

Understanding Add-Ons

  • Device Drivers are not Add-Ons

  • Add-Ons are also been known as Plug-Ins in other Operating Systems.

  • Add-Ons are shared libraries by another name.
    Or should I say, a shared library can be used as an Add-On.

  • A Shared library, in other operating systems, is often called a 'Dynamic Link Library' or a 'DLL' for short, and is functionally identical.

  • (confused yet.. ;-)

It's all a matter of 'HOW' a program goes about using this Shared Library.
I will refer to add-ons as a Shared Library for ease of reading.

Shared Libraries, export a set of functions and variables, in the same Team Space as the application that loads them. The Shared Library can access memory allocated by the main application, and vica versa..

In this way, the Shared Library acts as a logical extension to the main application.If an application links to a shared library at compile time, on startup, the application magically (read automatically) finds the Shared Libraries it wants, by searching specific directory structures, and 'Links' to it at run time, else complains noisily to the user, and exits gracefully.

A Shared Library, used in this manner, normally exports LOTS of symbols (functions and variables) in C and C++. Because it is so Transparent to the programer it is viable to expose heaps of symbols.

But... If you don't wana do that., you wanna be clever, you can search through files in a directory, and try loading them, using the image_id = load_add_on( path ), command. If it finds the 'path' requested resolves into a Shared Library, then you most manually search for a 'well none' function name using get_image_symbol( image_id, name, type, dest ). If you don't find the function name you are looking for, then it isn't the shared-library you are looking for, should unload_add_on( image_id ) and keep on looking.

Now, there is something intersting to note.. If there is a directory of Shared-Libraries for this purpose, they all export a 'Uniform' interface.. In this manner, they are similar to device drivers.. You want a common, well known set of functions to interarct with.

Add-Ons normally export 1 or 2 functions that create a list of function calls in a structure, or a newly created object, to access the rest of the library. This will also be a well defined interface.. (A Pure Abstract Class, or some well defined structure like the device driver exports. )

One must remember that because a Shared LIbrary exports C and C++ names, that the C++ names are mangled in a compiler specific format.. This is the main reason why Add-Ons dealing with C++ normally only export a C function, that creates and returns a C++ object for you to play with.

Shared Libraries, (regardless of how loaded), release them selves when an application exits. And, just for fun, You can be really clever, and actually list all public function names and objects in a Shared-Library, if you want too.

For more detailed information read the Be Book / Kernel Kit / Images.

Using Add-Ons and Device Drivers Together?

Add-Ons are often used to provide extensions to Application Servers, or other programs in User Space (as opposed to kernel space).

By splitting your driver needs between a Device Driver and a Add-On, you can put all long-tasks into the Add-On, and all real-time issues into the lightweight Device Driver, resulting in improved repsonsiveness of the whole system.

Overall Stability is increased because if your device fails in User space, it may not necessarily bring down the entire system, where a crash in Kernel space, is much nastier.

Performance is gained by spending less time in the Kernel, and Particullarly Less time spent handling Interrupts..(This is because interrupts stop operation of other threads of executition whilst being serviced)

Performance is also improved because you move the data closer to where it is needed, providing more flexibility in optimization between versions. (Ie., driver may not change, but add-on does to add new features).

Add-Ons are normally writen to extend a particular application server, where device drivers provide only the most core hardware abstraction of the device.

Using Add-Ons in a Device Driver

DONT!

Add-Ons are designed for extending applications in USER space...
Modules are a special type of add-on for device drivers...


The Communal Be Documentation Site
1999 - bedriven.miffy.org