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, 19 Feb 2007 23:13:04 -0500
From:	"Jaya Kumar" <jayakumar.lkml@...il.com>
To:	"Paul Mundt" <lethal@...ux-sh.org>,
	"Jaya Kumar" <jayakumar.lkml@...il.com>,
	"Peter Zijlstra" <a.p.zijlstra@...llo.nl>,
	linux-fbdev-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Cc:	jsimmons@...radead.org, Geert.Uytterhoeven@...ycom.com
Subject: Re: [PATCH 2.6.20 1/1] fbdev,mm: hecuba/E-Ink fbdev driver

On 2/18/07, Paul Mundt <lethal@...ux-sh.org> wrote:
> Given that, this would have to be something that's dealt with at the
> subsystem level rather than in individual drivers, hence the desire to
> see something like this more generically visible.
>

Hi Peter, Paul, fbdev folk,

Ok. Here's what I'm thinking for abstracting this:

fbdev drivers would setup fb_mmap with their own_mmap as usual. In
own_mmap, they would do what they normally do and setup a vm_ops. They
are free to have their own nopage handler but would set the
page_mkwrite handler to be fbdev_deferred_io_mkwrite().
fbdev_deferred_io_mkwrite would build up the list of touched pages and
pass it to a delayed workqueue which would then mkclean on each page
and then pass a copy of that page list down to a driver's callback
function. The fbdev driver's callback function can then do the actual
IO to the framebuffer or coalesce DMA based on the provided page list.

I would like to add something like the following to struct fb_info:

#ifdef CONFIG_FB_DEFERRED_IO
struct fb_deferred_io *defio;
#endif

to store the mutex (to protect the page list), the touched page list,
and the driver's callback function.

I hope this sounds sufficiently generic to meet everyone's (the two of
us? :) needs.

Thanks,
jaya

ps: I've added James and Geert to the CC list. I would appreciate any
advice on whether this is a suitable approach.
-
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