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 > Devel@XFree86.Org > http://XFree86.Org/mailman/listinfo/devel > _______________________________________________ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
