glX TLS disabled by default?

[tom fogal-3]

Is there any reason TLS for glX is disabled by default?  Most systems
support TLS these days, do they not?  Further, I'm not sure if this is
shared but my opinion is that the default configurations should cater
to the common case.

-tom


From dd4f53ad4aa0001e0bf0837fca2915bbc066f1ef Mon Sep 17 00:00:00 2001
From: Tom Fogal <tfogal@...>
Date: Sat, 7 Nov 2009 12:48:01 -0700
Subject: [PATCH] Enable glX TLS by default.

Not actually sure the patch itself is right; is the @<:@ stuff
some sort of markup?  Or escapes of some kind?  Or.. ?
---
 configure.ac |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index cc588d5..9a5875e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -638,10 +638,10 @@ dnl
 dnl More DRI setup
 dnl
 AC_ARG_ENABLE([glx-tls],
-    [AS_HELP_STRING([--enable-glx-tls],
-        [enable TLS support in GLX @<:@default=disabled@:>@])],
+    [AS_HELP_STRING([--disable-glx-tls],
+        [disable TLS support in GLX @<:@default=enabled@:>@])],
     [GLX_USE_TLS="$enableval"],
-    [GLX_USE_TLS=no])
+    [GLX_USE_TLS=yes])
 dnl Directory for DRI drivers
 AC_ARG_WITH([dri-driverdir],
     [AS_HELP_STRING([--with-dri-driverdir=DIR],
--
1.6.3.3


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Ian Romanick-4]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

tom fogal wrote:
> Is there any reason TLS for glX is disabled by default?  Most systems
> support TLS these days, do they not?  Further, I'm not sure if this is
> shared but my opinion is that the default configurations should cater
> to the common case.

I vaguely recall there being some interaction with the X server.  If
Mesa is built for TLS, then the X server must also be built for TLS.  If
a non-TLS X server loads a TLS Mesa driver, it will fail with unresolved
symbols.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkr2EOgACgkQX1gOwKyEAw8KrQCdFYN15ZgyHHYJZV/sbX3+2Qv8
hmMAoJQp4FtqMNqm0nHIX5Dl4ba07zzA
=yHxS
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Adam Jackson]

On Sat, 2009-11-07 at 16:29 -0800, Ian Romanick wrote:

> tom fogal wrote:
> > Is there any reason TLS for glX is disabled by default?  Most systems
> > support TLS these days, do they not?  Further, I'm not sure if this is
> > shared but my opinion is that the default configurations should cater
> > to the common case.
>
> I vaguely recall there being some interaction with the X server.  If
> Mesa is built for TLS, then the X server must also be built for TLS.  If
> a non-TLS X server loads a TLS Mesa driver, it will fail with unresolved
> symbols.

There's no intrinsic reason that the GLX loader couldn't support both, I
suppose, but it would be kind of lame.  There's still an interaction
between TLS and selinux that prevents me from shipping it, but I'm sure
that's fixable.

Mesa does attempt to be buildable for more systems than the X server
though.  I don't know if (for example) OpenVMS has sensible TLS support.

- ajax


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mark Kettenis]

> From: Adam Jackson <ajax@...>
> Date: Mon, 09 Nov 2009 10:51:13 -0500
>
> On Sat, 2009-11-07 at 16:29 -0800, Ian Romanick wrote:
>
> > tom fogal wrote:
> > > Is there any reason TLS for glX is disabled by default?  Most systems
> > > support TLS these days, do they not?  Further, I'm not sure if this is
> > > shared but my opinion is that the default configurations should cater
> > > to the common case.
> >=20
> > I vaguely recall there being some interaction with the X server.  If
> > Mesa is built for TLS, then the X server must also be built for TLS.  If
> > a non-TLS X server loads a TLS Mesa driver, it will fail with unresolved
> > symbols.
>
> There's no intrinsic reason that the GLX loader couldn't support both, I
> suppose, but it would be kind of lame.  There's still an interaction
> between TLS and selinux that prevents me from shipping it, but I'm sure
> that's fixable.
>
> Mesa does attempt to be buildable for more systems than the X server
> though.  I don't know if (for example) OpenVMS has sensible TLS support.

Is the TLS you're talking about here an abreviation for Thread Local
Storage?  If so then even OpenBSD doesn't have (sensible) support for
it.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[tom fogal-3]

Mark Kettenis <mark.kettenis@...> writes:
> > From: Adam Jackson <ajax@...>
> > Date: Mon, 09 Nov 2009 10:51:13 -0500
> >
> > On Sat, 2009-11-07 at 16:29 -0800, Ian Romanick wrote:
> >
> > > tom fogal wrote:
> > > > Is there any reason TLS for glX is disabled by default?
[snip]

> > > I vaguely recall there being some interaction with the X server.
> > > If Mesa is built for TLS, then the X server must also be built
> > > for TLS. [. . .]
> >
> > There's no intrinsic reason that the GLX loader couldn't support
> > both, I suppose, but it would be kind of lame. [plus selinux issue]
>
> Is the TLS you're talking about here an abreviation for Thread Local
> Storage?  If so then even OpenBSD doesn't have (sensible) support for
> it.

Yes, it is.

