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

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

Em 25-11-2011 10:00, Andreas Oberritter escreveu:
> On 24.11.2011 19:47, Mauro Carvalho Chehab wrote:
>> Em 24-11-2011 16:13, Manu Abraham escreveu:
>>> On Thu, Nov 24, 2011 at 11:38 PM, Mauro Carvalho Chehab
>>> <mchehab@redhat.com> wrote:
>>>> Em 24-11-2011 16:01, Manu Abraham escreveu:
>>>>> On Thu, Nov 24, 2011 at 11:14 PM, Hans Verkuil <hverkuil@xs4all.nl> 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.
>>>>>
>>>>>
>>>>> That won't work with other non av7110 hardware.
>>>>
>>>> There isn't any non-av7110 driver using it at the Kernel. Anyway, we can put
>>>> a warning at the existing headers as-is, for now, putting them to be removed
>>>> for a new kernel version, like 3.4.
>>>
>>>
>>> No, that's not an option. The to-be merged saa716x driver depends on it.
>>
>> If the driver is not merged yet, it can be changed.
>>
>>> A DVB alone device need not depend V4L2 for it's operation.
>>
>> Why not? DVB drivers with IR should implement the input/event/IR API. DVB drivers with net
>> should implement the Linux Network API.
> 
> DVB doesn't specify IR. There's no such thing like a DVB IR device.
> 
> IP over DVB is implemented transparently. No driver needs to do anything
> but register its device's MAC address, therefore no driver implements
> the Linux Network API.
> 
>> There is nothing wrong on using the ALSA API for audio and the V4L2 API for video,
>> as both API fits the needs for decoding audio and video streams, and new features
>> could be added there when needed.
> 
> Yes. There's nothing wrong with it and I'm not complaining. I don't care
> about the implementation of the API in ivtv either. Just don't remove
> the API from dvb-core, period.
> 
>> Duplicated API's that become legacy are removed with time. Just to mention two
>> notable cases, this happened with the old audio stack (OSS), with the old Wireless
>> stack.
> 
> I can still use iwconfig and linux/wireless.h is still available on my
> system.

Yes, but both iwconfig and the API changed.

> ALSA still provides OSS emulation and the real OSS stack was marked
> deprecated but still present for ages. 

OSS driver submission stopped years ago. I remember it clearly as they denied cx88-oss 
driver submission (2004 or 2005). The saa7134-oss and bttv-oss drivers were dropped in 2007[1]
in favor of the alsa drivers. The only hardware that are still there at OSS are the 
legacy ones that probably no alsa developer has anymore.

[1] http://kerneltrap.org/mailarchive/linux-kernel/2007/11/9/398438/thread

> In contrast, you want to remove a
> stable API and introduce a new *completely untested* API between 3.3 and
> 3.4.

Please read the patches again. The API for the devices are still there:
any binary compiled for older kernels will still work with av7110 and ivtv.
With the patches applied, the only difference is that the header file has
renamed, as they were moved to device-specific headers.

It should be noticed that, while both av7110 and ivtv uses the same ioctl's, av7110
creates devices over /dev/dvb, while ivtv uses it over /dev/video?. So, in practice, 
each driver has a different API.

There are no plans to remove the API for av7110. 

As discussed on this thread, it seems that the agreed plans for the ivtv API is to put
it into the standard kernel procedure to get rid of legacy API. That means that the API 
will be there for a few kernel versions.

Hans proposal is to remove the ivtv API on 3.8, with seems reasonable. So, the first
API removal will happen in about 18 months from now (assuming about 2 months per kernel 
version).

>> Do you have any issues that needs to be addressed by the V4L2 API for it to fit
>> on your needs?
> 
> I don't want to be forced to use the V4L2 API for no reason and no gain.

As already explained on the other email, there are gains on using it, like the support
for other types of encoding, the pipeline setup, sub-device control, shared buffer interface
with GPU, proper support for SoC, etc.

Also, currently, just one device uses it (av7110). I don't think that the chipset is
still manufactured. At least Google didn't help finding anything:
	http://www.google.com/search?q=av7110&tbm=shop&hl=en

On the other hand, there are thousands of devices using V4L2 API.

As both API's provide support for decoded video, one API has to be deprecated in favor
to the other. We should select for deprecation the one that is more restrictive
and that has just one driver using it.

> 
>>> Also, it doesn't
>>> make any sense to have device specific headers to be used by an application,
>>> when drivers share more than one commonality.
>>
>> The only in-kernel driver using audio/video/osd is av7110.
> 
> Once again: Manu is going to submit a new driver soon.

The API is there for several years (since 2002?), with just one driver supporting it.
It shouldn't be hard to convert Manu's work to the V4L2. I can help him on converting
his driver to use the V4L2 API if needed.

> You're trying to remove an API that you've never used. The people who
> use the API want it to stay.

As I said, it will stay there. Nobody will remove av7110 or remove the old API from it.

The idea is that no new driver should use it, as it is a legacy one-driver-only API.

If your complain is about the removal of audio.h, video.h and osd.h, then my proposal is
to keep it there, writing a text that they are part of a deprecated API, but keeping
the rest of the patches and not accepting anymore any submission using them, removing
the ioctl's that aren't used by av7110 from them.

Regards,
Mauro