From: David Sterba <dsterba@suse.cz>
To: Nikolay Borisov <n.borisov.lkml@gmail.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [RFC PATCH 00/12] Refactor btrfs_inode VS inode in delayed-inode.c
Date: Wed, 11 Jan 2017 17:51:00 +0100 [thread overview]
Message-ID: <20170111165100.GL12081@twin.jikos.cz> (raw)
In-Reply-To: <1484073342-28854-1-git-send-email-n.borisov.lkml@gmail.com>
On Tue, Jan 10, 2017 at 08:35:30PM +0200, Nikolay Borisov wrote:
> After following the discussion in [1] I took a look at what's the
> state of VFS-related members being used in core BTRFS code. It turned
> out there are quite a few functions which operate on struct btrfs_inode,
> yet take struct inode. As a result they have to resort ot excessive
> usage of BTRFS_I, furthermore passing inode around doesn't help the
> poor reader inferring why inode might be passed to a particular function.
>
> In order to better separate core btrfs functionalities from those part,
> which interface with the VFS I took a look around the code and this is
> the result. I'd like to solicit opinions whether people think this
> refactoring is useful, since I have gathered a list of a lot more
> functions which might use a bit of inode VS btrfs_inode changes. Also,
> a lot of function take inode just because btrfs_ino was taking an inode.
Agreed, this is a good direction how to clean up the code.
> The patches are self-explanatory, with the first one dealing with
> btrfs_ino being the bulk of it. This paves the way to restructuring
> a lot of functions.
>
> If the maintainers think this should be merged I'd rather resend it
> as a single patch so as not to pollute the git history. This
> version can be used for fine-grained discussion and feedback.
Actually I like the way it's separated as it keeps the review easy, it
keeps the context in one function and does one change.
It would be interesting the see the result as reported by the 'size'
utility before and after the patchset, the effects of removed BTRFS_I
calls.
I'll do a testing merge on top of current for-next to see how intrusive
it is. If it turns out to be ok, I'll add the patches to the cleanups
branch.
next prev parent reply other threads:[~2017-01-11 16:51 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-10 18:35 [RFC PATCH 00/12] Refactor btrfs_inode VS inode in delayed-inode.c Nikolay Borisov
2017-01-10 18:35 ` [PATCH 01/12] btrfs: Make btrfs_ino take a struct btrfs_inode Nikolay Borisov
2017-01-10 18:35 ` [PATCH 02/12] btrfs: Make btrfs_get_delayed_node take btrfs_inode Nikolay Borisov
2017-01-10 18:35 ` [PATCH 03/12] btrfs: Make btrfs_get_or_create_delayed_node " Nikolay Borisov
2017-01-10 18:35 ` [PATCH 04/12] btrfs: Make btrfs_delayed_inode_reserve_metadata " Nikolay Borisov
2017-01-10 18:35 ` [PATCH 05/12] btrfs: Make btrfs_insert_delayed_dir_index " Nikolay Borisov
2017-01-10 18:35 ` [PATCH 06/12] btrfs: Make btrfs_delete_delayed_dir_index " Nikolay Borisov
2017-01-10 18:35 ` [PATCH 07/12] btrfs: Make btrfs_delayed_delete_inode_ref " Nikolay Borisov
2017-01-10 18:35 ` [PATCH 08/12] btrfs: Make btrfs_kill_delayed_inode_items " Nikolay Borisov
2017-01-10 18:35 ` [PATCH 09/12] btrfs: Make btrfs_remove_delayed_node " Nikolay Borisov
2017-01-10 18:35 ` [PATCH 10/12] btrfs: Make btrfs_commit_inode_delayed_inode " Nikolay Borisov
2017-01-10 18:35 ` [PATCH 11/12] btrfs: Make btrfs_commit_inode_delayed_items " Nikolay Borisov
2017-01-10 18:35 ` [PATCH 12/12] btrfs: Make btrfs_inode_delayed_dir_index_count " Nikolay Borisov
2017-01-11 16:51 ` David Sterba [this message]
2017-01-11 18:11 ` [RFC PATCH 00/12] Refactor btrfs_inode VS inode in delayed-inode.c Nikolay Borisov
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=20170111165100.GL12081@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=n.borisov.lkml@gmail.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).