In the case that we're building against an X server, is there perhaps
some kind of configure-time test we could do?  Then the Mesa default
could be `autodetect' instead.

-tom

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Dan Nicholson-2]

On Mon, Nov 9, 2009 at 9:52 AM, tom fogal <tfogal@...> wrote:

> Mark Kettenis <mark.kettenis@...> writes:
>> > From: Adam Jackson <ajax@...>
>> > Date: Mon, 09 Nov 2009 10:51:13 -0500
>> >
>> > On Sat, 2009-11-07 at 16:29 -0800, Ian Romanick wrote:
>> >
>> > > tom fogal wrote:
>> > > > Is there any reason TLS for glX is disabled by default?
> [snip]
>> > > I vaguely recall there being some interaction with the X server.
>> > > If Mesa is built for TLS, then the X server must also be built
>> > > for TLS. [. . .]
>> >
>> > There's no intrinsic reason that the GLX loader couldn't support
>> > both, I suppose, but it would be kind of lame. [plus selinux issue]
>>
>> Is the TLS you're talking about here an abreviation for Thread Local
>> Storage?  If so then even OpenBSD doesn't have (sensible) support for
>> it.
>
> Yes, it is.
>
> In the case that we're building against an X server, is there perhaps
> some kind of configure-time test we could do?  Then the Mesa default
> could be `autodetect' instead.

Make it a variable in gl.pc and query it from the xserver configure.

gl.pc:
...
glx_tls = yes

xserver/configure:
if test "x$GLX_USE_TLS" = xauto; then
    GLX_USE_TLS=`$PKG_CONFIG --variable=glx_tls gl`
    test -z "$GLX_USE_TLS" && GLX_USE_TLS=no
fi

Or something like that.

--
Dan

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[tom fogal-3]

Dan Nicholson <dbn.lists@...> writes:

> On Mon, Nov 9, 2009 at 9:52 AM, tom fogal <tfogal@...> wrote:
> > Mark Kettenis <mark.kettenis@...> writes:
> >> > From: Adam Jackson <ajax@...>
> >> > Date: Mon, 09 Nov 2009 10:51:13 -0500
> >> >
> >> > On Sat, 2009-11-07 at 16:29 -0800, Ian Romanick wrote:
> >> >
> >> > > I vaguely recall there being some interaction with the X
> >> > > server.  If Mesa is built for TLS, then the X server must also
> >> > > be built for TLS. [. . .]

[snip]
> > In the case that we're building against an X server, is there
> > perhaps some kind of configure-time test we could do?  Then the
> > Mesa default could be `autodetect' instead.
>
> Make it a variable in gl.pc and query it from the xserver configure.

Sorry, that was ambiguous; I wasn't trying to ask how this might
be done.  I was wondering if the X server already provided this
information in some way Mesa could figure it out.

I imagine someone would have piped up if such support already existed
though, so I guess I should volunteer.

> gl.pc:
> ...
> glx_tls = yes
>
> xserver/configure:
> if test "x$GLX_USE_TLS" = xauto; then
>     GLX_USE_TLS=`$PKG_CONFIG --variable=glx_tls gl`
>     test -z "$GLX_USE_TLS" && GLX_USE_TLS=no
> fi

.. but now that you mention it, wouldn't it be the reverse?  That is,
we'd want the X server to provide a .pc with `tls = something', and
have Mesa query the server's .pc?  I guess it depends on which is
`lower' in the software stack, which I've been assuming is the X server
(correct me?).

-tom


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Ian Romanick-4]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Adam Jackson wrote:

> On Sat, 2009-11-07 at 16:29 -0800, Ian Romanick wrote:
>
>> tom fogal wrote:
>>> Is there any reason TLS for glX is disabled by default?  Most systems
>>> support TLS these days, do they not?  Further, I'm not sure if this is
>>> shared but my opinion is that the default configurations should cater
>>> to the common case.
>> I vaguely recall there being some interaction with the X server.  If
>> Mesa is built for TLS, then the X server must also be built for TLS.  If
>> a non-TLS X server loads a TLS Mesa driver, it will fail with unresolved
>> symbols.
>
> There's no intrinsic reason that the GLX loader couldn't support both, I
> suppose, but it would be kind of lame.  There's still an interaction
> between TLS and selinux that prevents me from shipping it, but I'm sure
> that's fixable.
>
> Mesa does attempt to be buildable for more systems than the X server
> though.  I don't know if (for example) OpenVMS has sensible TLS support.

A TLS loader does support both.  A non-TLS loader only supports non-TLS
drivers.  A TLS driver can only be loaded by a TLS loader.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkr5/NoACgkQX1gOwKyEAw9BQwCdGHPQcLlD4pDqrP13zqs7eY9l
QgwAniIzxfvs9jNCKU1Bo/ndQB2laJP9
=q85k
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Alan Coopersmith]

tom fogal wrote:
> .. but now that you mention it, wouldn't it be the reverse?  That is,
> we'd want the X server to provide a .pc with `tls = something', and
> have Mesa query the server's .pc?  I guess it depends on which is
> `lower' in the software stack, which I've been assuming is the X server
> (correct me?).

Wrong way around - Mesa is built first, the X server build depends on it.

--
        -Alan Coopersmith-           alan.coopersmith@...
         Sun Microsystems, Inc. - X Window System Engineering


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev