[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1245719079.4017.25.camel@pasglop>
Date: Tue, 23 Jun 2009 11:04:39 +1000
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Thomas Hellström <thomas@...pmail.org>,
Dave Airlie <airlied@...ux.ie>,
Alex Deucher <alexdeucher@...il.com>,
Andrew Lutomirski <luto@....edu>, dri-devel@...ts.sf.net,
Jerome Glisse <jglisse@...hat.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [git pull] drm: previous pull req + 1.
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.
Cheers,
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/
Powered by blists - more mailing lists