On Tue, Aug 09, 2005 at 10:45:15AM -0600, Marc Aurele La France wrote: >Hi. > >I've something here I'd like to discuss. > >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. If we were to start adding module interface version checking for other shared module interfaces, that would head off similar issues in the future. 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. David _______________________________________________ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
