[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPhsuW6ZSbKLYPpUk3DT+HxTfcuOVPG64rQ057aoLGgrGSeGHA@mail.gmail.com>
Date: Wed, 16 Oct 2019 10:00:13 -0700
From: Song Liu <liu.song.a23@...il.com>
To: Jens Axboe <axboe@...nel.dk>, Jeff Layton <jlayton@...nel.org>,
"J. Bruce Fields" <bfields@...ldses.org>
Cc: Eugene Syromiatnikov <esyr@...hat.com>,
open list <linux-kernel@...r.kernel.org>,
Alexander Viro <viro@...iv.linux.org.uk>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Ingo Molnar <mingo@...nel.org>,
linux-raid <linux-raid@...r.kernel.org>,
Linux-Fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH v3 0/3] Fix typo in RWH_WRITE_LIFE_NOT_SET constant name
Hi Jeff and J. Bruce,
On Wed, Oct 2, 2019 at 9:55 AM Song Liu <liu.song.a23@...il.com> wrote:
>
> On Tue, Oct 1, 2019 at 5:55 PM Jens Axboe <axboe@...nel.dk> wrote:
> >
> > On 10/1/19 5:12 PM, Song Liu wrote:
> > > On Fri, Sep 20, 2019 at 8:58 AM Eugene Syromiatnikov <esyr@...hat.com> wrote:
> > >>
> > >> Hello.
> > >>
> > >> This is a small fix of a typo (or, more specifically, some remnant of
> > >> the old patch version spelling) in RWH_WRITE_LIFE_NOT_SET constant,
> > >> which is named as RWF_WRITE_LIFE_NOT_SET currently. Since the name
> > >> with "H" is used in man page and everywhere else, it's probably worth
> > >> to make the name used in the fcntl.h UAPI header in line with it.
> > >> The two follow-up patches update usage sites of this constant in kernel
> > >> to use the new spelling.
> > >>
> > >> The old name is retained as it is part of UAPI now.
> > >>
> > >> Changes since v2[1]:
> > >> * Updated RWF_WRITE_LIFE_NOT_SET constant usage
> > >> in drivers/md/raid5-ppl.c:ppl_init_log().
> > >>
> > >> Changes since v1[2]:
> > >> * Changed format of the commit ID in the commit message of the first patch.
> > >> * Removed bogus Signed-off-by that snuck into the resend of the series.
> > >
> > > Applied to md-next.
> >
> > I think the core fs change should core in through a core tree, then
> > the md bits can go in at will after that.
As Jens suggested, we should route core fs patches through core tree. Could
you please apply these patches? Since the change is small, probably you can
also apply md patches?
Thanks,
Song
PS: for the series:
Acked-by: Song Liu <songliubraving@...com>
Powered by blists - more mailing lists