Browse Prior Art Database

Support for Dynamic Config of Link Support and Video Support Modules on UNIX

IP.com Disclosure Number: IPCOM000112811D
Original Publication Date: 1994-Jun-01
Included in the Prior Art Database: 2005-Mar-27
Document File: 2 page(s) / 92K

Publishing Venue

IBM

Related People

Baker, RJ: AUTHOR

Abstract

Disclosed is a technique that allows the dynamic support of hardware-specific modules in UNIX*, which does not normally support dynamic linking. Previously the solution required either fixing the list of supported interfaces and hardware or by restricting use to one at a time.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Support for Dynamic Config of Link Support and Video Support Modules
on UNIX

      Disclosed is a technique that allows the dynamic support of
hardware-specific modules in UNIX*, which does not normally support
dynamic linking.   Previously the solution required either fixing the
list of supported interfaces and hardware or by restricting use to
one at a time.

      In an environment where basic control software wishes to
support an unbounded list of lower level software, or hardware
options, it is necessary to define an interface that any developer
can use to implement a support module for that structure.   For
example, a Person to Person video application does not wish to be
restricted to a pre-determined list of video cards that it can
support; and it should be possible to extend the group of
communications link types supported, such that developers can add
support for their communications sub-systems.

      Having isolated the minimum subset of code to support video
cards, or link support types, and defined that interface, in order
that developers can construct such a module; the control software is
left with the task of being able to use any such module that has been
implemented on the running system.   On operating systems that
explicitly support dynamic loading of modules, and querying the entry
point address of named functions, the control code can issue load
subroutine calls, query the addresses of function entry point names
as defined in the interface, and then call these subroutines by
address when required.  UNIX has no such dynamic load and query
address functions.

      The UNIX solution implemented is as follows.   The control code
searches the library file system for any files matching a given
naming standard (e.g., liblsm*.a).  This allows users to simply add
new control modules by placing the appropriate file in the library
path on their machine.   Having identified a file to load, the
control code could issue a UNIX load and bind call.   This is a
feature of some UNIX systems that allow deferred resolution of
symbolic names.   Use of this call would mean that all control
modules would be required to have a unique set of entry points names
which would reduce the flexibility of operation, and the ease of
extending the operating environment.

      The implementation solution is in two stages.  First the
identified file is loaded into memory, using the standard UNIX load
command.  This will identify dependencies that the support module
has, and load the libraries it requires to run.  It does not resolve
any of the entry points to the support module.  The load command also
returns the address of the 'main entry point' to the lo...