Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linux-dvb] Re: DVB-CI question



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)

On Fri, Mar 26, 2004 at 09:06:18PM +0100, I wrote:
> On Fri, Mar 26, 2004 at 07:41:17PM +0000, Andrew de Quincey wrote:
> > 
> > The only problem I can see is that that API doesn't take into account that 
> > different devices operate at different levels . From what Ralph was saying, 
> > the Twinhan cards operate above the TPDU level.
> > 
> > For the stuff I was messing about with, I was thinking of something like the 
> > FE_SET_FRONTEND ioctl... so you had a structure like the following for the 
> > SEND_MSG/GET_MSG ioctls:
> > 
> > struct dvb_ci_msg {
> > 	int msg_type;
> > 	
> > 	union {
> > 		struct tpdu { ... };
> > 		struct othermsgtype1 { ... };
> > 		struct othermsgtype2 { ... };
> > 	} u;
> > }
> 
> Makes sense. Like I said before, I don't know that much about CI,
> so I removed everything from the API that I thought was useless.
> (It's always easier to add stuff later than to remove something).

I wanted to add support for other protocols than the one described
above, but I'm not sure how to do it. E.g. if we would implement a
transport layer API, would we just send SPDUs instead of TPDUs?
Or is there more interaction required than just send/receive?
Would it make sense to implement the transport layer in the driver?

Also, to keep userspace software portable I think it is not desirable
to support different protocols. We should only do it if it is unavoidable.

If you know about hardware that doesn't work with the link layer API
(Twinhan?), please let me know.


> > Would the CI read()/write() interface be removed in v4?
> 
> Yes. No need for two differtent methods for the same thing.

I still think that the send/receive ioctls are more readable
than read/write, but might be more natural to use. We could
drop the ioctls and replace them with some comments about the
format of the messages for read/write, if that is the preferred
interface?


Please comment,
Johannes


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



Home | Main Index | Thread Index