is _X_INLINE still needed

[Alan Coopersmith]

On 2/2/24 03:42, Enrico Weigelt, metux IT consult wrote:
> On 01.02.24 19:29, Alan Coopersmith wrote:
> 
> Hi Alan,
> 
>>> Which ones are public ?
>>
>> 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'".

In the stable branch, you can see it run in:
https://gitlab.freedesktop.org/xorg/xserver/-/blob/server-21.1-branch/hw/xfree86/Makefile.am?ref_type=heads

>> or which the one of the meson.build files installs to the $DESTDIR.
> 
> the stuff landing in $installdir/xorg ?

Yes.

>> I was mainly thinking of clients, but there are still a lot of out-of-tree
>> driver modules for Xorg, including a few outside of our control.
> 
> IIRC, the driver api/abi breaks some times, that's why distros have
> versioned dependencies.

Yes, in what used to be minor releases (1.n -> 1.n+1) and what are now
major releases (21.x -> 24.x).   But no one is planning on any such
releases for the Xorg server that I've seen.

> It seems we're carrying a lot of historically stuff / technical debt in
> here. Can we start some formal API definitions and start deprecating old
> stuff ? What I'd like to get out first is things that are pretty much
> libc wrappers like GenerateRandomData().
> 
> IMHO, at some point we have to choose between coninuous quality decaday
> or breaking extensions / drivers. Both are ugly, but I believe risking
> some (compile-time) breaks here and there are better than code rotting.
> 
> Maybe we could do some official announcement on *planning* some API
> deprecations and calling all external projects (eg. tigervnc) to join
> into the discussion what/when/how to do it. 

Theoretically, that is all possible.  Realistically though, none of it
is, because no one is working on a new release of the Xorg server, just
popping out the occasional security patch as necessary - with no maintainer
for Xorg, it's mostly frozen in place now.

 > 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.  We split the drivers out
because the release cycles for them were not aligned with the X servers
release cycle and we had no reason to tie them to it.

The Linux kernel can do this because it has active maintainers and a
regular release cycle.  Xorg has neither.

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