Re: Inter-module compatibility

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.