From: "Valdis Klētnieks" <valdis.kletnieks@vt.edu>
To: Matthew Wilcox <willy@infradead.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-fsdevel@vger.kernel.org, devel@driverdev.osuosl.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 01/15] staging: exfat: Clean up return codes - FFS_FULL
Date: Thu, 24 Oct 2019 14:39:13 -0400 [thread overview]
Message-ID: <1151252.1571942353@turing-police> (raw)
In-Reply-To: <20191024175904.GJ2963@bombadil.infradead.org>
[-- Attachment #1: Type: text/plain, Size: 895 bytes --]
On Thu, 24 Oct 2019 10:59:04 -0700, Matthew Wilcox said:
> Wouldn't it be better to do this as:
> Patch 1: Change all these defines to -Exxx and remove the stupid errno-changing
> blocks like this:
Well, except for the fact that the one for FFS_MEDIAERR required splitting the
uses into -ENODEV, -EIO, and -ENOENT.
Also, "and remover the stupid blocks" would be a second change, and I *thought*
the rule was "one thing, one patch".
> That way nobody actually needs to review patches 2-n; all of the changes
> are done in patch 1.
Reviewing a patch where you know that exactly one thing is supposed to happen
means scrolling through 14 occurrences of the pattern
if (num_alloced == 0)
- ret = FFS_FULL;
+ ret = -ENOSPC;
goes *really* fast, and those comprise most of the bulk of the patchset.
And as I already mentioned, the "stupid looking blocks" will be removed in
a future patch.
[-- Attachment #2: Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2019-10-24 18:39 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-24 15:53 [PATCH 00/15] staging: exfat: Clean up return codes Valdis Kletnieks
2019-10-24 15:53 ` [PATCH 01/15] staging: exfat: Clean up return codes - FFS_FULL Valdis Kletnieks
2019-10-24 17:59 ` Matthew Wilcox
2019-10-24 18:39 ` Valdis Klētnieks [this message]
2019-10-24 15:53 ` [PATCH 02/15] staging: exfat: Clean up return codes - FFS_NOTFOUND Valdis Kletnieks
2019-10-24 15:53 ` [PATCH 03/15] staging: exfat: Clean up return codes - FFS_DIRBUSY Valdis Kletnieks
2019-10-24 15:53 ` [PATCH 04/15] staging: exfat: Clean up return codes - FFS_PERMISSIONERR Valdis Kletnieks
2019-10-24 16:23 ` Joe Perches
2019-10-24 16:27 ` Valdis Klētnieks
2019-10-25 10:14 ` Dan Carpenter
2019-10-24 15:53 ` [PATCH 05/15] staging: exfat: Clean up return codes - FFS_NAMETOOLONG Valdis Kletnieks
2019-10-24 15:53 ` [PATCH 06/15] staging: exfat: Clean up return codes - FFS_FILEEXIST Valdis Kletnieks
2019-10-24 15:53 ` [PATCH 07/15] staging: exfat: Clean up return codes - FFS_INVALIDPATH Valdis Kletnieks
2019-10-24 15:53 ` [PATCH 08/15] staging: exfat: Clean up return code - FFS_MEMORYERR Valdis Kletnieks
2019-10-24 15:53 ` [PATCH 09/15] staging: exfat: Clean up return codes - FFS_FORMATERR Valdis Kletnieks
2019-10-25 2:56 ` Greg Kroah-Hartman
2019-10-24 15:53 ` [PATCH 10/15] staging: exfat: Clean up return codes - FFS_MEDIAERR Valdis Kletnieks
2019-10-24 15:53 ` [PATCH 11/15] staging: exfat: Clean up return codes - FFS_EOF Valdis Kletnieks
2019-10-24 15:53 ` [PATCH 12/15] staging: exfat: Clean up return codes - FFS_INVALIDFID Valdis Kletnieks
2019-10-24 15:53 ` [PATCH 13/15] staging: exfat: Clean up return codes - FFS_ERROR Valdis Kletnieks
2019-10-24 15:53 ` [PATCH 14/15] staging: exfat: Clean up return codes - remove unused codes Valdis Kletnieks
2019-10-24 15:53 ` [PATCH 15/15] staging: exfat: Clean up return codes - FFS_SUCCESS Valdis Kletnieks
2019-10-24 16:29 ` Joe Perches
2019-10-24 16:46 ` Valdis Klētnieks
2019-10-24 16:23 ` [PATCH 00/15] staging: exfat: Clean up return codes Joe Perches
2019-10-24 16:45 ` Valdis Klētnieks
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=1151252.1571942353@turing-police \
--to=valdis.kletnieks@vt.edu \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=willy@infradead.org \
/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).