[linux-dvb] Re: DVB-CI question

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Andrew de Quincey wrote:
> 
> ...
> Its just it makes the driver's IO routines _really_ complex, as they have to
> deal with multiple connections, multiple slots, the possibility that the CAM
> can be yanked out by the user at any time, and lots of other things. There is
> a LOT of complex locking involved to ensure it can't break.
> 
> Add to that the fact that each de-fragmented packet can be up to 65536 bytes,

Strange, from what I know a TPDU can be at most 2048 byte long...

Maybe you could take a quick look at VDR/ci.c and let me know whether
the data VDR exchanges with the CI already consists of the "fragements"
you're referring to.

Klaus

> so at least one of those buffers is needed PER connection PER slot. Adds up
> to a lot of wasted memory. It would also fix some otherwise unsolvable
> buffering issues in the driver (or rather, not solvable without some
> extremely nasty code).
> 
> IMO, the driver should be as simple as possible. I don't think the CAM
> interface benefits speed-wise from the reassembly being in the driver, so,
> apart from saving a little bit of extra code in userspace I can't see any
> good reason for the reassembly being in the kernel. Each app already has to
> implement all the other layers of the EN50221 control protocol stack itself;
> why not this extra bit as well?
> 
> At the moment, I'm still convinced that this is a good idea. I'm implementing
> all layers of the EN50021 protocol and the driver in parallel right now, and
> userspace looks far more suitable for the defragmentation code.


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