Re: [PATCH xserver] sdksyms: Tighten up the symbols we add to the magic table

2017-03-16 Thread Adam Jackson 
On Thu, 2017-03-16 at 03:04 +, Emil Velikov wrote:

> Your earlier reply mentioned that [you think that] xf86-video-nested
> was a mistake without providing any justification why. It would be
> great to have some information what is broken and/or architecturally
> wrong with it or the other components mentioned just above.
> 
> IIRC the only issues [with Xorg] pointed out so far were a) memory
> consumption and b) providing a config file [via command line as
> non-root]. With the latter being resolved IIRC.

xfree86 assumes that there's actual silicon (or something very willing
to fake it, like vmwgfx or qxl) backing the screen, and that that
device is in some way bound to the system's console. The first X-under-
wayland driver was an xfree86 driver, and making that work involved
changing the xfree86 core in a bunch of places to _stop_ making those
assumptions (don't look at the pci bus, don't try to VT switch, get
input from this other source, etc.). Why bother undoing those
assumptions when you have a base class that makes none of them?

A vaguely appropriate analogy (if we're considering only OpenGL) would
be mesa/src/gallium. It's this whole other abstraction layer and maybe
it buys you some things, but mesa/src/mesa is the real GL core and one
does not need gallium to make a GL driver. You'd only use it if there
were any benefit.

And for hw/xfree86 there kind of isn't. Most of ScrnInfoRec (xfree86's
subclass of ScreenRec) is stuff that should reasonably be in the base
class. That it isn't is largely an artifact of the old regime, where
the X Consortium releases were actually pretty boring, and though
XFree86 was the thing most people ran there was not a lot of interest
or effort in reducing the diff between the two, or moving useful
functionality up to the dix layer.

Which means the real goal, in terms of code annihilationism, is to rely
on xfree86 less not more.

We already have three nested servers. Xephyr and Xnest legitimately
vary in their approach, one is an X11 proxy and the other owns its own
pixels. Xdmx is largely a clever variation on Xnest, and they should
converge in the future. What benefit does a nested driver for xfree86
add? Why increase dependence on a midlayer that shouldn't exist, and
whose value is in assumptions that don't apply?

Hence also my bafflement at people trying to build xfree86 on cygwin.
You don't town the display, you don't own the input devices, why try to
build a server that assumes those things? Darwin you could _maybe_
argue for, if >console at the login prompt still drops you to a text
login, but even that's a reach because you'd still need to write new
video and input drivers.

- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] sdksyms: Tighten up the symbols we add to the magic table

2017-03-15 Thread Emil Velikov 
On 13 March 2017 at 17:07, Adam Jackson  wrote:
> On Fri, 2017-03-10 at 23:23 +, Emil Velikov wrote:
>> > On 10 March 2017 at 16:32, Adam Jackson  wrote:
>> > I neither expect nor want this to happen. dummy might have some minor
>> > utility, but the nested driver I think is a mistake, and I would not
>> > consider its availability as a reason to drop Xnest or Xephyr.
>> >
>>
>> Pardon the silly question, but going through the discussions did now help 
>> much.
>> Do we have a list of features/bugs for/against each suggestion ?
>
> I don't know what you mean by "each suggestion".
>
Pardon about that one - silly me being too brief, as always.

With "each suggestion" i meant "Xnest/Xephyr/xf86-video-{dummy,nested}
and other DDX/video drivers mentioned in this and earlier
discussions". Some information even if it covers only some of these
will also be appreciated.

>> I mean if there is somethings clearly defined, divide and conquer is the way.
>> Atm everything seems quite magical, unless one has extensive prior
>> experience with the DDXen and respective drivers.
>
> I don't know what you mean by "everything".
>
Your earlier reply mentioned that [you think that] xf86-video-nested
was a mistake without providing any justification why. It would be
great to have some information what is broken and/or architecturally
wrong with it or the other components mentioned just above.

IIRC the only issues [with Xorg] pointed out so far were a) memory
consumption and b) providing a config file [via command line as
non-root]. With the latter being resolved IIRC.

There's surely something else which has been pointed out/comes to your
mind, but is not obvious without spending 30+ minutes searching for
and/or through threads for the details.

Having those clearly defined, albeit overdue, is what we want, right ?

Thanks
Emil
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] sdksyms: Tighten up the symbols we add to the magic table

2017-03-13 Thread Adam Jackson 
On Fri, 2017-03-10 at 23:23 +, Emil Velikov wrote:
> > On 10 March 2017 at 16:32, Adam Jackson  wrote:
> > I neither expect nor want this to happen. dummy might have some minor
> > utility, but the nested driver I think is a mistake, and I would not
> > consider its availability as a reason to drop Xnest or Xephyr.
> > 
> 
> Pardon the silly question, but going through the discussions did now help 
> much.
> Do we have a list of features/bugs for/against each suggestion ?

