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, 21 May 2007 13:42:36 -0400
From:	"Jon Smirl" <jonsmirl@...il.com>
To:	"Dave Airlie" <airlied@...il.com>
Cc:	"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 5/21/07, Dave Airlie <airlied@...il.com> wrote:
> This just needs a userspace console again a parallel problem that
> really isn't much to do with the problem set this work is trying to
> solve... it should enable it...

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.

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.

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.

All of the points in the list are interrelated and the architecture
needs to address everything as a unified whole.

-- 
Jon Smirl
jonsmirl@...il.com
-
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