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: <1166046361.11914.198.camel@localhost.localdomain>
Date:	Thu, 14 Dec 2006 08:46:01 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.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

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

And even X is trying to move away from that at least partially... With
the DRI driver handling IRQs and processing command buffers... except
for cards with multiple hardware contexts, but then, we are in a case
similar to Infiniband where the HW is -designed- to have specific areas
mapped into user space, and there is still a kernel driver to arbitrate,
decide who gets what, establish those mappings, etc...

Thus X isn't even a good example :-)

Ben.

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