[PATCH xserver 3/4] dix: Convert ResourceClientBits to a variable

Adam Jackson ajax at redhat.com
Tue May 3 17:32:37 UTC 2016

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

More information about the xorg-devel mailing list