From: Greg KH <gregkh@linuxfoundation.org>
To: Monam Agarwal <monamagarwal123@gmail.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>,
devel@driverdev.osuosl.org, andreas.dilger@intel.com,
peter.p.waskiewicz.jr@intel.com, linux-kernel@vger.kernel.org,
Rashika Kheria <rashika.kheria@gmail.com>
Subject: Re: [PATCH v3 1/2] Staging: lustre: Refactor the function interval_erase_color() in /lustre/ldlm/interval_tree.c
Date: Sat, 11 Jan 2014 12:33:58 -0800 [thread overview]
Message-ID: <20140111203358.GA6501@kroah.com> (raw)
In-Reply-To: <CAFB2WuUaf9x42U0xTyczpw1=9kLaLLPC9v0f5JxpS7j+umt9kw@mail.gmail.com>
On Sat, Jan 11, 2014 at 05:14:35PM +0530, Monam Agarwal wrote:
> On Sat, Jan 11, 2014 at 5:09 PM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> > On Sat, Jan 11, 2014 at 04:56:44PM +0530, Monam Agarwal wrote:
> >> I took n as a flag to decide whether parent->in_left == node is true
> >> or not in the called function.
> >
> > So "n" stands for "node"?
> >
> >> Should I use some other name for the flag.
> >
> >
> > Yes.
> >
>
> Will "flag" be a suitable name?
Ick, no. You don't want a "flag" to have to determine what the logic is
for a given function. That just causes confusion and makes things
really hard to read and understand over time.
This whole function looks like a red/black tree, or something like that.
Shouldn't we just be using the in-kernel implementation of this? And if
not, then you really need to get the feedback of the code's original
authors as you might be changing the algorithm in ways that could cause
big problems.
thanks,
greg k-h
next prev parent reply other threads:[~2014-01-11 20:33 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-05 20:11 [PATCH 1/2] Staging: lustre: Fix line length exceeding 80 characters MonamAgarwal
2014-01-05 20:30 ` Joe Perches
2014-01-08 23:55 ` Greg KH
2014-01-11 11:00 ` [PATCH v3 1/2] Staging: lustre: Refactor the function interval_erase_color() in /lustre/ldlm/interval_tree.c Monam Agarwal
2014-01-11 11:19 ` Dan Carpenter
2014-01-11 11:26 ` Monam Agarwal
2014-01-11 11:39 ` Dan Carpenter
2014-01-11 11:44 ` Monam Agarwal
2014-01-11 20:33 ` Greg KH [this message]
[not found] ` <0E07CEA6-D544-4809-A0DC-48DCB808669D@intel.com>
2014-01-14 8:01 ` Xiong, Jinshan
2014-01-14 11:09 ` Monam Agarwal
2014-01-14 17:41 ` Xiong, Jinshan
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=20140111203358.GA6501@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=andreas.dilger@intel.com \
--cc=dan.carpenter@oracle.com \
--cc=devel@driverdev.osuosl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=monamagarwal123@gmail.com \
--cc=peter.p.waskiewicz.jr@intel.com \
--cc=rashika.kheria@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