[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220111230224.GT2328285@nvidia.com>
Date: Tue, 11 Jan 2022 19:02:24 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Logan Gunthorpe <logang@...tatee.com>
Cc: Matthew Wilcox <willy@...radead.org>, linux-kernel@...r.kernel.org,
Christoph Hellwig <hch@....de>,
Joao Martins <joao.m.martins@...cle.com>,
John Hubbard <jhubbard@...dia.com>,
Ming Lei <ming.lei@...hat.com>, linux-block@...r.kernel.org,
netdev@...r.kernel.org, linux-mm@...ck.org,
linux-rdma@...r.kernel.org, dri-devel@...ts.freedesktop.org,
nvdimm@...ts.linux.dev
Subject: Re: Phyr Starter
On Tue, Jan 11, 2022 at 03:57:07PM -0700, Logan Gunthorpe wrote:
>
>
> On 2022-01-11 3:53 p.m., Jason Gunthorpe wrote:
> > I just want to share the whole API that will have to exist to
> > reasonably support this flexible array of intervals data structure..
>
> Is that really worth it? I feel like type safety justifies replicating a
> bit of iteration and allocation infrastructure. Then there's no silly
> mistakes of thinking one array is one thing when it is not.
If it is a 'a bit' then sure, but I suspect doing a good job here will
be a lot of code here.
Look at how big scatterlist is, for instance.
Maybe we could have a generic 64 bit interval arry and then two type
wrappers that do dma and physaddr casting? IDK.
Not sure type safety of DMA vs CPU address is critical?
Jason
Powered by blists - more mailing lists