Are the per ABI module directories relevant for ABI version checking?

[callmetango]

When looking for how to solve Use Semantic Versioning instead of 25.0.x.x · Issue #646 · X11Libre/xserver I stumbled upon the fact that there are different ABI versions for the following classes:

#define ABI_CLASS_ANSIC		"X.Org ANSI C Emulation"
#define ABI_CLASS_VIDEODRV	"X.Org Video Driver"
#define ABI_CLASS_XINPUT	"X.Org XInput driver"
#define ABI_CLASS_EXTENSION	"X.Org Server Extension"

I found this in L56 - xserver/hw/xfree86/common/xf86Module.h at 5c3ce08b · X11Libre/xserver.

When drilling down further, it occured to me that the four version classes are used when checking for the compatibility of the module to load in L443 - xserver/hw/xfree86/loader/loadmod.c at 5c3ce08b · X11Libre/xserver and the following.

So do I get it right that if for example the xf86-video-intel module has to be loaded then the version information struct of the class ABI_CLASS_VIDEODRV is checked against the server version information in ABI_VIDEODRV_VERSION? If so, how come the per-ABI driver directories like /usr/lib/xorg/modules/xlibre-25... into play and where?

Wouldn't it be closer to the implementation of the version compatibility checking to reflect the major numbers of the ABI_..._VERSION defines in the file path? Like given a

#define ABI_VIDEODRV_VERSION	SET_ABI_VERSION(28, 0)

then having a /usr/lib/xorg/modules/drivers/28/... path for the drivers that are compiled against/compatible with the ABI_VIDEODRV_VERSION 28?

@metux @ONykyf @stefan11111 What do you think?

[ONykyf]

@callmetango @metux @stefan11111 IMO, if we accept that any increase of ABI_ANSIC_VERSION, ABI_VIDEODRV_VERSION, ABI_VIDEODRV_XINPUT, or ABI_EXTENSION_VERSION (if any occurs in the future) results in an increase of module_abi_tag (but not vice versa), then we may stick to the current scheme with /usr/lib/xorg/modules/xlibre-25.X and not introduce a zoo with four differently numbered directories.

[stefan11111]

@metux Is ABI_CLASS_ANSIC still used by drivers?

[metux]

@metux Is ABI_CLASS_ANSIC still used by drivers?

Not directly.
Note we don't even have any kind of clear definition what's making up some particular abi class.
And even if we wanted to fix that, we'd quickly end up with many cases that aren't actually easy to classify.

IMHO, this all doesn't make any sense at all anymore. Let's just have one ABI version.
And the rule is: whenever driver recompile becomes necessary, increase this ABI version - and no extra backwards compatibility.
(except for the special Nvidia hacks)

[callmetango]

@metux So you propose to merge these:

#define ABI_CLASS_ANSIC		"X.Org ANSI C Emulation"
#define ABI_CLASS_VIDEODRV	"X.Org Video Driver"
#define ABI_CLASS_XINPUT	"X.Org XInput driver"
#define ABI_CLASS_EXTENSION	"X.Org Server Extension"

into one version component?

[metux]

actually I propose not really caring about them anymore and instead do all via the major version

[callmetango]

That sounds like a good simplification. I assume that we will then only have one version number and use this to determine compatibility, correct?