Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <5eca0ab5-84be-2d8f-e0b3-c9fdfa961826@rasmusvillemoes.dk>
Date:   Mon, 7 Aug 2023 21:47:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.13.0
Subject: Re: [PATCH v2 1/3] lib/vsprintf: Sort headers alphabetically
Content-Language: en-US, da
To:     Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Petr Mladek <pmladek@suse.com>
Cc:     Marco Elver <elver@google.com>, linux-kernel@vger.kernel.org,
        kasan-dev@googlegroups.com, linux-mm@kvack.org,
        Steven Rostedt <rostedt@goodmis.org>,
        Sergey Senozhatsky <senozhatsky@chromium.org>,
        Alexander Potapenko <glider@google.com>,
        Dmitry Vyukov <dvyukov@google.com>,
        Andrew Morton <akpm@linux-foundation.org>
References: <20230805175027.50029-1-andriy.shevchenko@linux.intel.com>
 <20230805175027.50029-2-andriy.shevchenko@linux.intel.com>
 <ZNEASXq6SNS5oIu1@alley> <ZNEGrl2lzbbuelV7@smile.fi.intel.com>
From:   Rasmus Villemoes <linux@rasmusvillemoes.dk>
In-Reply-To: <ZNEGrl2lzbbuelV7@smile.fi.intel.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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.

It's of course entirely unrelated to moving the declarations of the
provided functions to a separate header file, but IMO both are worth doing.

Rasmus