On Sat, 20 Aug 2005, Marc Aurele La France wrote:
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.
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
(potentiall 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.
Vendors would need to handle the "b)" case in their drivers.
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".
The "a)" case can be made to fail cleanly by having the old names being
functions that print out an informative message and exit.
The "b)" case could be handled like this:
#define VBEExtendedInit(a,b,c) \
(xf86LoaderCheckSymbol("newVBEExtendedInit") : \
newVBEExtendedInit(a,b,c) ?
(FatalError(INFORMATIVE_MESSAGE), NULL))
However, I think it's better to control module loading from the module
public headers, thus incorporating interface version checking with the
interface definition and avoiding the need to resort to tricks like this.
The attached (against current CVS) is a nearly finalised implementation of
the above. I've tested this with various versions of the vbe and vesa
modules, and it works as expected.
However, what I have here is _very_ specific to the problem at hand, that
being dealing with the consequences of changing the vbe InfoBlock structures.
This means that I only changed those drivers (i810 (i830, actually), savage,
sis, vesa and xgi) that actually care about the layout of these structures.
For these drivers, both "a)" and "b)" are enforced.
For other "vbe'ing" drivers, such as my own atimisc, "b)" is not enforced
(good), but "a)" is, unnessarily. That's because, as I have it here,
vbeSetup() doesn't have a reasonable way of detecting its parent module
doesn't peek/poke into the changed structures. So, I'm left with an
assymmetric implementation.
The options, at this point, are ...
1) Leave this as is;
2) Change all vbe'ing drivers. This would put them all on the same footing
WRT enforcing "a)" and "b)".
3) Make vbeSetup() smarter. One possibility here is to check version
requirements only if the parent references, say, VBEGetModeInfo(),
although this wouldn't work for the combined i810 module, where only the
i830 code path looks into these structures.
I don't have a strong preference, except to commit a finalised version of
this change all in one go, to eliminate exposure.
The more I think about this, the more I'm inclined to renege on my lack of
preference.
"3)" would require the vbe module to know about a fairly specific aspect of
driver internals.
In "1)", something akin to the reverse happens, i.e. the driver would need to
be aware of what specifically in the vbe module became incompatible. This
before even loading it.
Design-wise, "2)" is the sole alternative that preserves layering. Applying
"2)" to the more general problem of inter-module versioning also means that
any incompatibility is to be considered as one of the entire module where it
occurs, rather than of only part, or some aspect, of this same module. This,
in retrospect, seems obvious.
So, barring objections here, I'll be proceeding with "2)".
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
