Re: Inter-module compatibility

Marc, I don't have any good ideas to suggest to solve this versioning
problem, but FWIW the NVIDIA X driver does not use the vbe module.

Thanks,
- Andy


On Wed, 10 Aug 2005, Marc Aurele La France wrote:

> On Tue, 9 Aug 2005, David Dawes wrote:
> > On Tue, Aug 09, 2005 at 10:45:15AM -0600, Marc Aurele La France wrote:
> >> Our loader scheme has been, and is, reasonably good at dealing with
> >> incompatibilities between modules and the core binary.  But it is not so
> >> good with ensuring modules are compatible with each other.
> 
> >> As a case in point, I am now faced with strong motivation to rework the
> >> three Vbe.*InfoBlock structures currently exported by vbe.h.
> 
> >> Now, it's not my purpose here to get into these motivations, but reworking
> >> these structures would have consequences, one of which I am unsure how to
> >> deal with.  At minimum, what I need to do is ...
> 
> >> a) prevent drivers compiled with the current vbe.h from using a vbe module
> >>   created with the new vbe.h;  and
> >> b) prevent drivers compiled with the new vbe.h from using a vbe module
> >>   created with the current vbe.h.
> 
> >> The hammer approach would suggest bumping the video driver ABI version
> >> number all the way up to 1.0.  (It currently sits at 0.8).  This is
> >> overkill as doing so would prevent the loading of _any_ version 0.* module,
> >> vendor-provided or not, making this "politically" unwise.
> 
> >> Bumping this version number to 0.9 (or leaving it alone) is insufficient as
> >> it prevents neither "a)" nor "b)", so changes would be required.
> 
> >> I've prototyped a way of dealing with "a)".  Basically, I'd have the vbe
> >> module's Setup() function call the common layer to associate a (potentially
> >> extended) XF86ModReqInfo occurrence with the vbe module, which the loader
> >> would then use to check parent modules against.
> 
> >> Dealing with "b)" is trickier.  All I can think of right now would require
> >> changes to the way video drivers load the vbe module, something I'd like to
> >> stay away from, especially in the presence of vendor-provided source and/or
> >> binaries.
> 
> > "b)" could be handled by changing the drivers to specify a vbe module
> > version requirement when loading the vbe module.  I don't think that is
> > unreasonable given that child module version checking is already a part
> > of the loadModule interface.
> 
> Yes.  One issue with this is that it doesn't do anything for vendor-provided
> drivers.
> 
> On the other hand, in this case, this would only need to be done to that
> subset of drivers that actually peek/poke inside the structures to be
> reworked, rather than passing structure occurrences around.  This requirement
> would need to be clearly documented.
> 
> Also, vbe.h could provide a macro to load the vbe module, the idea being to
> make the module control its own loading.
> 
> > If we were to start adding module interface version checking for
> > other shared module interfaces, that would head off similar issues
> > in the future.
> 
> Yes, and how a module is loaded could be controlled by its main header, or
> something like "xxxModule.h".
> 
> > Another option for handling both cases is to change the the name
> > of a required entry point in the vbe module (such as VBEInit and
> > VBEExtendedInit).  There are cases where this will not result in a
> > clean failure (one of the flaws of the current loader's handling of
> > unresolved symbols), but it will fail before attempting to operate with
> > incompatible data structures.
> 
> It would fail, yes, but not with an appropriate message.
> 
> Marc.
> 
> +----------------------------------+-----------------------------------+
> |  Marc Aurele La France           |  work:   1-780-492-9310           |
> |  Academic Information and        |  fax:    1-780-492-1729           |
> |    Communications Technologies   |  email:  [email protected]          |
> |  352 General Services Building   +-----------------------------------+
> |  University of Alberta           |                                   |
> |  Edmonton, Alberta               |     Standard disclaimers apply    |
> |  T6G 2H1                         |                                   |
> |  CANADA                          |                                   |
> +----------------------------------+-----------------------------------+
> XFree86 developer and VP.  ATI driver and X server internals.
> _______________________________________________
> Devel mailing list
> [email protected]
> http://XFree86.Org/mailman/listinfo/devel
>