[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190807064000.GC6002@infradead.org>
Date: Tue, 6 Aug 2019 23:40:00 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Matthew Wilcox <willy@...radead.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Christoph Hellwig <hch@...radead.org>,
Thomas Hellström (VMware)
<thomas@...pmail.org>, Dave Airlie <airlied@...il.com>,
Thomas Hellstrom <thellstrom@...are.com>,
Daniel Vetter <daniel.vetter@...ll.ch>,
LKML <linux-kernel@...r.kernel.org>,
dri-devel <dri-devel@...ts.freedesktop.org>,
Jerome Glisse <jglisse@...hat.com>,
Jason Gunthorpe <jgg@...lanox.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Steven Price <steven.price@....com>,
Linux-MM <linux-mm@...ck.org>
Subject: Re: drm pull for v5.3-rc1
On Tue, Aug 06, 2019 at 12:09:38PM -0700, Matthew Wilcox wrote:
> Has anyone looked at turning the interface inside-out? ie something like:
>
> struct mm_walk_state state = { .mm = mm, .start = start, .end = end, };
>
> for_each_page_range(&state, page) {
> ... do something with page ...
> }
>
> with appropriate macrology along the lines of:
>
> #define for_each_page_range(state, page) \
> while ((page = page_range_walk_next(state)))
>
> Then you don't need to package anything up into structs that are shared
> between the caller and the iterated function.
I'm not an all that huge fan of super magic macro loops. But in this
case I don't see how it could even work, as we get special callbacks
for huge pages and holes, and people are trying to add a few more ops
as well.
Powered by blists - more mailing lists