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:	Sun, 19 Oct 2008 14:04:51 -0700
From:	Keith Packard <keithp@...thp.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	keithp@...thp.com, Jesse Barnes <jbarnes@...tuousgeek.org>,
	Nick Piggin <nickpiggin@...oo.com.au>,
	Dave Airlie <airlied@...ux.ie>,
	Yinghai Lu <yinghai@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	dri-devel@...ts.sf.net, Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: io resources and cached mappings (was: [git pull] drm patches
	for 2.6.27-rc1)

On Sun, 2008-10-19 at 19:53 +0200, Ingo Molnar wrote:

> Note how simple and consistent it all gets: IO resources already know 
> their physical location and their size limits. Being able to cache an 
> ioremap in a mapping [and being able to use atomic kmaps on 32-bit] is a 
> relatively simple and natural extension to the concept.

I'm not sure I see any value in caching mappings here; we're mostly
interested in copying lots of data onto the card and so we use a lot of
different mappings; atomic mappings are easy to use, and efficient
enough.

Also, if we're using a resource, I'd like to just use byte offsets and
not pfns; the resource presumably knows the base address.

> i think we need to finalize the API names and their abstraction level, 
> and then could even merge those APIs into v2.6.28 on a fast path, to 
> enable you to use it. It does not interact with anything else so it 
> should be safe to do.

Let's figure out the API we want, then figure out whether it makes sense
to stick it into 2.6.28 or whether we just want to wait for .29. I don't
mind rewriting the driver for the next release.

I will probably use something like the io_reserve stuff for .28 though;
it makes the code easier to read and gives us good performance on 64 bit
kernels.

-- 
keith.packard@...el.com

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)

Powered by blists - more mailing lists