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

[Jesse Barnes <jbarnes@virtuousgeek.org>]

On Tue, 23 Jun 2009 11:04:39 +1000
Benjamin Herrenschmidt <benh@kernel.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.  That way we don't have to dump the whole queue into it when a
panic occurs, we can just switch buffers (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).  That's
slightly more invasive surgery though...  I should have a chance to do
something like that as part of the kdb/kms work I'll be doing with
Jason.

-- 
Jesse Barnes, Intel Open Source Technology Center