Index: [thread] [date] [subject] [author]
  From: Jon M. Taylor <taylorj@gaia.ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Thu, 29 Jul 1999 14:20:58 -0700 (PDT)

Re: 2nd prerelease: EXTENSION HOWTO and EHelper

On Wed, 28 Jul 1999, Brian S. Julin wrote:

> 
> 
> I finally got things kludged together enough to do a prerelease.

[snip]
 
> Third, for some reason for extension foobar under X, which
> was my test environment, "display-x-foobar" gets loaded
> before "generic-linear-8" and "generic-stubs", which makes
> it kinda hard to overload the generic-* libraries... 

	Yep.  I had the same problem in GGIMesa.  LibGG apparently tries to
extend the GGI_DISPLAY target variable and load that first, regardless of the
order of the libraries listed in the .conf files.  What I had to do to fix
this was to change the behavior of the sublibs so that they could go off, try
to load a valid rendering subsystem underneath themselves, and if sucessful
(checked by seeing if function pointer hooks == NULL) the top-level sublib
loader would stop enumerating and trying to load any more sublibs.  
Basically an in-order tree traversal.

	This way, the generic-stubs and generic-linear-* libraries will not
even be looked at unless the display-x-foobar returns without having
successfuly created a valid target-specific rendering setup, which is as it
should be.  But it requires a bit more intelligence in the sublibs themselves
to properly manage the sublibs underneath themselves.  If at any level it is
possible for a loaded sublib to partially implement the interface of the
level above it, this must be explicitly accounted for or everything will get
thrown away when the sublib does not implement the _whole_ interface.  
All I had to deal with was the setup below, which was not too complex on 
its face, and it still took quite a bit of tweaking in order to get 
everything to coordinate properly.

	The sublib tree for GGIMesa on my system looked like this:

GGIMesa top level
  generic-stubs-mesa
  generic-linear-*-mesa
  display-fbdev-mesa
    tgt-fbdev-kgicon-generic-mesa
      tgt-fbdev-kgicon-savage4-mesa

	So, when GGIMesa was attached to a visual, it would first check to 
see if a target-specific library was present and immediately fall back to 
generic-stubs or generic-linear if not.  If one was present (fbdev only 
for now), it would check to see if a KGIcon driver was loaded.  If not, 
it would look to see if the plain fbdev driver had an accel lib (like the 
LibGGI matroxfb accel driver).  I never coded any support for this since 
I have no matrox card, but the framework was present.  If this also 
failed, there would be nothing for the fbdev "driver" to do, so it would 
exit without hooking any of the API calls, the top-level GGIMesa GetAPI() 
call would see this and once again it would fall back to stubs.

	If a KGIcon driver was present, the fbdev driver would load the 
kgicon "accel" helper, which would in turn do more or less what the fbdev 
library above it did - probe for a specific driver type, see if an 
associated helper library was present, and bail out if not since there 
would be nothing for the kgicon helper to do, which would jump back to 
the fbdev target, which would in turn jump back to the top level without 
having hooked a valid driver, which would once again fall back to stubs.  
Only if the kgicon helper found a Savage4 (which it had to probe for 
itself!) would it load the Savage4 helper which would hook the API calls, 
jump back to the kgicon helper, jump back from there to the fbdev target, 
and jump back from there to the top-level which would _NOT_ load the 
stubs or generic-linear libraries (or any others), since the fbdev driver 
returned having hooked a valid rendering system.

> the latter two are loaded in the right order so that stubs
> is overloaded by linear-8.  My guess is this has nothing
> to do with the foobar extension's code though...

	Yes and no.  The primary reason is that LibGG tries to load a
target-specific extension sublib first.  The secondary reason does have to do
with the extension code, however - as you can see, sometimes the process of
autodetection and intelligent loading of the hierarchical library system
cannot be done correctly without adding more intelligence to the extension
code.

Jon 

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed

Index: [thread] [date] [subject] [author]