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]

Message-Id: <1179793201.32247.777.camel@localhost.localdomain>
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/