-
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.
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.