[linux-dvb] Re: Questions Round2

[Holger Waechtler <holger@convergence.de>]

Florian Schirmer wrote:
> Hi,
> 
> Some more questions, i stumbled on while digging trough the api:
> 
> 1. soft-dmx doesn't check the crc of sections. Any reason for that?

just a known bug. Somebody has to enable and test the crc32 code in 
dvb_demux.c again...


> 2. acceleration hooks
> 
> This is a quite complex question ;) Background: Our STB is capable of
> calculation the section crc itself. But it can only do that if the data
> is still in the queue and has not been pulled out into the
> dmxfeed->secbuf. To use the crc engine there are 2 possible solutions:
> 
> A) Copy all the dvb api soft dmx functions and hack them to use the
> engine. This will result in lots of duplicate code.
> B) Add some acceleration hooks into the feed structure. For example:

I vote for (B).


> struct dvb_accel {
> 
>   void priv;
> 
>   u32 (*crc)(void *src, size_t count);
>   void (*memcpy)(void *dst, void *src, size_t count);
> 
> }
> 
> Struct dvb_dmx_feed {
> [...]
>   struct dvb_accel accel;
> [...]
> 
> }
> 
> allocate_feed() {
> [...]
>   feed->accel.crc = dvb_crc;
>   feed->accel.memcpy = memcpy;
> [...]
> }
> 
> The api will initialize the accel functions with the normal
> dvb_crc/memcpy functions. If the hardware is able to do crc itself it
> can overwrite the handlers and benefit from its capabilties. 
> 
> Oppinions? Any other ideas?

no, looks fine for now. (Remembers me to the Mesa and DirectFB 
achitecture - even this would be reason enough to like it;)

I would not encapsulate the function pointers into an extra struct, just 
call the members check_crc32 and memcpy and put them directly into the 
demux struct right beside write_to_decoder, these acceleration function 
pointers are associated with a demultiplexer not with a feed, right?

Holger



-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.