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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E246BC001E0 for ; Mon, 14 Aug 2023 15:33:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7DD228E0002; Mon, 14 Aug 2023 11:33:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 78CCC8E0001; Mon, 14 Aug 2023 11:33:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 654328E0002; Mon, 14 Aug 2023 11:33:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 5340D8E0001 for ; Mon, 14 Aug 2023 11:33:58 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 1BF121C8B29 for ; Mon, 14 Aug 2023 15:33:58 +0000 (UTC) X-FDA: 81123105756.24.009146B Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf16.hostedemail.com (Postfix) with ESMTP id F08ED180018 for ; Mon, 14 Aug 2023 15:33:54 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=akFhWRIw; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf16.hostedemail.com: domain of pmladek@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=pmladek@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692027235; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=PQUYAWAb1k9Z/YmXHKlOUY17GrFAyEmuzFZMJMKUnBY=; b=rIMddQXeD8gubXNs1oMTWx4wmZR8KKjVNrKr+/3aLARTNWSqO8MCu5IwtAJi91l8x74pZS GH9iV1KH1kL+rrlpForVpnRci7tddTtxV7HUC2o5As7R1jOI9FrmZgbbX+rnfdtsIxrg4t GsesTU2ivD0qwFy8p8CGWbFsy6PWUtY= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=akFhWRIw; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf16.hostedemail.com: domain of pmladek@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=pmladek@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692027235; a=rsa-sha256; cv=none; b=6zZj6WJHuvEzsEFnllYVeSaPNJe70/IrVq/YzOJdCKGituK4QQ9+wc2N+qP5L/cb2VPnpO kWBoWIVy/BLmi/dZDffAyyyOdRwHh6Q1Hx3WgadFyGjxiJPu+rZ6BCdz2CZFRsLlXfl8J3 X0xLImqmYzEk+8mmLuXULMVH9cdRous= Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 5B2311F45B; Mon, 14 Aug 2023 15:33:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1692027233; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=PQUYAWAb1k9Z/YmXHKlOUY17GrFAyEmuzFZMJMKUnBY=; b=akFhWRIwcKkZJ1HqiOw2FkVywMcrW3YdODW66y3Ojg8RdRtsOTpTMn0s55q6+DzcqfU7bO z7iDB14FgzJMzKwzAoLDAjlSpNBV50zVhxTMTOvp7Osyepfj2TgLR/cEwrBWPiF0X7WLCh CHbGArNyGlr2OL2mfNV5LCaPwLB12Ds= Received: from suse.cz (pmladek.udp.ovpn2.prg.suse.de [10.100.201.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id EE8C92C143; Mon, 14 Aug 2023 15:33:52 +0000 (UTC) Date: Mon, 14 Aug 2023 17:33:49 +0200 From: Petr Mladek To: Rasmus Villemoes Cc: Andy Shevchenko , Marco Elver , linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, linux-mm@kvack.org, Steven Rostedt , Sergey Senozhatsky , Alexander Potapenko , Dmitry Vyukov , Andrew Morton Subject: Re: [PATCH v2 1/3] lib/vsprintf: Sort headers alphabetically Message-ID: References: <20230805175027.50029-1-andriy.shevchenko@linux.intel.com> <20230805175027.50029-2-andriy.shevchenko@linux.intel.com> <5eca0ab5-84be-2d8f-e0b3-c9fdfa961826@rasmusvillemoes.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5eca0ab5-84be-2d8f-e0b3-c9fdfa961826@rasmusvillemoes.dk> X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: F08ED180018 X-Stat-Signature: psi498mwqzzbziehoxugcww8c7ugeza3 X-HE-Tag: 1692027234-766181 X-HE-Meta: U2FsdGVkX18YfIOVxDwHjYDGbAfGtcZtr09TOAgRw40az+hjiFIuF+q1LDXVD5tReIK/0TtTaaHx9FbDw0z1sHGf1yHyKVFRYWocSxPSzJroNvD7vMCpMh4wxfutcJOfkd5vtP1ouIHrZxOpBJkUHjEJIx4ZsEdYLPS2SmB2HCgVa2mGSGUPMRrBZ0GxrYD/+qHrQ7Vu8gJsiHqy365SWPe1FqNqNqNycQmW7uefmZVc1ap6jqugHqg1SpwhhIABJUA/mYcXLC0lme5ygj5YRI9HFNNPRM57g0I9bumWrkNOoZTM5IhGx/KPTm+IUoicWOVRg2T4zG0mjij16UXfjU9SZfQvWRjW9yzWnIjlQreUNPN/YTK1rZXKMf2+89zAqaD6RTpsRuqpE1NTp/QTl528QUWKfC9M2GonzsTY+zIOjxqvoSRgVMEoeEvCf3sfnRJts0b1I0je88k0tuBsQ0tjBY+VbaNw2d75Q54tIFjdp5u+ISA61HP5NQXlRHj19ygOaHgBKzczl4/yy/tJ3/VP/sgzjd/k1zmzrAc1/pX/wW2sfuwEIdMHnFQtyAhE3fm6W+3rv48/Tc/PsXpbEqi8+HuO7XvfPtRug9WplJ3XV26eH/gMgaBjcbyb3O94aNtr+QJ2wRhHIp9N7ZKjnZJiXQzLTHICuSsAWtP8t7zwte7hdAHRLBPA3oNzmn7gDB4KU/hnSsr3etf9JSA9QhFb2NO245eUEuCh2ORtAJ7JPKFtXvfmemha4l5RQ9DJMy6gliJyVszFtALoHFXHJb2hwFwHPbJkUgA0f5oIx/AhZDr7q7bhsY7ygDVhJE3j9X7LO1E580LzTaMiTa6MHeltmo48MUWux7FbQJ5wHb3eja+i1ZdrkB6QkT3poMuwtw0EMSiDmB0rDhGVn3JWdL2PkRoqTcCdUNb9bFutIjXsSg3CH//+FWG20fUm57nzLFPqv1RoC5ziphjO94j QhyamRJl JqPYAV8vHNpP1uqlL07wVlF13JbIxL72NK5796ViqS/IJLR4tmXt7GDdB1VpNRKI4XkazKGWVhQhfIF6jLYnlqdRBpcwfzArSevo0qR7hCIYvNnzdN/fn7a2XV2VrE05UrkWaLz5ca1mAQ7kBpIJfFh+pAA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.011186, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon 2023-08-07 21:47:17, Rasmus Villemoes wrote: > On 07/08/2023 16.58, Andy Shevchenko wrote: > > On Mon, Aug 07, 2023 at 04:31:37PM +0200, Petr Mladek wrote: > >> On Sat 2023-08-05 20:50:25, Andy Shevchenko wrote: > >>> Sorting headers alphabetically helps locating duplicates, and > >>> make it easier to figure out where to insert new headers. > >> > >> I agree that includes become a mess after some time. But I am > >> not persuaded that sorting them alphabetically in random source > >> files help anything. > >> > >> Is this part of some grand plan for the entire kernel, please? > >> Is this outcome from some particular discussion? > >> Will this become a well know rule checked by checkpatch.pl? > >> > >> I am personally not going to reject patches because of wrongly > >> sorted headers unless there is some real plan behind it. > >> > >> I agree that it might look better. An inverse Christmas' tree > >> also looks better. But it does not mean that it makes the life > >> easier. > > > > It does from my point of view as maintainability is increased. > > > >> The important things are still hidden in the details > >> (every single line). > >> > >> From my POV, this patch would just create a mess in the git > >> history and complicate backporting. > >> > >> I am sorry but I will not accept this patch unless there > >> is a wide consensus that this makes sense. > > > > Your choice, of course, But I see in practice dup headers being > > added, or some unrelated ones left untouched because header list > > mess, and in those cases sorting can help (a bit) in my opinion. > > I agree with Andy on this one. There doesn't need to be some grand > master plan to apply this to the entire kernel, but doing it to > individual files bit by bit does increase the maintainability. And I > really don't buy the backporting argument. Sure, backporting some patch > across the release that does the sorting is harder - but then, > backporting the sorting patch itself is entirely trivial (maybe not the > textual part, but redoing the semantics of it is). _However_, > backporting a patch from release z to release y, both of which being > later than the release x that did the sorting, is going to be _easier_. > It also reduces merge conflicts - that's also why lots of Makefiles are > kept sorted. I am afraid that we will not find a consensus here. I agree that the sorting has some advantage. But I would still like to get some wider agreement on this move from other subsystem. It is a good candidate for a mass change which would be part of some plan. I want to avoid reshuffling this more times according to personal preferences. And I do not want to add this cosmetic subsystem specific requirement. Best Regards, Petr