linux-kernel - Re: [git pull] drm: previous pull req + 1.

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:	Tue, 23 Jun 2009 09:48:00 +0200
From:	Michel Dänzer <michel@...nzer.net>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>
Cc:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Thomas@...line-mail2.netline.ch, Dave Airlie <airlied@...ux.ie>,
	Andrew Lutomirski <luto@....edu>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jerome Glisse <jglisse@...hat.com>, dri-devel@...ts.sf.net,
	Alex Deucher <alexdeucher@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [git pull] drm: previous pull req + 1.

On Mon, 2009-06-22 at 18:18 -0700, Jesse Barnes wrote:
> On Tue, 23 Jun 2009 11:04:39 +1000
> Benjamin Herrenschmidt <benh@...nel.crashing.org> wrote:
> 
> > On Mon, 2009-06-22 at 17:24 -0700, Linus Torvalds wrote:
> > > 
> > > On Tue, 23 Jun 2009, Benjamin Herrenschmidt wrote:
> > > > 
> > > > As far as I can remember, all fbdev operations are done under the
> > > > console semaphore.
> > > 
> > > Yeah, and some of them are horribly broken (ie copying data from
> > > user space while doing it - causing horrible things like VC
> > > switching latencies and invisible printk's if an oops happens
> > > during the op).
> > > 
> > > Or maybe that got fixed. 
> > 
> > Well, it does rely on userspace behaving.. ie, no accel ops are done
> > by the kernel in KD_GRAPHICS and userspace is -supposed- to switch to
> > KD_GRAPHICS before touching the fb.
> > 
> > In fact, nowdays, we do have the infrastructure to be smart and
> > enforce that. IE. Instead of using a boring remap_page_ranges() in
> > fb_mmap() we could use a fault handler. When in KD_TEXT, we fail
> > them, when in KD_GRAPHICS, we service them, and we
> > unmap_mapping_range() when switching. Something like that...
> > 
> > Dunno how that interacts with the new DRM thingy though.
> 
> I think it could work, but ideally we'd keep the kernel fbcon object
> pinned, and keep printing into it even while some other gfx app is
> running.

It doesn't need to be pinned for that, does it? I think in the long run
it's a bad idea to have it pinned all the time, think of machines with
only 8 MB of VRAM...


> (something like this would also be handy for dual head debugging; one
> head running your desktop and the other a debug console printing all
> the messages).

On a side note, I did precisely that about ten years ago on my Amiga. :)
Granted, that was using two separate framebuffer devices (X glint driver
on top of pm2fb, debug messages on amifb), but I think even that case
isn't possible ATM. I agree it would be nice, though realistically
there's hardly a way around a second machine for graphics driver
development anyway.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer
--
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/