Em Sun, 22 Aug 2021 17:21:41 +0200 Soeren Moch <smoch@xxxxxx> escreveu: > > There's no regression: a legacy driver (av7110) for a device that stopped > > being manufactured 15 years ago and that doesn't work anymore with current > > Digital TV transmissions was removed, together with the API that it was > > implemented inside such driver's code. > What you write here is simply not true. > > The "device" (saa7146/av7110-based full-featured DVB card) is working > well. Probably not true - at least for some av7110-based boards - as there was a regression that no user ever noticed: https://lore.kernel.org/lkml/20210503115736.2104747-59-gregkh@xxxxxxxxxxxxxxxxxxx/ This was noticed only too late, due to a review of the offended patch caused by "hypocrite commits"[1]. [1] https://lwn.net/Articles/854645/. > Also with current Digital TV transmissions (e.g. Astra Satellite > TV in Europe). The DVB API never was implemented in driver's code, it is > linux userspace API (include/uapi/linux/dvb/). The DVB API used by all upstream drivers is implemented inside the DVB core (at drivers/media/dvb-core/). The "full-featured" API consists on the DVB API + some extra ioctls defined at the uAPI headers, plus an av7110 implementation, which covered only part of the ioctls that were defined at the headers. > You moved files out of the uapi part of kernel headers, parts of e.g. > RedHat userspace stops to build due to this. So it is a userspace > regression. Again, this is not a Kernel regression. There isn't a single bit of code inside the Kernel that it would require the "full-feat" uapi. If an app implements support to some OOT driver(s), it has to carry on the OOT userspace code for such driver(s), together with any needed headers for such support. So, you should submit a patch to such app maintainers directly - and/or to the distro packages that would have packages providing support for such OOT driver(s). Btw, as far as I'm aware, Red Hat's Kernels don't come with the saa716x OOT driver. > > The av7110 production stopped ~15 years ago. > But the cards work perfectly well. I own two such cards, there is no > problem at all with them. Other members of the community even test with > -rc3 kernels and file RedHat bugs. So there clearly is interest in them. Nobody is telling otherwise. If people want to use OOT drivers, that's OK. Nobody is preventing people to use it, nor to use the apps developed for such devices. Keeping av7110 in-kernel has been a waste of limited upstream development resources. A couple of years ago, we needed to fix the av7110 API due to year-2038 issues. From time to time, we get bugs affecting it (even security ones), as the code has been bit-rotting for a long time. The most recent one probably broke the driver without nobody noticing it for a couple of Kernel reviews, as mentioned above. > > This is a legacy hardware, which supports only the first generation of DVB > > standards, and had an integrated MPEG-2 decoder. As most DVB transmissions > > use MPEG4 or newer encoding schemas that didn't exist back in 1999, it > > doesn't make any sense keeping such driver upstream nowadays. > As I wrote in my previous email: most private TV stations in Germany > provide their free-to-air satellite programs MPEG-2 encoded only. > Therefore this is very popular and it absolutely makes sense to keep > this driver upstream. It is probably a lot easier to get a modern DVB "budget" card with supports not only MPEG-2 but all encoding standards than to find an old "full-feat" DVB card with av7110 those days. Who still provides saa71xx chips those days? As far as I'm aware, Philips semiconductors (who used to produce such chipsets) was split into NXP in 2006, and the entire digital TV chipset line moved altogether. I can't find any references those days to any saa71xx at either NXP or Philips websites. > > The API that got removed was written to control the av7110 MPEG-2 decoder, > > and was never integrated at the DVB core: the av7110 had a driver-specific > > implementation inside its code. > This is simply not true. > The DVB API is linux userspace API, absolutely nothing driver specific > inside driver's code. >From upstream PoV, it is an av7110-specific API, as all in-kernel support was inside av7110 driver's code. > > The saa716x driver you're mentioned is an out of tree driver. > > We don't keep APIs at the upstream Kernel due to OOT drivers. > Strong words to distract from the main point: > This regression report is about upstream DVB userspace API and the > saa7146/av7110 driver, both part of mainline linux for a long time. Removing a legacy driver is not a regression. See, you're the one trying to distract from the main point: The saa716x driver is OOT. There was never any upstream support for it. None of the patches you're mentioning prevents anyone to keep building it as an OOT driver. What it was removed was the av7110, together with the API header files that were used only by this single driver. > you stripped almost everything from my previous email, you did not > answer any questions or gave any explanation for your behavior. I striped the points already discussed with you when I gave you feedback about the saa716x patchset [2], as this is a completely separate discussion than the removal of av7110 support. In summary, it makes no sense to claim that saa716x OOT driver broke because a different driver was removed upstream. Thanks, Mauro [2] https://lore.kernel.org/linux-media/20180307121438.389f411c@xxxxxxxxx/
