>
> > 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.
Sorry, I forgot to mention a few assumptions I made here.
Of course, this already works today, but the read() call goes
into the (disk) driver and thus involves the CPU copying the
data from the disk buffers into the frame buffer.
If the disk driver would implement the kind of DMA I am suggesting,
it could in fact DMA directly from the disk into the frame buffer.
The CPU would hardly get involved and no system memory would be used
in the process!
> But maybe you mean: map in the file and pass the buffer to the read()
> function of the device driver? This would make sense.
Yes, this is the other way round. "device driver" in this case
refers to the video card's device driver. I'm not sure though
if it would really avoid any memory-to-memory copies by the CPU.
>
> > 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).
>
OK, so the buffer gets freed eventually. However, even if the driver
releases on close(), this only happens when the last close() call
is made, i.e. if multiple processes keep the device open and one
of them exits without releasing it's buffer, the buffer remains
allocated. [With the video frame grabber driver for which I wrote
this stuff, the buffer can be up to several megabytes in size
-- quite a bit of memory to be wasted].
The way I see it, the buffer logically belongs to the process
that has allocated it and thus they should both die at the same
time, but that is admittedly arguable.
Cheers
Rob
----------------------------------------------------------------
Robert Kaiser email: rkaiser@sysgo.de
SYSGO RTS GmbH
Carl-Zeiss-Str. 41 phone: (49) 6131 9138-80
D-55129 Mainz / Germany fax: (49) 6131 9138-10