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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to