linux-kernel - Re: [GIT PATCH] more Driver core patches for 2.6.19

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]

Message-Id: <1166044547.27217.902.camel@laptopd505.fenrus.org>
Date:	Wed, 13 Dec 2006 22:15:47 +0100
From:	Arjan van de Ven <arjan@...radead.org>
To:	Linus Torvalds <torvalds@...l.org>
Cc:	Greg KH <gregkh@...e.de>, Andrew Morton <akpm@...l.org>,
	linux-kernel@...r.kernel.org, tglx@...utronix.de
Subject: Re: [GIT PATCH] more Driver core patches for 2.6.19

On Wed, 2006-12-13 at 13:08 -0800, Linus Torvalds wrote:
> 
> On Wed, 13 Dec 2006, Linus Torvalds wrote:
> > 
> > Btw: there's one driver we _know_ we want to support in user space, and 
> > that's the X kind of direct-rendering thing. So if you can show that this 
> > driver infrastructure actually makes sense as a replacement for the DRI 
> > layer, then _that_ would be a hell of a convincing argument.
> 
> Btw, the other side of this argument is that if a user-space driver 
> infrastructure can _not_ help the DRI kind of situation, then it's largely 

with DRI you have the case where "something" needs to do security
validation of the commands that are sent to the card. (to avoid a
non-privileged user to DMA all over your memory)

That and a tiny bit of resource management is the bulk of the kernel DRM
code... and I don't think userspace can do it fundamentally better.
Sure you could pipe things to a root daemon instead of doing a system
call. But I don't see that being superior.

-
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/