I'm again Cc'ing to linux-kernel (otherwise I wouldn't write in
English).
> As far as I know, mmap() just allows a user program to access
> portions of kernel space memory, so the memory the DMA goes to
> or from is still in kernel space. This also means that the
> kernel has to allocate and de-allocate this memory.
>
> Of course, you can set things up to make it look as though the
> buffer belonged to the application, basically by making it use
> a special allocation routine which results in an ioctl() call
> that would cause the driver to allocate that DMA memory on
> behalf of the application program.
>
> But this has some ugly consequences:
>
> 1) It results in a lot of unnecessary crosstalk between the
> application and the driver.
> The application has to be "DMA aware", i.e. it has to know
> that the device it is talking to is capable of DMA and it
> has to be programmed specifically to exploit this feature.
> With my approach, it could simply do:
>
> ....
> memory = malloc(BUFFER_SIZE);
> result = read(fd, memory, BUFFER_SIZE);
> ....
>
> where the read() call would result in a DMA into user space
> if the driver can do it. The application doesn't know about
> it, so this is far more generic.
Sorry, I misunderstood you. You don't want to implement a
"sys_lock_dma_memory()" call but provide user-level transparent means
to let the device driver perform dma transfers to the user
buffer.
Very nice.
> In the movie player example I mentioned in my posting, it
> would even be possible to use mmap() to map in the video
> card's frame buffer and pass that pointer to a read() call
> to read video data from a file directly into the frame buffer,
> so the video data would be transferred from disk directly
> into the frame buffer without using any system resources
> (except for the disk, of course).
> If you were to do this with mmap(), you could map in both
> the frame buffer and the disk file, but you would still
> have to use the CPU copy data from one to the other.
Why? No, this can already be achieved by mmap()ing the frame buffer
into the address space and passing it to the read() function.
But maybe you mean: map in the file and pass the buffer to the read()
function of the device driver? This would make sense.
> 2) What happens if the application dies unexpectedly (killed
> by a signal, for instance) after allocating a DMA buffer ?
> Since nobody is there to tell the driver to free up the
> buffer, it will remain allocated forever ... memory leak.
> With my approach, the allocated buffer dies together with
> the program that allocated it and this is IMHO how it should
> be.
No, this would no tbe a problem with traditional mmap() approach. The
driver would have allocated a buffer either all the time (waste of
memory, I must admit) or would allocate it when the device is opened
and release it when the device is closed. This would cover the fatal
signal as well as all files are closed by the OS if a process is
killed by signal (or exits otherwise with files still open).
Cheers
Claus