On Fri, 15 Oct 2004, Holger Waechtler wrote:
Gerd Knorr wrote:
Syncronization will become _very_ nasty with that approach through,
I doubt it is a good idea ...
synchronisation of what? Do you mean audio/video synchronisation via PCR?
No. Syncronization of the DMA buffers. With one application doing DMA
this is trivial: The kernel will notify the application when a new
buffer has been filled, the application will notify the kernel when it
is done with processing the data in there and the buffer can be refilled
with new data, end of story.
With multiple apps having read access to the very same DMA buffer ring
this suddenly becomes much more complex. Especially the handling of
nasty corner cases like this one (and there are probably more): One
application gets stuck for some reason and stops releasing the processed
buffers. Might be a bug. Might be a app streaming stuff over the
network and the network is overloaded. Whatever, doesn't matter. How
do you handle that?
The entire ringbuffer of DMA areas is exposed read-only to the
application and every client can query via ioctl() the current DMA write
pointer position or the number ov valid (filled) DMA areas, or simply a
bitfield describing which DMA buffers are filled with data.
Ringbuffer read-pointers need to get handled by the application, the
situation is basically similiar to the one when you program a DMA driver
in kernel space, you can only read the current write position register
from the hardware.
As you may recall this is what I've done in my Mac drivers. But I've taken
it one step further and exported the current write position via a
single-page memory mapping to userspace as well (so there are two memory
mappings, one big one and one small one).
The driver gives the user information about where in the mapping the level
is to be found and how to turn it into a number of bytes. For PCI devices,
this means that the userspace program doesn't ever have to cross into the
kernel in the normal process of decoding, so there is no overhead there
(the small mapping exported is part of their PCI register address space).
Moreover, it means that the kernel drivers aren't interested when new data
is ready, so they don't have to setup or handle interrupts - once a
channel has been tuned the kernel drivers sit back and do nothing.
How do you check whether new data is available? Are you doing
busy-polling on the write position? I wanted to wake up a
poll()-waitqueue in the data-available irq, but maybe there are better
ways...