On Monday 19 April 2004 17:07, Johannes Stezenbach wrote: > Hi, > > I'm trying to finish my work on the V4 CI API. After a bit of thinking > I made the following changes which I just comitted to CVS: > > - one device node for all slots on one CI controller > - define API protocol units to be "raw, unfragmented TPDUs", i.e. > slightly above link level but not interpreted by the driver, so > the transport level must be implemented in user space; > this is the status quo of the V3 API and I think it makes much sense > to keep it that way > - define poll(2) semantics; link/pyhsical layer polling is entirely > handled within the driver > > (this is not TOFU -- please read down below)
I have no real preference on whether read/write or the IOCTL interface is used.. but here are my thoughts on it: * We're using the read/write interface at the moment. Is there any real advantage to swapping to the IOCTL interface? * If we supported more than just link level packets, we would have to extend the read/write interface anyway as we would need a way to specify the type of packet. However, another way of doing this would be for the driver to specify what type of packet must be used on a particular slot in the _caps structure. The userspace app then just sends the corresponding protocol structure on the read/write interface. Other stuff: * It would be good to add the max. size of a TPDU (or whatever protocol is in use) as a field to dvb_ci_capability. At the moment, everyone is hardcoding it to 2048 bytes because that is what is necessary for the av7110 cards. But this isn't the case with the budget-ci, so it would be nice to have the limits explicitly returned by the driver. * Is DVB_CI_CAM_IOERR useful? The budget-ci driver returns -EIO if a write operation failed, and automatically restarts the link initialisation protocol. I suppose it would be useful if the renegotiation fails multiple times though... perhaps it should just be called DVB_CI_CAM_FATAL_ERR (or something), and used to indicate when the CAM appears to have locked up and needs a reset. * I assume we would have the protocol structures to be sent over read/write (if used) defined in the ci.h header. * As for whether we need to support different types of protocol, I cannot comment... to quote Ralph's original message: > If you keep the interfaces between layers general enough it should > also be no problem to support drivers with other interfaces (like the > av7110 cards or also the Twinhan cards with even higher level interface) > with the same code. What these "higher level" interfaces are was never discussed. I assume higher level in EN50221, but I may be wrong. -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
