is _X_INLINE still needed

Alan Coopersmith alan.coopersmith at oracle.com
Wed Feb 7 01:29:27 UTC 2024


On 2/5/24 06:27, Enrico Weigelt, metux IT consult wrote:
> On 02.02.24 18:33, Alan Coopersmith wrote:
>>>> For the Xorg server, the ones listed in
>>>> https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/hw/xfree86/sdksyms.sh
>>>
>>> is this script actually used somewhere ?
>>>
>>> It looks like some test script - should we include it into some
>>> test stage in the build system ?
>>
>> It's run as part of the build process in the branches that still build
>> with autoconf - looking now I see it seems to have been dropped in the
>> meson builds, and replaced by "xorg_c_args += '-DXORG_NO_SDKSYMS'".
> 
> What does -DXORG_NO_SDKSYMS (or leaving it off) actually do ?
> Grepped through the code (master branch) and it doesn't really make
> sense to me.

The key bit is in hw/xfree86/loader/loader.c:

#ifndef XORG_NO_SDKSYMS
extern void *xorg_symbols[];
#endif

So if it's not defined, then it links in the array of external symbols
built by sdksyms.sh which ensures they're all defined in the Xorg server,
even if they're not called from any other file linked into the server,
so that we could define functions used in the external ABI that weren't
used internally.

If I remember correctly, this was to workaround linker & libtool wonkiness
on some platforms, which may be why no one has complained about it being
dropped when building with meson on current platforms - see the Dec 2008 commits
listed on:
https://gitlab.freedesktop.org/xorg/xserver/-/commits/master/hw/xfree86/loader/loader.c


>>  > In the long run, I'd really
>>  > prefer getting all drivers and extensions in-tree and declare the API
>>  > volatile - quite like we're doing it in the linux kernel.
>>
>> That would guarantee we never release a new version of Xorg given how
>> many drivers just no longer compile at all.
> 
> Which ones, for example ?
> I could take care of those that I've got actual HW for.

The list I compiled 2 years ago is still mostly up-to-date:
https://lists.x.org/archives/xorg-devel/2022-January/058800.html
(the rest of the thread landed on
https://lists.x.org/archives/xorg-devel/2022-February/thread.html ).

Honestly, some of these I don't know if anyone in the world still has
hardware for - I certainly have no hardware for the drivers I've done
releases of lately - I just send them out into the world and get no
complaints and don't know if that's because they work perfectly or if
they've never been run.

>> The Linux kernel can do this because it has active maintainers and a
>> regular release cycle.  Xorg has neither.
> 
> We should try to attact more folks. Maybe an open call on various
> Linux/Unix sites (eg. phoronix) ?

Everyone who reads phoronix has already seen plenty of times that Xorg
is lacking in maintainers - we don't need to generate another 15 page
forum thread there with everyone arguing and no one doing anything.

-- 
         -Alan Coopersmith-                 alan.coopersmith at oracle.com
          Oracle Solaris Engineering - https://blogs.oracle.com/solaris



More information about the xorg-devel mailing list