I don't know what you mean by "each suggestion".

> I mean if there is somethings clearly defined, divide and conquer is the way.
> Atm everything seems quite magical, unless one has extensive prior
> experience with the DDXen and respective drivers.

I don't know what you mean by "everything".

- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] sdksyms: Tighten up the symbols we add to the magic table

2017-03-10 Thread Emil Velikov 
On 10 March 2017 at 16:32, Adam Jackson  wrote:
> On Wed, 2017-03-08 at 17:44 +, Jon Turney wrote:
>> On 06/03/2017 22:20, Adam Jackson wrote:
>> > On Mon, 2017-03-06 at 18:23 +, Jon Turney wrote:
>> >
>> > > Unfortunately, one of the possible definitions of _X_EXPORT in
>> > > Xfuncproto.h is empty, in which case, this leaves us with nothing in
>> > > sdksyms.c
>> >
>> > Though this be true, I'm not sure how it can matter. We only build
>> > xfree86 on systems where _X_EXPORT expands to something non-empty. And
>>
>> It has been possible to build an xfree86 server for Cygwin since this
>> [1] patchset.
>>
>> This might even turn out to be useful, if the idea of removing Xephyr,
>> Xnest and Xvfb servers [2], to be replaced by invoking the Xorg server
>> with the xf86-video-dummy or xf86-video-nested drivers, ever happens.
>
> I neither expect nor want this to happen. dummy might have some minor
> utility, but the nested driver I think is a mistake, and I would not
> consider its availability as a reason to drop Xnest or Xephyr.
>
Pardon the silly question, but going through the discussions did now help much.
Do we have a list of features/bugs for/against each suggestion ?

I mean if there is somethings clearly defined, divide and conquer is the way.
Atm everything seems quite magical, unless one has extensive prior
experience with the DDXen and respective drivers.

-Emil
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] sdksyms: Tighten up the symbols we add to the magic table

2017-03-10 Thread Adam Jackson 
On Wed, 2017-03-08 at 17:44 +, Jon Turney wrote:
> On 06/03/2017 22:20, Adam Jackson wrote:
> > On Mon, 2017-03-06 at 18:23 +, Jon Turney wrote:
> > 
> > > Unfortunately, one of the possible definitions of _X_EXPORT in
> > > Xfuncproto.h is empty, in which case, this leaves us with nothing in
> > > sdksyms.c
> > 
> > Though this be true, I'm not sure how it can matter. We only build
> > xfree86 on systems where _X_EXPORT expands to something non-empty. And
> 
> It has been possible to build an xfree86 server for Cygwin since this 
> [1] patchset.
> 
> This might even turn out to be useful, if the idea of removing Xephyr, 
> Xnest and Xvfb servers [2], to be replaced by invoking the Xorg server 
> with the xf86-video-dummy or xf86-video-nested drivers, ever happens.

I neither expect nor want this to happen. dummy might have some minor
utility, but the nested driver I think is a mistake, and I would not
consider its availability as a reason to drop Xnest or Xephyr.

- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] sdksyms: Tighten up the symbols we add to the magic table

2017-03-08 Thread Jon Turney 

On 06/03/2017 22:20, Adam Jackson wrote:

On Mon, 2017-03-06 at 18:23 +, Jon Turney wrote:


Unfortunately, one of the possible definitions of _X_EXPORT in
Xfuncproto.h is empty, in which case, this leaves us with nothing in
sdksyms.c


Though this be true, I'm not sure how it can matter. We only build
xfree86 on systems where _X_EXPORT expands to something non-empty. And


It has been possible to build an xfree86 server for Cygwin since this 
[1] patchset.


This might even turn out to be useful, if the idea of removing Xephyr, 
Xnest and Xvfb servers [2], to be replaced by invoking the Xorg server 
with the xf86-video-dummy or xf86-video-nested drivers, ever happens.


[1] https://lists.x.org/archives/xorg-devel/2012-April/030281.html
[2] https://lists.x.org/archives/xorg-devel/2012-March/030059.html


we rely on it expanding to something non-empty because we build the
rest of the server with hidden visibility, so we need a positive way to
declare that a symbol is exported; if the system does not have this
facility, then the server isn't going to export the correct set of
symbols to the drivers anyway.


Well, that's not absolutely essential, I mean, sdksyms just ensures that 
symbols we want to export are actually referenced and so present in Xorg.


But yeah, at the moment _X_EXPORT expands to nothing and 
-Wl,--export-all is used on Cygwin, which is wrong, strictly speaking, 
as that makes it possible to build a driver which uses a symbol it 
shouldn't.


