Introduction
The current XFree86® loader was originally developed as part of the lead up to the 4.0 Release, and was used to facilitate the modularisation of the internal XFree86 server structure. The loader played a key part of the move from the XFree86 3.x based architecture to the XFree86 modular 4.0 design. Subsequently, the loader was adapted to more fully match the interconnectedness of the XFree86 server architecture.
So, while the current version of the XFree86 loader works and works capably, it is heavily focused on the modularisation of "drivers" and driver-related components. This gives it two significant limitations:
- It is not well suited to modularising or customising "core" server internal components.
- It is difficult to import external system-provided interfaces which the core XFree86 server may not be aware of.
So, with these goals in mind, X-Oz Technologies is pleased to announce the first installment of a set of XFree86 loader enhancements designed to address the current limitations, yet also extend the modularity potential of the XFree86 server.
Stale Relocations
One of the more serious problems with the current XFree86 loader is the issue that relocations are not invalidated when unloading a module, nor are they re-calculated when re-loading.
The first installment of our XFree86 Loader Enhancements alleviates this flaw by keeping track of all "external" relocations particularly when the module is re-loaded, and the relocations get automatically recalculated.
This flaw shows up in desktop footprints; most particularly low-footprint areas.
All unresolved symbols are now directed to the loader's catch-all function, which has been greatly enhanced to provide complete programming diagnostics.
Export Restrictions
The first installment of our XFree86 Loader Enhancements allows modules to define a list symbols to export. This feature is unavailable in the present design.
Class Scoping
Scoping also provides a convenient mechanism for implementing the export restrictions via the "self" and "global" scopes and is implemented via classes..
Minimized Footprint
These changes affect the loader's memory usage because by keeping track of relocations the memory usage is increased but by minimizing the exported symbols the memory usage decreases substantially depending upon the type of module being loaded.
The improved hashing algorithm used for loading the symbol table also works far better with the name space exported by the core executable.
Platform Limitations
The installment of our X-Oz Loader for XFree86 is implemented only for ELF objects on IA32 platforms.
Future Work
Future work we are planning for the expanding the Loader++ includes (not in prioritized order):
- Making broader use of class-scoping.
- Allowing scheduling and synchronization of tasks
- Ensuring a secure X server.
- Providing mechanisms for modules to gain access to system or externally provided interfaces.
- ...and of course following up on the higher level goals that these enhancements will make possible.
Credits
This work was done by David H. Dawes and everyone X-Oz Technologies.