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 [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
