[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPcyv4hSs2M3LYscsepYat+FN9e3aUxSY3kGMFD6M9-9BCR5HQ@mail.gmail.com>
Date: Mon, 12 Sep 2016 20:49:43 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: Nicholas Piggin <npiggin@...il.com>
Cc: Linux MM <linux-mm@...ck.org>,
Andrea Arcangeli <aarcange@...hat.com>,
Xiao Guangrong <guangrong.xiao@...ux.intel.com>,
Arnd Bergmann <arnd@...db.de>,
"linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
linux-api@...r.kernel.org,
Dave Hansen <dave.hansen@...ux.intel.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
linux-arch@...r.kernel.org
Subject: Re: [RFC PATCH 1/2] mm, mincore2(): retrieve dax and tlb-size
attributes of an address range
On Mon, Sep 12, 2016 at 7:16 PM, Nicholas Piggin <npiggin@...il.com> wrote:
> On Mon, 12 Sep 2016 10:29:17 -0700
[..]
>> Certainly one of the new request flags can indicate that the vector is
>> made up of larger entries.
>
> Hmm. Changing prototype depending on flags. I thought I was having
> a nightmare about ioctls for a minute there :)
Heh :)
> In general, is this what we want for a new API? Should we be thinking
> about an extent API?
This probably fits better with the use cases I know that want to
consume this information, something like fiemap (mextmap, maybe?) for
memory.
Powered by blists - more mailing lists