linux-kernel - Re: [RFC] enhancing the kernel's graphics subsystem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 21 May 2007 20:26:30 -0400
From:	"Jon Smirl" <jonsmirl@...il.com>
To:	"Jeff Garzik" <jeff@...zik.org>
Cc:	"Jesse Barnes" <jbarnes@...tuousgeek.org>,
	"Jesse Barnes" <jesse.barnes@...el.com>,
	linux-kernel@...r.kernel.org,
	"Antonino A. Daplas" <adaplas@...il.com>
Subject: Re: [RFC] enhancing the kernel's graphics subsystem

On 5/21/07, Jeff Garzik <jeff@...zik.org> wrote:
> Jon Smirl wrote:
> > 2) Address the long outstanding issue of multi-seat at the console
> > level. My solution to this is the one device per CRTC model.
>
> This is very very low priority.  Pretty much nobody besides you is
> clamoring for it.
>
>
> > 3) Eliminate the need for a root priv controlling process. Get rid of
> > the potential for a security hole.
>
> Agreed.
>
>
> > 4) OOPS should always display even if in a graphics mode
>
> Agreed, and this was in the list that Jesse(?) posted.
>
>
> > 8) Allow multiple user space graphics systems to run. These user space
>
> Another very very low priority item.
>
> There are a lot more important things to work on.  Linux is about what
> people need -right now-, not what you think Linux might need in the
> future; not what you think might be nice to have.

I am not asking that these features be implemented today. I am asking
that enough planning go into the architecture today to make sure that
these features can be built in the future without tearing up the
graphics system for a third time.

This is the essence of my complaint about this patch. The patch
introduces a new low level graphics API to the kernel. Once we put an
API in it is basically impossible to get it back out. I am not
convinced that enough planning has gone into this API yet.

I'm also not convinced that there is a transition plan in place to
ensure that all drivers get updated to this new API. The last thing we
want is to maintain two parallel sets of video drivers forever into
the future. V4L2 did something similar to this and orphaned a lot of
drivers that the distributions were forced into updating later.

Mode setting is intimately intertwined with the console. VT swapping
adds another messy layer which can and should be eliminated in a
redesign. Multi-seat and unicode add more complexity. All of this
needs to be designed as a unified system. Satisfying the needs of the
X server is the easiest piece of the puzzle.

-- 
Jon Smirl
jonsmirl@...il.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/