Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <CAJfpegt9DRmwKksR0QSA7NzQP_=a=yJybdL9mOP1cw5goGkdgw@mail.gmail.com>
 <20190424083800.GA11722@deco.navytux.spb.ru>
In-Reply-To: <20190424083800.GA11722@deco.navytux.spb.ru>
From:   Miklos Szeredi <mszeredi@redhat.com>
Date:   Wed, 24 Apr 2019 10:57:35 +0200
Message-ID: <CAOssrKeowGky6cccH0EKXiJkTwnPAU+as_vish=u4kvU=TQsvg@mail.gmail.com>
Subject: Re: FUSE workflow=? (Re: [RESEND1, PATCH 1/2] fuse: convert printk -> pr_*)
To:     Kirill Smelkov <kirr@nexedi.com>
Cc:     Miklos Szeredi <miklos@szeredi.hu>,
        Brian Foster <bfoster@redhat.com>,
        Maxim Patlasov <mpatlasov@parallels.com>,
        Anatol Pomozov <anatol.pomozov@gmail.com>,
        Pavel Emelyanov <xemul@openvz.org>,
        Andrew Gallagher <andrewjcg@fb.com>,
        "Anand V . Avati" <avati@redhat.com>,
        Alexey Kuznetsov <kuznet@virtuozzo.com>,
        Andrey Ryabinin <aryabinin@virtuozzo.com>,
        Kirill Tkhai <ktkhai@virtuozzo.com>,
        Constantine Shulyupin <const@makelinux.com>,
        Chad Austin <chadaustin@fb.com>,
        Dan Schatzberg <dschatzberg@fb.com>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        fuse-devel <fuse-devel@lists.sourceforge.net>,
        lkml <linux-kernel@vger.kernel.org>,
        Han-Wen Nienhuys <hanwen@google.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Apr 24, 2019 at 10:38 AM Kirill Smelkov <kirr@nexedi.com> wrote:
>
> +torvalds
>
> On Tue, Apr 23, 2019 at 04:57:58PM +0200, Miklos Szeredi wrote:
> > On Wed, Mar 27, 2019 at 10:15 AM Kirill Smelkov <kirr@nexedi.com> wrote:
> > >
> > > Functions, like pr_err, are a more modern variant of printing compared to
> > > printk. They could be used to denoise sources by using needed level in
> > > the print function name, and by automatically inserting per-driver /
> > > function / ... print prefix as defined by pr_fmt macro. pr_* are also
> > > said to be used in Documentation/process/coding-style.rst and more
> > > recent code - for example overlayfs - uses them instead of printk.
> > >
> > > Convert CUSE and FUSE to use the new pr_* functions.
> > >
> > > CUSE output stays completely unchanged, while FUSE output is amended a
> > > bit for "trying to steal weird page" warning - the second line now comes
> > > also with "fuse:" prefix. I hope it is ok.
> >
> > Yep.  Applied, thanks.
>
> Miklos, thanks for feedback. Could you please clarify where the patch is
> applied? Here is what linux/MAINTAINERS says
>
>         FUSE: FILESYSTEM IN USERSPACE
>         M:      Miklos Szeredi <miklos@szeredi.hu>
>         L:      linux-fsdevel@vger.kernel.org
>         W:      http://fuse.sourceforge.net/
>         T:      git git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git
>         S:      Maintained
>         F:      fs/fuse/
>         F:      include/uapi/linux/fuse.h
>         F:      Documentation/filesystems/fuse.txt
>
> but git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git was
> not updated for ~ 2 months. I see other "Applied, thanks" replies from
> you on linux-fsdevel in recent days and it suggests that patches are
> indeed applied, but where they are integrated is the question.

My private patch queue.

> Linux-next also has no post-5.1 fuse patches at all, so I'm really
> puzzled about what is going on.
>
> Is there any reason not to keep for-next fuse branch publicly available?
> Or am I missing something?

I usually push to fuse.git#for-next within a day or two of adding it
to my queue.

> Could you please also have a look at other posted patches? I'm
> struggling for months sending them to you and not getting feedback. It
> is kind of frustrating to work in this mode.

I see.  I'll try to give more frequent feedback on patches.  The
reason for not replying is not that I intentionally ignore incoming
patches, but because I'm working on something else and context
switching between completely different projects is not easy for me.

Thanks,
Miklos