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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3EED5C04A6A for ; Thu, 13 Jul 2023 15:15:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233597AbjGMPPv (ORCPT ); Thu, 13 Jul 2023 11:15:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49798 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229916AbjGMPPt (ORCPT ); Thu, 13 Jul 2023 11:15:49 -0400 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2AB2EA2; Thu, 13 Jul 2023 08:15:47 -0700 (PDT) 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="350089204" X-IronPort-AV: E=Sophos;i="6.01,203,1684825200"; d="scan'208";a="350089204" 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?= Cc: Jani Nikula , =?UTF-8?Q?Heiko_St=c3=bcbner?= , Geert Uytterhoeven , Xinliang Liu , Linus Walleij , Tomi Valkeinen , Alexey Kodanev , dri-devel@lists.freedesktop.org, Vandita Kulkarni , Alim Akhtar , Anitha Chrisanthus , Marijn Suijten , Jonathan Hunter , Arun R Murthy , Jerome Brunet , Liu Shixin , 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 , linux-sunxi@lists.linux.dev, Stylon Wang , Tim Huang , Suraj Kandpal , =?UTF-8?Q?Andr=c3=a9_Almeida?= , Andi Shyti , Yifan Zhang , Leo Li , Sascha Hauer , Lucas De Marchi , Inki Dae , Hersen Wu , Jessica Zhang , 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 , Zack Rusin , Gerd Hoffmann , 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 , =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= , David Lechner , Juha-Pekka Heikkila , "Jiri Slaby (SUSE)" , David Francis , Aaron Liu , Patrik Jakobsson , Vinod Polimera , linux-rockchip@lists.infradead.org, Fangzhi Zuo , Aurabindo Pillai , VMware Graphics Reviewers , Ben Skeggs , =?UTF-8?Q?Jouni_H=c3=b6gander?= , Dave Airlie , linux-mips@vger.kernel.org, Gurchetan Singh , Martin Blumenstingl , linux-arm-msm@vger.kernel.org, Animesh Manna , linux-renesas-soc@vger.kernel.org, Maxime Ripard , Chaitanya Kumar Borah , Philipp Zabel , linux-amlogic@lists.infradead.org, Evan Quan , Michal Simek , linux-arm-kernel@lists.infradead.org, Sean Paul , Neil Armstrong , Kai Vehmanen , Boris Brezillon , Chunyan Zhang , Qingqing Zhuo , Sandy Huang , Swati Sharma , John Stultz , Paul Kocialkowski , Kyungmin Park , Drew Davenport , Kevin Hilman , Hawking Zhang , Haneen Mohammed , Anusha Srivatsa , Dan Carpenter , Karol Herbst , Joonas Lahtinen , linux-hyperv@vger.kernel.org, Stefan Agner , Melissa Wen , =?UTF-8?Q?Ma=c3=adra_Canal?= , Luca Coelho , Laurent Pinchart , Andrzej Hajda , Likun Gao , Sam Ravnborg , Alain Volmat , Xinwei Kong , Jernej Skrabec , Deepak Rawat , Chen-Yu Tsai , Joel Stanley , Ankit Nautiyal , Harry Wentland , Sumit Semwal , Alan Liu , Philip Yang , Lyude Paul , intel-gfx@lists.freedesktop.org, Alison Wang , Wolfram Sang , Abhinav Kumar , Gustavo Sousa , Baolin Wang , Rodrigo Vivi , Mikko Perttunen , Rodrigo Siqueira , Tomi Valkeinen , Deepak R Varma , "Pan, Xinhui" , Biju Das , Chia-I Wu , Konrad Dybcio , Kieran Bingham , Tian Tao , Shawn Guo , =?UTF-8?Q?Christian_K=c3=b6nig?= , Khaled Almahallawy , linux-stm32@st-md-mailman.stormreply.com, Emma Anholt , Chun-Kuang Hu , Imre Deak , Liviu Dudau , Alexandre Torgue , Roman Li , Paul Cercueil , Rob Clark , Hamza Mahfooz , David Airlie , Marek Vasut , Jiapeng Chong , xen-devel@lists.xenproject.org, Guchun Chen , Oleksandr Andrushchenko , Raphael Gallais-Pou , Rodrigo Siqueira , Russell King , Uma Shankar , Mika Kahola , Maxime Coquelin , Jiasheng Jiang , Srinivasan Shanmugam , Vinod Govindapillai , linux-tegra@vger.kernel.org, =?UTF-8?B?TWFyZWsgT2zFocOhaw==?= , Maarten Lankhorst , =?UTF-8?Q?Joaqu=c3=adn_Ignacio_Aramend=c3=ada?= , Melissa Wen , Hans de Goede , linux-mediatek@lists.infradead.org, Fabio Estevam , Laurentiu Palcu , Matthias Brugger , David Tadokoro , AngeloGioacchino Del Regno , Orson Zhai , amd-gfx@lists.freedesktop.org, Jyri Sarha , Yannick Fertre , Nicolas Ferre , Krzysztof Kozlowski , Philippe Cornu , Daniel Vetter , Wayne Lin , Dmitry Baryshkov , Nirmoy Das , Lang Yu , Lucas Stach 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 Precedence: bulk List-ID: X-Mailing-List: linux-tegra@vger.kernel.org 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