From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 03F10C4338F for ; Tue, 24 Aug 2021 07:48:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D801B6125F for ; Tue, 24 Aug 2021 07:48:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234732AbhHXHsu (ORCPT ); Tue, 24 Aug 2021 03:48:50 -0400 Received: from mail.kernel.org ([198.145.29.99]:48654 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234618AbhHXHst (ORCPT ); Tue, 24 Aug 2021 03:48:49 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 2E0D061183; Tue, 24 Aug 2021 07:48:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1629791285; bh=KgbcpAcVlKxkKPGLwIaqYxCZnA9LBhYWX45e1GRD3p8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=oUMAgzI/pFM9ctDnnM6eYGOcKD/LYVTiF/AmevfMdxjhpISQ5uWEOMEkfZWdlgD/i HVXX50N4XuR5IpDAmWUpgpn/TQ0Lgj6sz/PjM3tXiD3cGi/16nRO4iUrBLWt+ciiHS +wjv3MKh7lAbAuwlnCWCJ7ggEuiw36ZcvYP77dg+drS7W6NPWVmJn8nEnOiXQl+nHg zzjrmUlDzFuFHwezgRJ45ubvaJtAuSeawQt17XBK79lNndbVlhsShyipacDn8uyaju I5ecsdcECw8OKpvjN9YTvoiwqqPkkJRLjP1XWB436M9zdDf24dt4qOklvMEhVq5YWv iRqJ5k/knR7oA== Date: Tue, 24 Aug 2021 09:47:54 +0200 From: Mauro Carvalho Chehab To: Linus Torvalds Cc: Soeren Moch , Linux Media Mailing List , "linux-kernel@vger.kernel.org" Subject: Re: [Regression 5.14] media: dvb userspace api Message-ID: <20210824094754.32ad5eab@coco.lan> In-Reply-To: References: <4e3e0d40-df4a-94f8-7c2d-85010b0873c4@web.de> <20210819133128.45ef4353@coco.lan> <20210822194709.4b9d33d4@coco.lan> X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.30; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org Em Mon, 23 Aug 2021 09:58:00 -0700 Linus Torvalds escreveu: > On Mon, Aug 23, 2021 at 7:59 AM Soeren Moch wrote: > > > > Linus, > > > > Is what I described directly above the new linux maintenance policy? Or > > is linux media a private kingdom where the community should keep away? > > Is this a place where the subsystem maintainer is on a mission to > > destroy everything instead of maintaining and improving it? Please tell > > me what I understood wrong here. > > So technically, the regression policy for the kernel is purely about > the ABI - the _binary_ interface. That seems to not have broken - old > programs continue to work. > > We very much try to discourage user space applications from using the > kernel header files directly - even projects like glibc etc are > supposed to _copy_ them, not include the kernel headers. Unfortunately, media APIs aren't part of projects like glibc. Almost all open source media apps keep their own copies of the uAPI header files. As far as I'm aware, the "full-feat" API is implemented only by some modules of VDR. I don't know any other open source application using such headers. > Exactly because re-organization and changes to the kernel tree > shouldn't be something that then causes random problems elsewhere that > are so hard to test - and synchronize - from the kernel standpoint (or > from the standpoint of the other end). > > That clearly doesn't seem to be the case in this situation. Which is > annoying as heck. > > Mauro: there clearly _are_ users of those header files, and even > apparently that one old driver out there. And those headers were in > the 'uapi' directory, so while it is annoying how user space programs > used them this way, I think it's also not entirely unreasonable. > > I have reverted the header file move. But I would also heartily > recommend that whatever user program includes those headers (VDR - > anything else?) should take snapshots of these specific kernel > headers. > > I'm not convinced that it makes sense to move the av7110 driver back > from staging - it may continue to work, but it _is_ old and there is > no maintenance - and I would certainly suggest that any other > out-of-tree driver that uses these old interfaces that nothing else > implements shouldn't do so, considering that nothing else implements > them. > > So the only thing I did was move the header files back, and mark that > move to be backported to 5.13 stable. Ok. Thanks, Mauro