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
| ||
|
Date: Tue, 22 May 2007 10:20:01 +1000 From: Benjamin Herrenschmidt <benh@...nel.crashing.org> To: Jon Smirl <jonsmirl@...il.com> Cc: Dave Airlie <airlied@...il.com>, 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 Mon, 2007-05-21 at 13:42 -0400, Jon Smirl wrote: > > When I went through the design process for all this I came to the same > conclusion about needing a user space console process. > > User space console does impact on all of this because it implies that > the current console should be be defeatured down until it becomes only > a system recovery console and not a console for everyday use. I do agree (heh, for once) with that in the sense that in the long run, we should strip the kernel console down to the bare minimum to boot, display oopses, etc... and have all the fancy stuff, unicode, VT, and more in a userspace console process. However, I'm a little bit worried that we'll end up with 10 competing incompatible and inconsistent userspace console projects and -that- will be horrible. But it's something separate from what Dave and Jesse are trying to address. Let's first gets the fundation right and -then- we can do all sort of crazy things. Or maybe you can start working on a user console project in parallel using the new APIs that Jesse and Dave are providing ? :-) > For example, one part of the defeaturing would be to remove the > drawing acceleration code in the existing fbdev console drivers and to > rework it to support accelerated drawing from the user space console > implementation. You want the system recovery console mode to be as > simple as possible so that it is always guaranteed to work. User space > console is also what leads to the idea of compiling VT out of the > kernel. I do agree on that in the long run, but again, let's look into this -after- we have solved the more immediate issues. We can probably kill most of fbdev, fbcon and current VT once we have a solid userland based replacement that isn't completely bloated (maybe with a "slim" version that does only VGA and non-utf8 for server type apps). > Once you decide that a user space console is needed then the per CRTC > device node becomes more obvious since different people can be logged > onto the different consoles. That's irrelevant. Implementation detail. > All of the points in the list are interrelated and the architecture > needs to address everything as a unified whole. And that's bullshit :-) 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/
Powered by blists - more mailing lists