OpenSolaris

The default mode of searching for symbols at runtime, is to inspect each loaded
object, starting with the application.  This search has been the defacto
standard in Unix since dynamic linking was introduced.  It's intent is to
ensure one implementation of an interface (the first one found), is used to
satisfy all references.   The problem however, is that the model ensures one
implementation is found :-).   Todays applications and libraries get more and
more complex, and unintended interposition keeps causing issues.  In addition,
scenarios are becoming more common where process units wish to bind to
different implementations of the same named symbol.

Direct bindings is a technology added back in Solaris 7.  It records the
dependency that satisfies a symbol reference at link-edit time.  This
dependency is then inspected directly at runtime to resolve the symbol, rather
than employing the more expensive scan of loaded objects.

Direct bindings provides a means of binding to separate instances of
interfaces having the same name.   This can be exploited to avoid accidental
interposition.  (A recent ldap issue, is just another in a chain of namespace
pollution problems we keep coming across, see 4737548).  In fact, the whole
synonyms.h model of building many system libraries could be replaced with
direct bindings.

Interposition is still provided.  Objects that wish to interpose on a symbol can
identify themselves as interposers (ld(1) -z interpose), or this magically
happens when an object is preloaded (ld.so.1(1) LD_PRELOAD).  This 
identification is employed by all the system malloc libraries to ensure only
one malloc implementation is used within a process. 

There is of course, a potential for disruption.  If we change to a model where
our libraries are directly bound, non-explicit interposition, will be avoided.
And, there's probably a few applications that work because of non-explicit
interposition (whether the interposition was intentional is another matter).

There are a number of stepping stones that have been, and still have to be,
put in place to realize directly binding the OSNet.

  .	Numerous bug fixes have been required to ensure explicit interposition
	occurs in a directly bound environment (4790194, 4774727, 4918310 ...)

  .	Greater flexibility is preventing direct bindings where a single
	implementation must exist has been provided (4850703), and this
	mechanism has been applied to our malloc libraries (4790202).

  .	The ability to better inspect applications bindings, especially to be
	able to identify direct bindings has been introduced with lari(1),
	see 4716275.

  .	The ability to preserve interfaces, while moving implementations is
	critical to providing a stable directly bindable environment.
	Per-symbol filtering, added with 4939565 (and see 4947158), goes a long
	way to providing this.

  .	The OSNet consolidation should be hardened in preparation for enabling
	direct bindings - duplicate symbol definitions should be removed where
	appropriate, or non-direct binding flags should be set where
	interposition is required.  These requirements have been integrated with
	6455532.

N/A

N/A