linux-kernel - Re: console font limits

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] [day] [month] [year] [list]

Date:	Sun, 6 May 2007 19:35:53 -0400
From:	Daniel Hazelton <dhazelton@...er.net>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>
Cc:	"Antonino A. Daplas" <adaplas@...il.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Kyle Moffett <mrmacman_g4@....com>,
	Jan Engelhardt <jengelh@...ux01.gwdg.de>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Albert Cahalan <acahalan@...il.com>,
	linux-kernel <linux-kernel@...r.kernel.org>, aeb@....nl
Subject: Re: console font limits

On Friday 04 May 2007 11:34:40 Jesse Barnes wrote:
> On Thursday, May 03, 2007, Antonino A. Daplas wrote:
> > On Thu, 2007-05-03 at 23:58 -0400, Daniel Hazelton wrote:
> > > On Thursday 03 May 2007 20:39:05 H. Peter Anvin wrote:
> > > > Kyle Moffett wrote:
> > >
> > > I guess I could start on that work again - shouldn't take me all that
> > > long to recover the stuff I lost when a blackout caused my hard drive
> > > to get corrupted beyond recovery (and the automated journal replay
> > > didn't do a damned thing - I think it actually *added* to the
> > > corruption, but I don't think any filesystem would have survived that)
> >
> > You might want to look at the modesetting-101 branch of DRM.  It's goal
> > is similar to yours.  They even have a drm framebuffer.  I don't know
> > how far they are with their goal, but I can see some progress.
> >
> > Here's their git tree:
> >
> > git://git.freedesktop.org/git/mesa/drm#modesetting-101

Nope. Address doesn't work for me. 

> It sounds like we'll need a new KD_* flag for this work too, something like
> KD_TEXT_BUT_ONLY_ON_PANIC, sine with the above tree, the kernel will have
> intimite knowledge of the current graphics mode, framebuffer location,
> etc.  It should be enough to clear the scanout buffer and output the
> printk, though if there's a lot of rendering going on, the DRM driver
> might have to be pretty smart about it.

Yeah, I had thought about this. What I was thinking was that, on panic, the 
kernel could either kill the graphics mode entirely or do something like what 
the Amiga used to do - ie: scroll the screeen *down* and insert the error 
output at the top. (well, the opposite, really - scroll up and insert, just 
to keep the code simple and elegant)

Other than that, well... I figure that if the kernel is using DRM internally 
it can easily tell DRM to cancel out all extended rendering contexts - 
OpenGL, overlays and such - when the panic happens.

DRH

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