Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

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

Em 24-11-2011 16:07, Andreas Oberritter escreveu:
> On 24.11.2011 18:58, Mauro Carvalho Chehab wrote:
>> Em 24-11-2011 15:51, Andreas Oberritter escreveu:
>>> On 24.11.2011 18:44, Hans Verkuil wrote:
>>>> On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote:
>>>>> Don't break existing Userspace APIs for no reason! It's OK to add the
>>>>> new API, but - pretty please - don't just blindly remove audio.h and
>>>>> video.h. They are in use since many years by av7110, out-of-tree drivers
>>>>> *and more importantly* by applications. Yes, I know, you'd like to see
>>>>> those out-of-tree drivers merged, but it isn't possible for many
>>>>> reasons. And even if they were merged, you'd say "Port them and your
>>>>> apps to V4L". No! That's not an option.
>>>>
>>>> I'm not breaking anything. All apps will still work.
>>>>
>>>> One option (and it depends on whether people like it or not) is to have
>>>> audio.h, video.h and osd.h just include av7110.h and add a #warning
>>>> that these headers need to be replaced by the new av7110.h.
>>>>
>>>> And really remove them at some point in the future.
>>>>
>>>> But the important thing to realize is that the ABI hasn't changed (unless
>>>> I made a mistake somewhere).
>>>
>>> So why don't you just leave the headers where they are and add a notice
>>> about the new V4L API as a comment?
>>>
>>> What you proposed breaks compilation. If you add a warning, it breaks
>>> compilation for programs compiled with -Werror. Both are regressions.
>>
>> I don't mind doing it for 3.3 kernel, and add a note at
>> Documentation/feature-removal-schedule.txt that the
>> headers will go away on 3.4. This should give distributions
>> and app developers enough time to prevent build failures, and
>> prepare for the upcoming changes.
> 
> Are you serious?
> 
> Breaking things that worked well for many years - for an artificially
> invented reason - is so annoying, I can't even find the words to express
> how much this sucks.

Andreas,

All the in-kernel API's are there to support in-kernel drivers.

Out of tree drivers can do whatever they want. As you likely know, several STB 
vendors have their own API's. 

Some use some variants of DVBv3 or DVBv5, and some use their own proprietary
API's, that are even incompatible with DVB (and some even provide both).

Even the ones that use DVBv3 (or v5) have their own implementation that diverges
from the upstream one.

Provided that such vendors don't violate the Kernel GPLv2 license where it applies, 
they're free do do whatever they want, forking the DVB API, or creating their own
stacks.

So, keeping the in-kernel unused ioctl's don't bring any real benefit, as vendors
can still do their forks, and applications designed to work with those hardware 
need to support the vendor's stack.

On the other hand, keeping an outdated API that doesn't fit well for the vendors
that want to upstream their STB drivers is bad, as it creates confusion for
them, and prevents innovation, as they may try to workaround on the limitation of
an API designed for the first generation DVB standards.

That's what Hans patches are addressing.

If you have a better approach, feel free to suggest it, provided that, at the end,
the API that aren't used by non-legacy drivers are removed (or moved to driver's
specific ioctl's).

Regards,
Mauro