[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAH2r5muYzimR+i2EBFwvJQ4MWWpzVdbaocg+8FdSniSZF7rXQw@mail.gmail.com>
Date: Thu, 9 Oct 2025 09:10:11 -0500
From: Steve French <smfrench@...il.com>
To: Markus Elfring <Markus.Elfring@....de>
Cc: linux-cifs@...r.kernel.org, Bharath SM <bharathsm@...rosoft.com>,
Paulo Alcantara <pc@...guebit.org>, Ronnie Sahlberg <ronniesahlberg@...il.com>,
Shyam Prasad N <sprasad@...rosoft.com>, Tom Talpey <tom@...pey.com>, Steve French <sfrench@...ba.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: smb: client: Simplify a return statement in get_smb2_acl_by_path()
On Thu, Oct 9, 2025 at 9:00 AM Markus Elfring <Markus.Elfring@....de> wrote:
>
> > Three of the four you just sent today, grow the code slightly,
>
> How much will this observation matter?
Remember the goals here, the priorities:
1) Fixes for bugs
2) Performance improvements
3) Features that add support for missing Linux requirements (e.g.
adding O_TMPFILE or "rename_exchange support)
and then lower priority but still somewhat useful:
4) cleanup patches that remove unneeded code (although has to be
balanced against how it can hurt backports of important fixes),
ie cleanup that makes code *smaller* and therefore slightly easier to
read and maintain
5) cleanup code that adds or updates comments clarifying confusing code
Obviously "cleanup" patches that don't shrink code are often useless
(as they potentially break backports of patches for no value).
--
Thanks,
Steve
Powered by blists - more mailing lists