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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Mon, 28 May 2007 20:12:13 +0000
From:	Pavel Machek <pavel@....cz>
To:	Jon Smirl <jonsmirl@...il.com>
Cc:	Dave Airlie <airlied@...il.com>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Jeff Garzik <jeff@...zik.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

Hi!

> >> These are not isolated problems. Linux needs a 
> >properly designed
> >> graphics subsystem. One way to achieve that is to 
> >design it all on
> >> paper first so that we can try and locate the 
> >interactions between
> >> modules. For example the current mode setting design 
> >is definitely
> >> broken for multi-seat support, that's because you 
> >didn't take that
> >> feature into account when writing the code.
> >
> >No it isn't the code Jesse posted can handle multi-seat 
> >fine in the
> >areas that it makes sense as we've pointed out to you 
> >you cannot just
> 
> The code doesn't create one device per CRTC. Missing 
> that feature
> means that we need a persistent root priv app around 
> that owns the
> single device and then listens for messages from each 
> seat asking it
> to do things. That root priv app is not necessary, it is 
> a security
> risk and it should be eliminated.

Fine, submit a patch. But don't block other people patches just
because they do not address your favourite problem.

> >Fine, but nobody has succeeded at this, because the 
> >effort of doing it
> >this way is not incrementally developed, we are not 
> >designing DX10, we
> >are improving Linux graphics one step at a time.
> 
> And the right way to build a house is to build the 
> kitchen first and
> figure out the rest after the kitchen is finished.

...and the right way to build a house is to do nothing, and chase away
anyone trying to do something?

> >The thing is we need integration with memory 
> >management, the memory
> >management is in the drm as it is complicated and the 
> >work is done, I
> >know you aren't even reading this sentence at this 
> >point.
> 
> A new memory manager for drm is a nice piece of work. It 
> was something
> that needed to get done. But right now it is being done 
> in an X
> specific manner without consideration of alternative 
> graphics
> environments.

Feel free to post alternative patch that addresses that...

Fact is, everyone runs X these days. 'Your patches can't go in,
because you do not support alternative graphics systems (that don't
exist)' is pretty weak argument.

							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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/