On Thu, Apr 22, 2004 at 12:09:56PM +0100, Andrew de Quincey wrote: > 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?
No, I just thought it would make the code more explicit. But I guess V3 was only confusing because we had both read/write and ioctl, and the packet format for read/write was undefined. I guess I remove the ioctls and settle with read/write in V4. > * 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. I think if we want to implement higher level protocols we need additional ioctls or message types, e.g. for the transport layer we'd need a notification for terminated transport connections. All in all I think that's not worth it, and we should just support the current link layer interface. > * 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. This might be a good idea, however it means that some drivers are inherently broken, as the standard does not allow for such limitations? > * 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. Yes, the intention is to mark the CAM as broken, not to return error information for individual TPDUs. One could just time out waiting for DVB_CI_CAM_READY after the cam has been inserted, but DVB_CI_CAM_IOERR is more explicit. Maybe a better name is DVB_CI_CAM_ERROR? > * 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. The ancient av7110 DVB driver/firmware used a "high level" protocol for CI, with partial application layer support via special messages (see CI_MSG* and CI_CMD* in drivers/media/dvb/ttpci/av7110_hw.h). However, this protocol is so proprietary that I don't see how to map it into a standard API, so I don't think we should worry about it. Thanks for your comments, Johannes -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
