Thread (36 messages) 36 messages, 9 authors, 2022-01-20

Re: Phyr Starter

From: Logan Gunthorpe <logang@deltatee.com>
Date: 2022-01-11 23:08:44
Also in: dri-devel, linux-block, linux-mm, linux-rdma, lkml, nvdimm


On 2022-01-11 4:02 p.m., Jason Gunthorpe wrote:
On Tue, Jan 11, 2022 at 03:57:07PM -0700, Logan Gunthorpe wrote:
quoted

On 2022-01-11 3:53 p.m., Jason Gunthorpe wrote:
quoted
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.
Yeah, but scatterlist has a ton of cruft; numerous ways to allocate,
multiple iterators, developers using it in different ways, etc, etc.
It's a big mess. bvec.h is much smaller (though includes stuff that
wouldn't necessarily be appropriate here).

Also some things apply to one but not the other. eg: a memcpy to/from
function might make sense for a phy_range but makes no sense for a
dma_range.
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?
I would argue it is. A DMA address is not a CPU address and should not
be treated the same.

Logan
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help