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.coopersm...@oracle.com
Oracle Solaris Engineering - https://blogs.oracle.com/solaris
