[linux-dvb] What do you think of mpsys library ? (for ca_zap)

[Manu Abraham]

Kenneth Aafløy wrote:
> Hi,
> 
> On Friday 01 April 2005 17:53, Dominique Dumont wrote:
> 
>>Manu and I are currently exchanging ideas (and code) related to the
>>next ca_zap (i.e. the small user space application in charge of
>>sending a ca_pmt message to the CAM on a Twinhan card).
>>
>>We are thinking about providing a library to parse PAT and PMT and to
>>generate an EN50221 CA_SET_PMT message.
>>
>>I've seen that mpsys library [1] alreasy provides a C library to parse
>>PMT and most of a TS stream. Using the XML protocol description, it
>>should be quite easy to provide an EN50221 parser also.  (although,
>>I'm not so sure about the encoding part of the EN50221 messages ... I
>>may have to dust off my XSLT cookbook )
>>
>>What do you think of this library ?
>>Is there any reason not to use it with dvb application ? 
>>Or not to recommend it ?
> 
> 
> I'm not sure why you want to bring xml into this picture? Abstracting?
> 
> I'm thinking:
> 
> We merge the code from *zap and scan in a library, similar to the alsa library.

Exactly.. My idea was that i have a ca_zap application, for which the 
code can be easily factorized out... and that is what exactly i am 
doing, rather than have another library into the picture, such that we 
loose a lean architecture ...


> Importing common features such as the vdr ci code (which is used by at least
> mythtv and iirc videolan), then provide a common method of tuning that includes
> the quirks of handling an associated cam. The library would have control over
> a configuration file that resides in etc, which the application may or may not

With the ca_zap factorized out, the communication happens to be purely 
EN50221 style paclet exchange, which was exactly as we discussed earlier 
regarding the design of the High Level CI interface.

With this interface, the translation is carried out by the driver, 
rather than a library. The advantage would be that, hardware that does 
not fit into the current scheme can be very well associated with that 
way ( i really mean all of them, if you are really interested to know 
more , i have Documentation/ci.txt in the experimental branch depicting 
how to use it further.)

> use as it sees fit. Both the in kernel frontend and ci threads could
> potentionally be moved to userspace, reducing the kernel driver footprint.

No, moving the ci threads out from the driver would raise the very same 
questions that we had been discussing earlier. The point is to 
accomodate new hardware !

> The interface of this library must offcourse be pondered on, as it should remain
> very stable and allow extensions that potentially could be introduced by new
> adapter types. IIRC there is also an implementation of ts2ps (or similar) in
> the kernel that could be ripped out.

The interface of the library is very similar to the ones found in scan 
and so on, so i don't think there is much of an issue there.

> 
> The CAM handling could then be very simplyfied, allowing either the application

With this way the CAM handling is extremely simplified...

Once the packets are exchanged, the driver takes care of the rest ..

> or the library (plugins?) to handle the features of decrypting the stream. IIRC
> Marcus Metzler pointed out to me that there are meny methods of controlling
> decrypting a stream, that involves controlling a remote device, which also
> would fit well in this picture.
>

Yes it could very well fit into the picture (as the interface of the USB 
devices are different, this way it would be very effecient, since this 
does *only* EN50221 style exchange and not tied to any specific style, 
or hardware interface.), i was currently doing some basic parsing and 
some Application level EN50221 style packet exchange. Whatever new could 
be very well added to it without any difficulty as it is relatively simple.


> We could start simple, just providing the features of handling decryption, then
> put in other blocks to handle other aspects of dvb.
> 

That's what exactly what i am doing .. I am right now providing 
(factorizing) the code that would otherwise go into ca_zap.

> What do you think?

Currently my architecture is like this, ca_zap is linked against 2 tiny 
libs, libsi and liben50221, which are nothing but factored code from 
ca_zap as you might have already seen from my earlier patches ...

I had been restoring my system from a relatively low level and hence the 
delay in getting things up as expected.. :-(


> To radical a goal?


Let me know what you think ..

Manu