|
|
All external names for C device driver routines are formed using the prefix(D1) for the driver, such as tok or e3B. This is mandatory for ``Entry-point routines''entry point routines in drivers that use DDI versions prior to version 8 and all ODDI drivers for SCO OpenServer 5 and highly desirable for DDI 8 drivers, even though the kernel accesses the driver's entry points through the drvops(D4) structure. Subordinate driver routines and other resources should either be prefixed or given static linkage. The ensures that these names will not collide with names inside the kernel or with names in other device drivers and loadable modules.
For a C++ driver, the kernel-called routines must be declared and defined as non-member functions, using extern "C" linkage, and named with the appropriate prefix. This gives them the unmangled name that the kernel expects.
A problem arises with other C++ names. For instance, class member function names cannot be given static linkage or be defined with extern "C". Rather, they will always have global, mangled names. For example, a member function A::f might get the name f__1AFv. Such a name is in violation of the driver name space guidelines.
As a practical matter, such mangled names are extremely unlikely to collide with any name in the kernel, since the kernel is not written in C++. Such names could, however, collide with other drivers written in C++. The solution then is to prefix the C++ class names (or other kinds of names) with the appropriate driver prefix (so that member function xxxA::f would get name f__4xxxAFv), or, in SVR5, to put the driver code inside a C++ namespace (so that member function xxx::A::f would get name f__Q2_3xxx1AFv). Either way, names will not collide with those of other C++ drivers.
In SVR5, strict adherence to the driver name space guidelines can be achieved by using the ld -r -Bexport= list option. This enables you to specify all the external names that the driver exports to the kernel. The linker then hides the mangled names that violate the name space guidelines. Note, however, that doing this could make debugging the driver more difficult.
In SCO SVR5 2.X, ld does not support using the -Bexport option with -r.