So, I guess I need to look at doing this properly with 
__attribute__((dllexport|dllimport)).


___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] sdksyms: Tighten up the symbols we add to the magic table

2017-03-06 Thread Adam Jackson 
On Mon, 2017-03-06 at 18:23 +, Jon Turney wrote:

> Unfortunately, one of the possible definitions of _X_EXPORT in 
> Xfuncproto.h is empty, in which case, this leaves us with nothing in 
> sdksyms.c

Though this be true, I'm not sure how it can matter. We only build
xfree86 on systems where _X_EXPORT expands to something non-empty. And
we rely on it expanding to something non-empty because we build the
rest of the server with hidden visibility, so we need a positive way to
declare that a symbol is exported; if the system does not have this
facility, then the server isn't going to export the correct set of
symbols to the drivers anyway.

- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] sdksyms: Tighten up the symbols we add to the magic table

2017-03-06 Thread Jon Turney 

On 16/02/2017 19:00, Adam Jackson wrote:

The code as written would match anything declared extern. _X_EXPORT is
what we really mean here. That's a macro, so check for what it expands
to and skip if not found.
---
 hw/xfree86/sdksyms.sh | 4 
 1 file changed, 4 insertions(+)

diff --git a/hw/xfree86/sdksyms.sh b/hw/xfree86/sdksyms.sh
index cf26892..10909d0 100755
--- a/hw/xfree86/sdksyms.sh
+++ b/hw/xfree86/sdksyms.sh
@@ -343,6 +343,10 @@ BEGIN {
n = 1;
 }

+# only match _X_EXPORT
+if ($n !~ /^(__attribute__..visibility..default|__global)/)
+next;
+
# skip attribute, if any
while ($n ~ /^(__attribute__|__global)/ ||
# skip modifiers, if any



Unfortunately, one of the possible definitions of _X_EXPORT in 
Xfuncproto.h is empty, in which case, this leaves us with nothing in 
sdksyms.c


This would be much easier if we could use -fdirectives-only, but I guess 
this needs to be cpp-agnostic.


Not sure how to fix this short of having a define to make Xfuncproto.h 
not define the _X_EXPORT macro, and turning that on when sdksyms.sh 
invokes cpp, and having sdksyms.sh recognize a literal X_EXPORT...


___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] sdksyms: Tighten up the symbols we add to the magic table

2017-02-16 Thread Peter Hutterer 
On Thu, Feb 16, 2017 at 02:00:03PM -0500, Adam Jackson wrote:
> The code as written would match anything declared extern. _X_EXPORT is
> what we really mean here. That's a macro, so check for what it expands
> to and skip if not found.
> 
> Signed-off-by: Adam Jackson 
> ---
>  hw/xfree86/sdksyms.sh | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/hw/xfree86/sdksyms.sh b/hw/xfree86/sdksyms.sh
> index cf26892..10909d0 100755
> --- a/hw/xfree86/sdksyms.sh
> +++ b/hw/xfree86/sdksyms.sh
> @@ -343,6 +343,10 @@ BEGIN {
> n = 1;
>  }
>  
> +# only match _X_EXPORT
> +if ($n !~ /^(__attribute__..visibility..default|__global)/)
> +next;

Reviewed-by: Peter Hutterer 

> +
>   # skip attribute, if any
>   while ($n ~ /^(__attribute__|__global)/ ||
>   # skip modifiers, if any

fwiw, just a line below here there's still a mention of _X_EXPORT which is
a noop:

  $n ~ /^\*?(unsigned|const|volatile|struct|_X_EXPORT)$/ ||

feel free to remove that one with my rev-by.

Cheers,
   Peter
 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xserver] sdksyms: Tighten up the symbols we add to the magic table

2017-02-16 Thread Adam Jackson 
The code as written would match anything declared extern. _X_EXPORT is
what we really mean here. That's a macro, so check for what it expands
to and skip if not found.

Signed-off-by: Adam Jackson 
---
 hw/xfree86/sdksyms.sh | 4 
 1 file changed, 4 insertions(+)

diff --git a/hw/xfree86/sdksyms.sh b/hw/xfree86/sdksyms.sh
index cf26892..10909d0 100755
--- a/hw/xfree86/sdksyms.sh
+++ b/hw/xfree86/sdksyms.sh
@@ -343,6 +343,10 @@ BEGIN {
n = 1;
 }
 
+# only match _X_EXPORT
+if ($n !~ /^(__attribute__..visibility..default|__global)/)
+next;
+
# skip attribute, if any
while ($n ~ /^(__attribute__|__global)/ ||
# skip modifiers, if any
-- 
2.9.3

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel