on patch "DVB: add firesat driver" in staging.git

[Stefan Richter]

Robert Berger wrote:
> Andreas Monitzer wrote:
>> On Jun 15, 2008, at 00:16, Stefan Richter wrote:
>>
>>> I forgot:  There is also the more fundamental question whether all of 
>>> this shouldn't rather be done in userspace, like with FireWire set 
>>> top boxes that are commonly used in North America.  But I am unable 
>>> to assess this due to lack of knowledge of the DVB side.
>>
>> The DVB API assumes that devices are handled by kernel modules, that's 
>> why I created one in the first place.

OK.  IOW the benefit is that FireWire DVB cards are presented to 
userspace like any other DVB card.

>> Additionally, there are performance considerations that have to be 
>> taken into account (receiving the stream has to happen in realtime, 
>> otherwise the video and audio streams would stutter), so this might 
>> pose another need for a kernel module (I don't know enough about the 
>> raw1394 API to judge that, though).

I am not familiar with isochronous 1394 application programming at all. 
But IIDC (uncompressed video for machine vision, surveillance etc.), DV 
(compressed video with camcorders, TVs, STBs), and semipro/pro audio are 
all handled in userspace, which is evidence that many realtime 
requirements can be satisfied with userspace implementations.

AFAIU zero-copy operation is possible with raw1394 only within the 
constraints of a ring buffer of programmable size.  This buffer is to be 
used during the whole reception, which makes zero-copy unrealistic in 
most situations.  I don't know about the capabilities of video1394, 
which is another userspace ABI of the ieee1394 stack.  The new firewire 
stack's firewire-cdev ABI allows for zero-copy operation without 
raw1394's restriction.

However, zero-copy operation is not a general requirement for realtime 
applications, although it is of course desirable, or actually necessary 
on resource restricted hardware.

> I don't know enough about the 1394 API to judge for this project, but I 
> believe that there are similarities to IPTV systems, where the streams 
> are coming through an Ethernet interface.
> Some people want to avoid the copy from kernel to user space (network 
> stack) and back to kernel space (inject into some hardware demux) in 
> case of a user space application, hence they go for the kernel space 
> implementation and claim it's for performance reasons, but I do have 
> evidence, that it's not enough. (different implementations on the same 
> hardware platform)
> In case you receive some RTP stream over the network you need to peel 
> off various headers and stuff like layers from an onion to end up with 
> the raw data, which can be injected into the demux.
[...]
> Do you see similarities for the 1394 stuff?

AFAIK raw1394 uses a feature of FireWire controllers which discards IEEE 
1394 headers from received streams before DMA.  The new firewire-cdev 
API uses a more flexible feature, dual buffer DMA, which lets the 
controller write headers of configurable size (i.e. IEEE 1394 headers 
and optionally additional format-dependent headers) into a buffer 
separate from the payload buffer.

(Note though that I have no expertise in any of these areas.  Some 
people over at linux1394-devel have, but I didn't want to cross-post.)
-- 
Stefan Richter
-=====-==--- -==- -====
http://arcgraph.de/sr/