on patch "DVB: add firesat driver" in staging.git
robert.berger at reliableembeddedsystems.com
Sun Jun 15 12:11:52 UTC 2008
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.
> 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 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
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. So the classic
approach is for each packet to allocate some memory for one layer and
less for the next (stripped stuff) and less for the next and so on. To
pass from one layer to the next you do some copies, which is very
expensive in terms of performance. It turned out that it's worthwhile to
write your own memory manager, which contains a reusable pool of chunks
of memory. In order to pass form one to the next layer no copying is
needed, but just some playing around with pointers. Like this a user
space application with a memory manager can easily outperform a kernel
space application, which does not use it's own memory manager.
Of course if you would use a memory manager in kernel space, you could
achieve the best results, since you would avoid the copies form kernel
to user space and back.
Do you see similarities for the 1394 stuff?
Embedded Software Specialist
Reliable Embedded Systems
Consulting Training Engineering
Tel.: (+30) 697 593 3428
Fax.:(+30 210) 684 7881
email: robert.berger at reliableembeddedsystems.com
......The moral is obvious. You can't trust code that you did not
totally create yourself. -- Ken Thompson
My public pgp key is available at:
More information about the devel