Re: [PATCH] Ngene cam device name

[Andreas Oberritter <obi@linuxtv.org>]

On 05/04/2011 10:27 AM, Issa Gorissen wrote:
> From: Andreas Oberritter <obi@linuxtv.org>
>> Also, there's still no mapping between ca and caio devices. Imagine a
>> built-in descrambler ca0 and two CI slots ca1 and ca2.
>>
>> ca0 won't get a caio device, at least for now.
>> ca1 and ca2 might or might not have a caio device.
>>
>> If there is caio0, how am I supposed to know that it's related to ca1 or
>> ca2 (or ca0, if someone implements a caio device to bypass the software
>> demux to use a built-in descrambler)? You must not assume that there are
>> either none or two (or three) caio interfaces. You need to be able to
>> detect (or set up) the connection between the interfaces. Otherwise this
>> "API" will be a mess.
>>
>> Regards,
>> Andreas
> 
> 
> To my understanding, in such a described case, 
> 
> - ca0 would be reached from /dev/dvb/adapter0/ca0
> - ca[12], depending on if they are connected to the same physical adapter
> (PCI, USB, ...), would be reached from /dev/dvb/adapter1/ca[12] or
> /dev/dvb/adapter1/ca1 and /dev/dvb/adapter2/ca2 and there respective caio
> devices.

Of course I'm referring to devices connected to the same physical
adapter. Otherwise they would all be called ca0. Device enumeration
always starts at 0, for each adapter. What you're describing just
doesn't make sense.

> - If the 3 ca devices are on the same adapter, then the driver writer should
> take care of the order of the mapping so that ca1 always map caio1 and
> ca2/caio2, ...; and if this is not feasable, then the driver writer should
> span the ca/caio devices on different /dev/dvb/adapter folders.

You can't create caio1 without creating caio0 first. Of course, you
could require driver writers to register those ca devices first that
have caio devices. But that conflicts with other policies the driver
author might already have chosen, e.g. to map the ca (descrambler)
device numbers to demux and dvr numbers, which seems way more intuitive
to me, because demux hardware usually comes with built-in descramblers.

It's ugly to force random policies on drivers. Please create a proper
interface instead!

Last but not least, using a different adapter number wouldn't fit
either, because a DVB adapter is supposed to
- be one independent piece of hardware
- provide at least a frontend and a demux device

At least on embedded devices, it simply isn't feasible to copy a TS to
userspace from a demux, just to copy it back to the kernel and again
back to userspace through a caio device, when live streaming. But you
may want to provide a way to use the caio device for
offline-descrambling. Unless you want to force users to buy multiple
modules and multiple subscriptions for a single receiver, which in turn
would need multiple CI slots, you need a way to make sure caio can not
be used during live streaming. If this dependency is between different
adapters, then something is really, really wrong.

Why don't you just create a new device, e.g. ciX, deprecate the use of
caX for CI devices, inherit CI-related existing ioctls from the CA API,
translate the existing read and write funtions to ioctls and then use
read and write for TS I/O? IIRC, Ralph suggested something similar. I'm
pretty sure this can be done without too much code and in a backwards
compatible way.

Regards,
Andreas