Re: [PATCH 0/5] Driver support for cards based on Digital Devices bridge (ddbridge)

[Mauro Carvalho Chehab <mchehab@redhat.com>]

Em 16-07-2011 12:44, Antti Palosaari escreveu:
> On 07/16/2011 06:40 PM, Andreas Oberritter wrote:
>> On 16.07.2011 16:54, Mauro Carvalho Chehab wrote:
>>> Em 16-07-2011 11:16, Antti Palosaari escreveu:

>>> Approach 4) fe0 is a frontend "superset"
>>>
>>> *adapter0
>>> *frontend0 (DVB-S/DVB-S2/DVB-T/DVB-T2/DVB-C/ISDB-T) - aka: FE superset
>>> *frontend1 (DVB-S/DVB-S2)
>>> *frontend2 (DVB-T/DVB-T2)
>>> *frontend3 (DVB-C)
>>> *frontend4 (ISDB-T)
>>>
>>> fe0 will need some special logic to allow redirecting a FE call to the right fe, if
>>> there are more than one physical frontend bound into the FE API.
>>>
>>> I'm starting to think that (4) is the better approach, as it won't break legacy
>>> applications, and it will provide an easier way for new applications to control
>>> the frontend with just one frontend.
>>
>> Approach 4 would break existing applications, because suddenly they'd
>> have to cope with an additional device. It would be impossible for an
>> existing application to tell whether frontend0 (from your example) was a
>> real device or not.

(not sure who commented this... somehow, I didn't receive the original email - well,
I'll just reply on Antti's answer)

Yes, an existing application will not know how to handle such fe, but, as the other
fe's are still provided, they can swill switch the delivery system by replacing the
frontend they're using. There are some alternatives for this approach, like:

Approach 5) fe0 is a frontend "superset", initialized to handle the first registered
delivery system

>>> *adapter0
>>> *frontend0 (DVB-S/DVB-S2), but allows changing to DVB-T/DVB-T2/DVB-C/ISDB-T
>>> *frontend1 (DVB-T/DVB-T2)
>>> *frontend2 (DVB-C)
>>> *frontend3 (ISDB-T)

(so, it is something between approach 1 and 4)

Being frankly, I think that this would be messy.

In any case, I think that, if we decide for something like approach 4 or 5, we 
should deprecate the support for the extra frontends, after kernel + 2 versions,
so, falling back into approach 2 (e. g. just one frontend for all delivery systems).

I also think that we should get a decision about that for 3.1, and port DRX-K to
the agreed approach before the release of 3.1, as it will be one less driver that
we'll need to concern about migrating.

Cheers,
Mauro