linux-kernel - Re: FUSE workflow=? (Re: [RESEND1, PATCH 1/2] fuse: convert printk -> pr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 24 Apr 2019 10:57:35 +0200
From:   Miklos Szeredi <mszeredi@...hat.com>
To:     Kirill Smelkov <kirr@...edi.com>
Cc:     Miklos Szeredi <miklos@...redi.hu>,
        Brian Foster <bfoster@...hat.com>,
        Maxim Patlasov <mpatlasov@...allels.com>,
        Anatol Pomozov <anatol.pomozov@...il.com>,
        Pavel Emelyanov <xemul@...nvz.org>,
        Andrew Gallagher <andrewjcg@...com>,
        "Anand V . Avati" <avati@...hat.com>,
        Alexey Kuznetsov <kuznet@...tuozzo.com>,
        Andrey Ryabinin <aryabinin@...tuozzo.com>,
        Kirill Tkhai <ktkhai@...tuozzo.com>,
        Constantine Shulyupin <const@...elinux.com>,
        Chad Austin <chadaustin@...com>,
        Dan Schatzberg <dschatzberg@...com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        fuse-devel <fuse-devel@...ts.sourceforge.net>,
        lkml <linux-kernel@...r.kernel.org>,
        Han-Wen Nienhuys <hanwen@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: FUSE workflow=? (Re: [RESEND1, PATCH 1/2] fuse: convert printk -> pr_*)

On Wed, Apr 24, 2019 at 10:38 AM Kirill Smelkov <kirr@...edi.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@...edi.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@...redi.hu>
>         L:      linux-fsdevel@...r.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