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 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A9E2EC001DC for ; Fri, 14 Jul 2023 07:15:46 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 794D710E7E9; Fri, 14 Jul 2023 07:14:59 +0000 (UTC) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by gabe.freedesktop.org (Postfix) with ESMTPS id 82CC710E6F9; Thu, 13 Jul 2023 15:15:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1689261347; x=1720797347; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=FdV+ihBB75TX4OJUKwPysdCuraDJ8JqOsAXrG1NV6Qw=; b=XdGzFJhISwDiDbnWBAYeUC4zJhZMbuZfQYsgCs3V8XtGKbcbkDzg+upH txq/U57jv5mpjolZu18qryVqA916tu/0TXOCShnci127EuC4+BRL70Fp7 d0Acc92wVR9HsFcQ5YHhzYoK3W3EooSCdF56SKXOlL6Bjh9vWgZsuYmog YaNwg8iU7PQGml94JycoI+kr74eyStfrO1xJnHdZ1yiVU9M31ZkNOsv4E ezj2G69i6yChQSzMru2O9eSvUmv2FSadzvlYJjNB71dremcK92v8P+SUD gJ9FT02JXZx2yFsR4MNlOtWaUB9/xERDqf/t7dlte8lrIN/8nCMYE0Zhv Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10770"; a="350089215" X-IronPort-AV: E=Sophos;i="6.01,203,1684825200"; d="scan'208";a="350089215" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jul 2023 08:15:44 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10770"; a="968656199" X-IronPort-AV: E=Sophos;i="6.01,203,1684825200"; d="scan'208";a="968656199" Received: from apaulaux-mobl.ger.corp.intel.com (HELO [10.213.206.56]) ([10.213.206.56]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jul 2023 08:14:58 -0700 Message-ID: Date: Thu, 13 Jul 2023 16:14:55 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [Freedreno] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev Content-Language: en-US To: Thomas Zimmermann , Sean Paul , =?UTF-8?Q?Uwe_Kleine-K=c3=b6nig?= References: <20230712094702.1770121-1-u.kleine-koenig@pengutronix.de> <87fs5tgpvv.fsf@intel.com> <20230713130337.fd2l67r23g2irifx@pengutronix.de> <78be52b8-5ffb-601a-84b2-ead2894973a6@suse.de> From: Tvrtko Ursulin Organization: Intel Corporation UK Plc In-Reply-To: <78be52b8-5ffb-601a-84b2-ead2894973a6@suse.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 14 Jul 2023 07:14:54 +0000 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Geert Uytterhoeven , Xinliang Liu , Rodrigo Vivi , Alexey Kodanev , dri-devel@lists.freedesktop.org, Vandita Kulkarni , Alim Akhtar , Anitha Chrisanthus , Marijn Suijten , Jonathan Hunter , Arun R Murthy , Jerome Brunet , linux-samsung-soc@vger.kernel.org, Samuel Holland , Matt Roper , Wenjing Liu , Javier Martinez Canillas , Stanislav Lisovskiy , Danilo Krummrich , NXP Linux Team , spice-devel@lists.freedesktop.org, Niranjana Vishwanathapura , Dmitry Baryshkov , linux-sunxi@lists.linux.dev, Matthias Brugger , Stylon Wang , Tim Huang , Suraj Kandpal , =?UTF-8?Q?Andr=c3=a9_Almeida?= , Mika Kahola , Raphael Gallais-Pou , Leo Li , Sascha Hauer , Lucas De Marchi , Hersen Wu , Dave Airlie , Kamlesh Gurudasani , Bhawanpreet Lakha , =?UTF-8?Q?=c5=81ukasz_Bartosik?= , Radhakrishna Sripada , Andrew Jeffery , Seung-Woo Kim , =?UTF-8?Q?Noralf_Tr=c3=b8nnes?= , kernel@pengutronix.de, Alex Deucher , freedreno@lists.freedesktop.org, Claudiu Beznea , Laurent Pinchart , Alexandre Belloni , linux-aspeed@lists.ozlabs.org, nouveau@lists.freedesktop.org, Mitul Golani , =?UTF-8?Q?Jos=c3=a9_Roberto_de_Souza?= , virtualization@lists.linux-foundation.org, Thierry Reding , Yongqin Liu , Mario Limonciello , Fei Yang , Juha-Pekka Heikkila , Chunyan Zhang , David Francis , Vinod Govindapillai , Aaron Liu , Vinod Polimera , linux-rockchip@lists.infradead.org, Fangzhi Zuo , Aurabindo Pillai , VMware Graphics Reviewers , Ben Skeggs , =?UTF-8?Q?Jouni_H=c3=b6gander?= , Jessica Zhang , Martin Blumenstingl , linux-arm-msm@vger.kernel.org, Animesh Manna , Nicolas Ferre , Maxime Ripard , Chaitanya Kumar Borah , Tian Tao , Biju Das , linux-amlogic@lists.infradead.org, Evan Quan , Michal Simek , linux-arm-kernel@lists.infradead.org, Sean Paul , Neil Armstrong , Kai Vehmanen , Boris Brezillon , Shawn Guo , Qingqing Zhuo , Sandy Huang , Swati Sharma , linux-renesas-soc@vger.kernel.org, Kyungmin Park , Maxime Coquelin , Kevin Hilman , Hawking Zhang , Haneen Mohammed , Paul Cercueil , Anusha Srivatsa , Dan Carpenter , Karol Herbst , linux-hyperv@vger.kernel.org, Melissa Wen , =?UTF-8?Q?Ma=c3=adra_Canal?= , Luca Coelho , Gerd Hoffmann , Andrzej Hajda , Likun Gao , "Jiri Slaby \(SUSE\)" , Emma Anholt , Alain Volmat , Chen-Yu Tsai , Jernej Skrabec , Deepak Rawat , Xinwei Kong , Joel Stanley , Orson Zhai , Ankit Nautiyal , Alan Liu , Philip Yang , intel-gfx@lists.freedesktop.org, Alison Wang , Wolfram Sang , Abhinav Kumar , Gustavo Sousa , Baolin Wang , Tomi Valkeinen , Mikko Perttunen , Yifan Zhang , Rodrigo Siqueira , Tomi Valkeinen , Deepak R Varma , "Pan, Xinhui" , Konrad Dybcio , Kieran Bingham , John Stultz , Roman Li , Sumit Semwal , =?UTF-8?Q?Christian_K=c3=b6nig?= , Khaled Almahallawy , linux-stm32@st-md-mailman.stormreply.com, Sam Ravnborg , Chun-Kuang Hu , Liviu Dudau , Alexandre Torgue , Gurchetan Singh , Liu Shixin , Krzysztof Kozlowski , Hamza Mahfooz , Marek Vasut , Paul Kocialkowski , xen-devel@lists.xenproject.org, Guchun Chen , Oleksandr Andrushchenko , Rodrigo Siqueira , Russell King , Jani Nikula , Uma Shankar , Andi Shyti , Jiasheng Jiang , Srinivasan Shanmugam , David Lechner , Jiapeng Chong , =?UTF-8?B?TWFyZWsgT2zFocOhaw==?= , =?UTF-8?Q?Joaqu=c3=adn_Ignacio_Aramend=c3=ada?= , Melissa Wen , Hans de Goede , linux-mediatek@lists.infradead.org, Laurentiu Palcu , linux-tegra@vger.kernel.org, David Tadokoro , AngeloGioacchino Del Regno , amd-gfx@lists.freedesktop.org, Lang Yu , Yannick Fertre , linux-mips@vger.kernel.org, Philippe Cornu , Wayne Lin , Drew Davenport , Nirmoy Das , Jyri Sarha Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On 13/07/2023 16:09, Thomas Zimmermann wrote: > Hi > > Am 13.07.23 um 16:41 schrieb Sean Paul: >> On Thu, Jul 13, 2023 at 9:04 AM Uwe Kleine-König >> wrote: >>> >>> hello Sean, >>> >>> On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote: >>>> I'd really prefer this patch (series or single) is not accepted. This >>>> will cause problems for everyone cherry-picking patches to a >>>> downstream kernel (LTS or distro tree). I usually wouldn't expect >>>> sympathy here, but the questionable benefit does not outweigh the cost >>>> IM[biased]O. >>> >>> I agree that for backports this isn't so nice. However with the split >>> approach (that was argumented against here) it's not soo bad. Patch #1 >>> (and similar changes for the other affected structures) could be >>> trivially backported and with that it doesn't matter if you write dev or >>> drm (or whatever name is chosen in the end); both work in the same way. >> >> Patch #1 avoids the need to backport the entire set, however every >> change occuring after the rename patches will cause conflicts on >> future cherry-picks. Downstream kernels will have to backport the >> whole set. Backporting the entire set will create an epoch in >> downstream kernels where cherry-picking patches preceding this set >> will need to undergo conflict resolution as well. As mentioned in my >> previous email, I don't expect sympathy here, it's part of maintaining >> a downstream kernel, but there is a real cost to kernel consumers. >> >>> >>> But even with the one-patch-per-rename approach I'd consider the >>> renaming a net win, because ease of understanding code has a big value. >>> It's value is not so easy measurable as "conflicts when backporting", >>> but it also matters in say two years from now, while backporting >>> shouldn't be an issue then any more. >> >> You've rightly identified the conjecture in your statement. I've been >> on both sides of the argument, having written/maintained drm code >> upstream and cherry-picked changes to a downstream kernel. Perhaps >> it's because drm's definition of dev is ingrained in my muscle memory, >> or maybe it's because I don't do a lot of upstream development these >> days, but I just have a hard time seeing the benefit here. > > I can only second what Sean writes. I've done quite a bit of backporting > of DRM code. It's hard already. And this kind of change is going to to > affect almost every backported DRM patch in the coming years. Not just > for distribution kernels, but also for upstream's stable series. It's > really only possible to do this change over many releases while keeping > compatible with the old name. So the more I think about it, the less I > like this change. I've done my share of backporting, and still am doing it, so I can say I dislike it as much as anyone, however.. Is this an argument which the kernel as a wider entity typically accepts? If not could it be a slippery slope to start a precedent? It is a honest question - I am not familiar if there were or were not any similar discussions in the past. My gut feeling is that *if* there is a consensus that something _improves_ the code base significantly, backporting pains should probably not be weighted very heavily as a contra argument. Regards, Tvrtko