is _X_INLINE still needed

[Enrico Weigelt, metux IT consult]

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
info at metux.net -- +49-151-27565287