Re: [cdi-devel] [RFC PATCH] mem.h: Handling memory areas

[Matthew Iselin <matthew@xxxxxxxxxxxxxx>]

On Mon, Jan 25, 2010 at 7:37 AM, Kevin Wolf <kevin@xxxxxxxxxx> wrote:
> <snip>
>
> To explain the use of the other functions, consider the following.
> Let's take a disk driver as an example. Instead of buffer/size its
> write function will directly get a memory area from the OS. The OS might
> already have allocated the memory physically contiguous, but it doesn't
> need to do so. The driver calls cdi_mem_require_flags which copies the
> data into a suited buffer - but if the OS already did the right thing,
> it's a no-op.

Hmm, I don't actually like the sounds of that. I'd prefer that when
the driver gets memory from the OS it specifies the flags it requires
for the memory area rather than get the memory then change flags on
the area (potentially requiring a full reallocation of the buffer
itself) later. I also don't think cdi_mem_require_flags should perform
a copy: semantics like that are not intuitive. I may have
mis-interpreted of course.

> cdi_mem_copy is for the other way round. Now the disk driver wants to
> read something from its disk. It gets a memory area from the OS and uses
> cdi_mem_require_flags to get something usable for DMA, which may or may
> not involve a copy. When the disk has transferred all the data, the
> driver uses cdi_mem_copy to make sure that the read data ends up in the
> buffer it was passed - and again, if the buffer had already the right
> flags this will be a no-op.

Again, cdi_mem_require_flags probably shouldn't perform a copy.

It just sounds like the interface could be cleaned up a bit, and
especially could be modified to reduce the amount of copying that the
CDI implementation might have to do. Drivers at least should know what
they need from the very beginning.

Apart from these nitpicks I like where you're going with the interface.

Cheers,
Matt