Re: is _X_INLINE still needed
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.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/solaris
Re: is _X_INLINE still needed
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. Looks like currently defunct. It is yet missing in the meson build ? or which the one of the meson.build files installs to the $DESTDIR. the stuff landing in $installdir/xorg ? Yes. Ok. Just scanned through them an seeing some problems: * seem to contain both internal as well as exported stuff (eg. defines some structs that don't seem to be used anywhere) * pretty much undocumented * for some the licensing is unclear * inconsistant formatting ... Shall we start cleaning that up a bit ? 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. Okay, then let's plan one. 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. I'm now working on it :) And certainly, I'll have to continue to do so, since there just isn't any practically usable replacement, for my use cases, on the horizon. Things like wayland are pretty much unusable for me, since I need X's core features like network transparency. (it could possibly replace the DDX one day, but I'll still need X11 for at least the next decade). > 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 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) ? --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
Re: is _X_INLINE still needed
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
Re: is _X_INLINE still needed
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
Re: is _X_INLINE still needed
On 2/1/24 03:33, Enrico Weigelt, metux IT consult wrote: On 31.01.24 20:22, Alan Coopersmith wrote: Hi Alan, In public headers, I'd say it's still needed, as we've always supported Which ones are public ? For the Xorg server, the ones listed in https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/hw/xfree86/sdksyms.sh or which the one of the meson.build files installs to the $DESTDIR. By applications you mean things like X clients, or also out-of-tree extensions (*1) ? 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. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/solaris
Re: is _X_INLINE still needed
On 01.02.24 12:33, Enrico Weigelt, metux IT consult wrote: made a PR on this: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1264 --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
Re: is _X_INLINE still needed
On 31.01.24 20:22, Alan Coopersmith wrote:
Hi Alan,
In public headers, I'd say it's still needed, as we've always supported
Which ones are public ?
Here's a quick grep of Xserver tree:
nekrad@orion:~/src/xorg/xserver$ git grep _X_INLINE
Xext/security.c:static _X_INLINE const char *
dix/region.c:_X_INLINE static int
dix/region.c:_X_INLINE static Bool
dix/resource.c:static _X_INLINE void
dix/selection.c:static _X_INLINE void
doc/c-extensions:* _X_INLINE: inline this function if possible
(generally obeyed unless
exa/exa_classic.c:static _X_INLINE void *
exa/exa_driver.c:static _X_INLINE void *
exa/exa_mixed.c:static _X_INLINE void *
exa/exa_priv.h:static _X_INLINE Bool
glx/glxserver.h:static _X_INLINE int
glx/glxserver.h:static _X_INLINE int
glx/glxserver.h:static _X_INLINE int
hw/xfree86/modes/xf86Crtc.h:static _X_INLINE xf86OutputPtr
hw/xfree86/modes/xf86Crtc.h:static _X_INLINE xf86CrtcPtr
hw/xfree86/modes/xf86Crtc.h:static _X_INLINE RRCrtcPtr
hw/xfree86/modes/xf86Crtc.h:static _X_INLINE _X_DEPRECATED void
xf86_reload_cursors(ScreenPtr screen) {}
mi/mifpoly.h:static _X_INLINE int
compiling applications against our libraries in strict C89 mode (i.e.
-std=c89, not gnu89 or similar modes that allow extensions),
By applications you mean things like X clients, or also out-of-tree
extensions (*1) ?
1) the only still maintained one I'm aware of is from tigervnc, and
don't believe it's relying on strict c89 mode.
thx,
--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
Re: is _X_INLINE still needed
On 1/31/24 11:01, Enrico Weigelt, metux IT consult wrote: Hello folks, I wonder whether the _X_INLINE still needed (inside X server codebase). It's coming from from xproto (>=7.0.9) and seems to tbe just workaround for old compilers that didn't understand the inline keyword yet. (personally, don't actually recall having one that didn't, must be decades ago :p) Does the xserver still need to support such compilers that don't know the inline keyword yet ? In public headers, I'd say it's still needed, as we've always supported compiling applications against our libraries in strict C89 mode (i.e. -std=c89, not gnu89 or similar modes that allow extensions), and it's easier to leave it in those headers than to announce we're dropping that support. (At least for existing headers, it's probably not necessary in new headers, but we don't create those very often these days.) In the Xserver code base itself, where it's not exposed to other software, I think it's fine to just use a bare "inline", as we already use & require other C99 features in that code base. (Currently the only compiler checks in Xfuncproto.h are for gcc with extensions, or for version 5.5 or later of the Sun cc compiler, which was released as part of Sun Studio 8 in 2003 - and all prior versions of that compiler have been unsupported by its vendor since 2010.) -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/solaris
