On Tue, 2016-05-03 at 17:35 +0200, Mark Kettenis wrote: > Hmm. This is marked as _X_EXPORT, so presumably part of the driver > ABI. Exporting variables like this is generally a bad idea, at least > for ELF DSOs. Copy relocations and all that.
It would be part of the driver ABI, yes, and I'm certainly sympathetic to avoiding exposing variables directly as a matter of style. But it very much wouldn't be the first, and in this particular case I don't think it matters much. Relocations to variables defined in the server seem to end up as direct relocs not copies: dmt:~/git/xserver% eu-readelf -r hw/xfree86/dixmods/.libs/libglx.so | grep noGlx 0x0000000000240d40 X86_64_64 000000000000000000 +0 noGlxExtension Even if they were copy relocs, I believe that only affects initializaton performance as opposed to runtime. Perhaps there's some other negative property I'm missing here, please do enlighten me if so. > So isn't it better to keep this as a function call? You'd still make > it return a precalculated value instead of doing the ilog2 on each > call. Marking it as a "pure" function in addition to that should fine > too. I guess the question is what API the callers need, and the answer seems to be CLIENT_ID(), CLIENT_BITS(), and possibly RESOURCE_ID_MASK and CLIENTOFFSET; at least, those are the matches I find outside of the resource system itself, in xserver itself. I have some difficulty imagining out-of-tree code that would need to be much more intimate with the resource sytem than CLIENT_ID() and CLIENT_BITS(). I'll withdraw this for the moment and conjure up something better. - ajax _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
