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