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 ?
or which the one of the meson.build files installs to the $DESTDIR.
the stuff landing in $installdir/xorg ?
by the way just found a bug there: XIstubs.h missing include of
X11/Xfuncproto.h
And found something that really bothers me being in a public interface:
extinit.h --> init functions of built-in extensions. Is there really
any valid use case for calling some of these from other (out-of-tree)
extensions ?
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.
Can we at least demand external extensions and drivers being built with
the same toolchain and flags (eg c99) like the xserver itself ?
IMHO, that's pretty much necessary anyways, as soon as some distro uses
some more sophisticated optimizations which can have influence on actual
calling conventions, alignments, etc.
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. 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.
--mtx
--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
