[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130111142703.GJ20089@twin.jikos.cz>
Date: Fri, 11 Jan 2013 15:27:03 +0100
From: David Sterba <dsterba@...e.cz>
To: Zhi Yong Wu <zwu.kernel@...il.com>
Cc: dsterba@...e.cz, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, viro@...iv.linux.org.uk,
david@...morbit.com, darrick.wong@...cle.com, andi@...stfloor.org,
hch@...radead.org, linuxram@...ux.vnet.ibm.com,
wuzhy@...ux.vnet.ibm.com
Subject: Re: [PATCH RESEND v1 03/16] vfs: add I/O frequency update function
On Fri, Jan 11, 2013 at 03:38:31PM +0800, Zhi Yong Wu wrote:
> On Thu, Jan 10, 2013 at 8:51 AM, David Sterba <dsterba@...e.cz> wrote:
> > On Thu, Dec 20, 2012 at 10:43:22PM +0800, zwu.kernel@...il.com wrote:
> >> --- a/fs/hot_tracking.c
> >> +++ b/fs/hot_tracking.c
> >> @@ -164,6 +164,135 @@ static void hot_inode_tree_exit(struct hot_info *root)
> >> spin_unlock(&root->lock);
> >> }
> >>
> >> +struct hot_inode_item
> >> +*hot_inode_item_lookup(struct hot_info *root, u64 ino)
> >> +{
> >> + struct rb_node **p = &root->hot_inode_tree.map.rb_node;
> >> + struct rb_node *parent = NULL;
> >> + struct hot_comm_item *ci;
> >> + struct hot_inode_item *entry;
> >> +
> >> + /* walk tree to find insertion point */
> >> + spin_lock(&root->lock);
> >> + while (*p) {
> >> + parent = *p;
> >> + ci = rb_entry(parent, struct hot_comm_item, rb_node);
> >> + entry = container_of(ci, struct hot_inode_item, hot_inode);
> >> + if (ino < entry->i_ino)
> >> + p = &(*p)->rb_left;
> >> + else if (ino > entry->i_ino)
> >> + p = &(*p)->rb_right;
> >
> > style comment: put { } around the all if/else blocks,
> no, it will violate checkpatch.pl. If the if/else block only contains
> one line of code, we should not put {} around them.
Unless its in a if / else if / else sequence, see
Documentation/CodingStyle chapter 3.1. This is what I've learned long
time ago and using it intuitively. I don't know to what extent
checkpatch sticks to that document, the code is menat to be read by
people, so if there is one style prevailing in the subsystem (and it is
by looking into random fs/*.c files) it's wise to keep the style
consistent.
david
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists