From: David Hildenbrand <david@redhat.com>
To: Max Kellermann <max.kellermann@ionos.com>
Cc: Kiryl Shutsemau <kirill@shutemov.name>,
akpm@linux-foundation.org, axelrasmussen@google.com,
yuanchu@google.com, willy@infradead.org, hughd@google.com,
mhocko@suse.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, lorenzo.stoakes@oracle.com,
Liam.Howlett@oracle.com, vbabka@suse.cz, rppt@kernel.org,
surenb@google.com, vishal.moola@gmail.com
Subject: Re: [PATCH v2 01/12] mm/shmem: add `const` to lots of pointer parameters
Date: Mon, 1 Sep 2025 11:41:49 +0200 [thread overview]
Message-ID: <661e6140-572b-4480-9ca2-6a127730f32b@redhat.com> (raw)
In-Reply-To: <CAKPOu+_wQ9DDHOQDtFeXU7ZqwvwxYqXNqWeSP3zJpfC0Cm2YAA@mail.gmail.com>
On 01.09.25 11:26, Max Kellermann wrote:
> On Mon, Sep 1, 2025 at 10:35 AM David Hildenbrand <david@redhat.com> wrote:
>> We usually write complete sentences, and there is nothing wrong with
>> repeating what the subject says.
>>
>> All the time it takes you to argue here would be better used improving
>> your patch descriptions.
>
> Sure, but first I need to know what is really needed. Reviews on LKML
> are often contradictory, and it's easy to get pushed around from one
> corner to the next.
Yeah, and that sucks and I'm sorry if that happened to you in the past.
If you ever get pushback on (a) splitting patches into reasonable
logical chunks or (b) writing a short yet concise patch description that
explains what the patch does and why, feel free to CC me.
>
> I just posted v4 with longer commit messages. I think that's a lot of
> unnecessary noise that takes a lot of time to read, but oh well, if
> that's what you guys really want...
>
> (In the days of LLMs, writing is almost free, but reading all that
> redundant or generated garbage text becomes impossible. I think it is
> harmful to have so much redundant text because time spent reading it
> is time wasted. But that's just my opinion.)
There is an important distinction between garbage and a reasonable patch
description.
--
Cheers
David / dhildenb
next prev parent reply other threads:[~2025-09-01 9:41 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-31 9:39 [PATCH v2 00/12] mm: add `const` to lots of pointer parameters Max Kellermann
2025-08-31 9:39 ` [PATCH v2 01/12] mm/shmem: " Max Kellermann
2025-09-01 7:33 ` Kiryl Shutsemau
2025-09-01 8:05 ` Max Kellermann
2025-09-01 8:20 ` David Hildenbrand
2025-09-01 8:26 ` Max Kellermann
2025-09-01 8:35 ` David Hildenbrand
2025-09-01 9:26 ` Max Kellermann
2025-09-01 9:32 ` Vlastimil Babka
2025-09-01 9:45 ` Max Kellermann
2025-09-01 9:49 ` David Hildenbrand
2025-09-01 9:41 ` David Hildenbrand [this message]
2025-09-01 9:48 ` Max Kellermann
2025-09-01 9:52 ` David Hildenbrand
2025-09-01 10:00 ` Max Kellermann
2025-09-01 10:07 ` David Hildenbrand
2025-09-01 10:36 ` Max Kellermann
2025-09-01 10:40 ` David Hildenbrand
2025-09-01 9:01 ` Mike Rapoport
2025-08-31 9:39 ` [PATCH v2 02/12] include/pagemap.h: " Max Kellermann
2025-08-31 9:39 ` [PATCH v2 03/12] include/mmzone.h: " Max Kellermann
2025-08-31 9:39 ` [PATCH v2 04/12] include/fs.h: add `const` to several " Max Kellermann
2025-08-31 9:39 ` [PATCH v2 05/12] mm/oom_kill: add `const` to pointer parameter Max Kellermann
2025-08-31 9:39 ` [PATCH v2 06/12] mm/util: add `const` to several pointer parameters Max Kellermann
2025-08-31 9:39 ` [PATCH v2 07/12] parisc/sys_parisc.c: add `const` to mmap_upper_limit() parameter Max Kellermann
2025-09-01 0:38 ` Matthew Wilcox
2025-09-01 6:06 ` Max Kellermann
2025-08-31 9:39 ` [PATCH v2 08/12] arch, mm/util: add const to arch_pick_mmap_layout() parameter Max Kellermann
2025-08-31 23:43 ` kernel test robot
2025-09-01 4:30 ` Max Kellermann
2025-08-31 9:39 ` [PATCH v2 09/12] include/mm_types.h: add `const` to several pointer parameters Max Kellermann
2025-08-31 9:39 ` [PATCH v2 10/12] include/mm_inline.h: add `const` to lots of " Max Kellermann
2025-08-31 9:39 ` [PATCH v2 11/12] include/mm.h: " Max Kellermann
2025-08-31 9:39 ` [PATCH v2 12/12] mm/highmem: " Max Kellermann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=661e6140-572b-4480-9ca2-6a127730f32b@redhat.com \
--to=david@redhat.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=hughd@google.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=max.kellermann@ionos.com \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--cc=vishal.moola@gmail.com \
--cc=willy@infradead.org \
--cc=yuanchu@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).