Quoting Adrian Chadd <adr...@freebsd.org> (from Mon, 10 Feb 2014
17:24:09 -0800):
On 10 February 2014 17:07, James Gritton <ja...@freebsd.org> wrote:
So is it worthwhile to add a new jail parameter called "insecure" (or
somesuch)? That way you could easily add the encapsulation without
any of the security. The other vibe I'm getting is not to do
anything. Either way, it sounds like the Xorg-enabling patch will
remain a patch - not seeing a lot of buy-in here.
I'm not against more optional and obscure holes if they have a use; I
just call that "a fine-grained capabilities model."
I'd rather it stay a patch. IMHO the only viable solution is to create
a sandboxable API for this DRI/IO-MMU stuff to, well, DRI via.
So hm. Can you actually run clients in different jails, but have them
access the same DRI window(s)? Or does running a client in a jail
force it to go all over the socket(s) and not via DRI?
I would assume that a client somehow determines if he is rendering
local or remotely. If he is doing it local (= in the same "container"
as the X server) it uses DRI. I do not expect that two jails with
"allow.kmem" allow to use DRI to the same X server, but I haven't
tested it, so take it only as a gut-feeling.
Bye,
Alexander.
--
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
