Re: [PATCH v3] Allow fd.o to join forces with X.Org

2018-11-08 Thread Peter Hutterer
On Thu, Nov 08, 2018 at 05:52:08PM -0500, Harry Wentland wrote:
> The leadership of freedesktop.org (fd.o) has recently expressed interest
> in having an elected governing body. Given the tight connection between
> fd.o and X.Org and the fact that X.Org has such a governing body it
> seemed obvious to consider extending X.Org's mandate to fd.o.
> 
> Quite a bit of background on fd.o leading up to this has been covered by
> Daniel Stone at XDC 2018 [2] and was covered really well by Jake Edge of
> LWN [1].
> 
> One question that is briefly addressed in the LWN article and was
> thoroughly discussed by members of the X.Org boards, Daniel Stone, and
> others in hallway discussions is the question of whether to extend the
> X.Org membership to projects hosted on fd.o but outside the purpose of
> the X.Org foundation as enacted in its bylaws.
> 
> Most people I talked to would prefer not to dilute X.Org's mission and
> extend membership only to contributors of projects that follow X.Org's
> purpose as enacted in its bylaws. Other projects can continue to be
> hosted on fd.o but won't receive X.Org membership for the mere reason of
> being hosted on fd.o.
> 
> [1] https://lwn.net/Articles/767258/
> [2] https://youtu.be/s22B3E7rUTs
> 
> v3:
>  - Clarify what support of fd.o projects entails without formalizing a
>two-tier system for fd.o projects that fall under X.Org's mandate and
>those who don't
>  - Add link to Daniel's talk at XDC2018
> 
> v2:
>  - Subject line that better describes the intention
>  - Briefly describe reasons behind this change
>  - Drop expanding membership eligibility
> 
> Acked-by: Daniel Stone 
> ---
> 
> We're looking for feedback and comments on this patch. If it's not
> widely controversial the final version of the patch will be put to a
> vote at the 2019 X.Org elections.
> 
> The patch applies to the X.Org bylaws git repo, which can be found at
> https://gitlab.freedesktop.org/xorgfoundation/bylaws
> 
> Happy commenting.

Acked-by: Peter Hutterer 

Cheers,
   Peter

> Harry
> 
>  bylaws.tex | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/bylaws.tex b/bylaws.tex
> index 4ab35a4f7745..5a7542739582 100644
> --- a/bylaws.tex
> +++ b/bylaws.tex
> @@ -24,6 +24,11 @@ The purpose of the X.Org Foundation shall be to:
>  
>   \item Support and educate the general community of users of this
>   graphics stack.
> +
> + \item Support free and open source projects through the freedesktop.org
> + infrastructure. This includes, but is not limited to: Administering and
> + providing project hosting services.
> +
>  \end{enumerate}
>  
>  \article{INTERPRETATION}
> -- 
> 2.19.1
> 
___
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: libpciaccess on GNU/Hurd

2018-11-08 Thread Samuel Thibault
Adam Jackson, le jeu. 08 nov. 2018 15:19:41 -0500, a ecrit:
> > > If you try to implement this with a userspace arbiter then
> > > all you need to do to break it is run an old version of libpciaccess.
> > 
> > Sure. Except if ioperm is allowed only for the pci arbiter.
> 
> ... but that's all you need. Call ioperm, if it succeeds you must be
> the arbiter, so you install the x86 backend.

Mmm, we could do that in the kernel, yes: only allow one process to
access the PCI config ports.

Samuel
___
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: libpciaccess on GNU/Hurd

2018-11-08 Thread Adam Jackson
On Wed, 2018-11-07 at 22:56 +0100, Samuel Thibault wrote:
> Adam Jackson, le mer. 07 nov. 2018 15:09:58 -0500, a ecrit:
> > Because the kernel is the one thing in a position to enforce access
> > exclusion.
> 
> root-owned processes can still use ioperm to get access to io ports and
> break that.

Maybe on your kernel. Mine doesn't allow ioperm even for root.

> > If you try to implement this with a userspace arbiter then
> > all you need to do to break it is run an old version of libpciaccess.
> 
> Sure. Except if ioperm is allowed only for the pci arbiter.

... but that's all you need. Call ioperm, if it succeeds you must be
the arbiter, so you install the x86 backend. If it fails you use the
arbiter backend. There's no reason for pci_system_init()'s caller to
care.

- 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