[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