All of lore.kernel.org
 help / color / mirror / Atom feed
From: Praveen Kumar <kpraveen.lkml@gmail.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Cc: tim@xen.org, sstabellini@kernel.org, wei.liu2@citrix.com,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [PATCH v5 01/17] rbtree: changes to align the coding conventions with Linux tree
Date: Fri, 4 Aug 2017 22:29:28 +0530	[thread overview]
Message-ID: <CABcWhv43P-QvJBvqSE3cFFBYn+E_zX3oi1TbR7OMoJe4m2-4pw@mail.gmail.com> (raw)
In-Reply-To: <1501756670.28477.6.camel@citrix.com>

Hi Dario,

On Thu, Aug 3, 2017 at 4:07 PM, Dario Faggioli
<dario.faggioli@citrix.com> wrote:
> On Fri, 2017-07-14 at 07:05 -0600, Jan Beulich wrote:
>> > > > On 14.07.17 at 14:51, <kpraveen.lkml@gmail.com> wrote:
>> >
>> > Agreed, I shouldn't have added.
>> > rbtree.h file does include incline functions which are actually
>> > commented, and in order to have complete similarity I did include
>> > the
>> > same here.
>> >
>> > Also, rbtree.c does have comment in header note being modified, for
>> > the
>> > same reason.
>> >
>> > Further, do you suggest to keep the old ones, but that may cause
>> > porting issue and it won't be exact replica from Linux base. Please
>> > suggest.
>>
>> I'm fine with comment updates, _as long as you say so_ in the
>> commit message. If you say "only style changes", then there
>> ought to be no additions whatsoever.
>>
> I fully agree with Jan.
>
> And, as him, I also think you can update the header comments at the
> beginning of both rbtree.c and rbtree.h files, as soon as you mention
> that in the changelog.
>

Sure, will try to update with each patch individually in the header
comments ( if there are any version change ).

> *HOWEVER*, about this change, in both .c and .h:
>
> @@ -14,7 +14,8 @@
>    GNU General Public License for more details.
>
>    You should have received a copy of the GNU General Public License
> -  along with this program; If not, see <http://www.gnu.org/licenses/>.
> +  along with this program; if not, write to the Free Software
> +  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
>
>    linux/lib/rbtree.c
>  */
>
> This comes from 443701ef "Replace FSF street address with canonical
> URL" (check with `git blame xen/common/rbtree.c'), and I think we
> should leave this alone (i.e., keep the url, and not change back to the
> physical address).
>
> I understand it then will be a difference between our rbtree.{c,h} and
> Linux's ones, but I think it's one difference it's worth living with
> (and, honestly, I really don't expect this specific thing to cause much
> issues in future 'backports' from Linux).
>
> If others agree on this too, that would mean you basically would let
> the header comment of rbtree.c alone, while in rbtree.h, you "just" add
> the commented API usage example functions.
>

There will be issue while directly applying the patch from Linux tree
( having changed the file name ) as the line number changes. Because
of which I included the commented code. Further to this, for some of
the patches shared, I was also facing porting issue with and has been
manually ported. So, I am thinking if maintaining complete accuracy /
replica with Linux tree will give any benefit ?

> Regards,
> Dario
> --
> <<This happens because I choose it to happen!>> (Raistlin Majere)
> -----------------------------------------------------------------
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  reply	other threads:[~2017-08-04 16:59 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-14  8:26 [PATCH v5 00/17] xen: common: rbtree: ported updates from Linux tree Praveen Kumar
2017-07-14  8:26 ` [PATCH v5 01/17] rbtree: changes to align the coding conventions with " Praveen Kumar
2017-07-14 12:28   ` Jan Beulich
2017-07-14 12:51     ` Praveen Kumar
2017-07-14 13:05       ` Jan Beulich
2017-08-03 10:37         ` Dario Faggioli
2017-08-04 16:59           ` Praveen Kumar [this message]
2017-08-04 17:04             ` Jan Beulich
2017-08-04 17:21               ` Praveen Kumar
2017-08-06  7:42                 ` Jan Beulich
2017-07-14  8:26 ` [PATCH v5 02/17] rbtree: remove redundant if()-condition in rb_erase() Praveen Kumar
2017-08-03 10:11   ` Jan Beulich
2017-07-14  8:26 ` [PATCH v5 03/17] rbtree: empty nodes have no color Praveen Kumar
2017-07-14  8:26 ` [PATCH v5 04/17] rbtree: move some implementation details from rbtree.h to rbtree.c Praveen Kumar
2017-07-14  8:26 ` [PATCH v5 05/17] rbtree: break out of rb_insert_color loop after tree rotation Praveen Kumar
2017-07-14  8:26 ` [PATCH v5 06/17] rbtree: adjust root color in rb_insert_color() only when necessary Praveen Kumar
2017-07-14  8:26 ` [PATCH v5 07/17] rbtree: low level optimizations in rb_insert_color() Praveen Kumar
2017-07-14  8:26 ` [PATCH v5 08/17] rbtree: adjust node color in __rb_erase_color() only when necessary Praveen Kumar
2017-07-14  8:26 ` [PATCH v5 09/17] rbtree: optimize case selection logic in __rb_erase_color() Praveen Kumar
2017-07-14  8:26 ` [PATCH v5 10/17] rbtree: low level optimizations " Praveen Kumar
2017-07-14  8:26 ` [PATCH v5 11/17] rbtree: coding style adjustments Praveen Kumar
2017-07-14  8:26 ` [PATCH v5 12/17] rbtree: optimize fetching of sibling node Praveen Kumar
2017-07-14  8:26 ` [PATCH v5 13/17] rbtree: add __rb_change_child() helper function Praveen Kumar
2017-07-14  8:26 ` [PATCH v5 14/17] rbtree: place easiest case first in rb_erase() Praveen Kumar
2017-07-14  8:26 ` [PATCH v5 15/17] rbtree: handle 1-child recoloring in rb_erase() instead of rb_erase_color() Praveen Kumar
2017-07-14  8:26 ` [PATCH v5 16/17] rbtree: low level optimizations in rb_erase() Praveen Kumar
2017-07-14  8:26 ` [PATCH v5 17/17] rbtree: fix typo in comment of rb_insert_color Praveen Kumar

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=CABcWhv43P-QvJBvqSE3cFFBYn+E_zX3oi1TbR7OMoJe4m2-4pw@mail.gmail.com \
    --to=kpraveen.lkml@gmail.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=dario.faggioli@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=tim@xen.org \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.