On Friday 26 March 2004 15:14, Klaus Schmidinger wrote: > 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...
Out of interest, where does that 2048 figure come from? I can't see it in EN50221 or R206-001. I'm wondering if its an implementation limit imposed by the av7110 firmware. I can see why it would be like that; it really simplifies the defragmenter (I'll probably do the same myself). However, the worrying thing is that I can't see how the *CAM* knows the maximum TPDU size; there doesn't seem to be a protocol for negotiating it. Can anyone suggest what I'm missing? -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
