From: Greg Kurz <groug@kaod.org>
To: Christian Schoenebeck <qemu_oss@crudebyte.com>
Cc: stefanha@gmail.com, berrange@redhat.com, qemu-devel@nongnu.org,
antonios.motakis@huawei.com, dgilbert@redhat.com
Subject: Re: [Qemu-devel] [PATCH v6 0/4] 9p: Fix file ID collisions
Date: Mon, 2 Sep 2019 17:34:32 +0200 [thread overview]
Message-ID: <20190902173432.20f2637b@bahia.lan> (raw)
In-Reply-To: <21182000.2zn5IIMESL@silver>
On Sun, 01 Sep 2019 21:28:45 +0200
Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:
> On Donnerstag, 29. August 2019 19:02:34 CEST Greg Kurz wrote:
> > On Thu, 22 Aug 2019 15:18:54 -0700 (PDT)
> >
> > no-reply@patchew.org wrote:
> > > Patchew URL:
> > > https://patchew.org/QEMU/cover.1566503584.git.qemu_oss@crudebyte.com/
> > >
> > >
> > >
> > > Hi,
> > >
> > > This series seems to have some coding style problems. See output below for
> > > more information:
> [snip]
> > >
> > > === OUTPUT BEGIN ===
> > > 1/4 Checking commit bb69de63f788 (9p: Treat multiple devices on one export
> > > as an error) ERROR: Author email address is mangled by the mailing list
> > > #2:
> > > Author: Christian Schoenebeck via Qemu-devel <qemu-devel@nongnu.org>
> >
> > This is problematic since it ends up in the Author: field in git. Please
> > find a way to fix that.
>
> Like in which way do you imagine that? And where is the actual practical
> problem? I mean every patch still has my signed-off-by tag with the correct
> email address ending up in git history.
>
Yes, this only breaks Author: if the patch is applied from the list.
> The cause for this issue is that the domain is configured to require DKIM
> signatures for all outgoing emails. That's why mailman replaces my address by
> "Christian Schoenebeck via Qemu-devel <qemu-devel@nongnu.org>" placeholder
> since it could not provide a valid signature.
>
> There were good reasons for enabling DKIM and it is a good thing for all
> domains in general, since that ensures that (i.e. foreign) email addresses
> cannot be used as sender address if the actual sender is not authorized for
> sending emails with that address.
>
Don't know much about DKIM but google seems to confirm what you say. So,
this means that patchew will complain each time you post if we can't find
a proper way to address that... :-\
> What I changed in the meantime though is that you should get all my patches
> directly to your personal address, not only from the list. Or did you receive
> v6 again just from the list?
>
I've received the patches in my mailbox but I prefer to use the patchwork's
pwclient CLI to apply patches... and patchwork captures the patches from
the list, so I end up having to patch the authorship manually anyway.
How are you sending patches ? With git send-email ? If so, maybe you can pass
something like --from='"Christian Schoenebeck" <qemu_oss@crudebyte.com>'.
Since this is a different string, git will assume you're sending someone else's
patch : it will automatically add an extra From: made out of the commit Author
as recorded in the git tree.
> > Other warnings/errors should also be fixed but they look trivial.
>
> Yeah, they are trivial. *But* there is one thing ...
>
> > > Author: Christian Schoenebeck via Qemu-devel <qemu-devel@nongnu.org>
> > >
> > > ERROR: space prohibited after that open parenthesis '('
> > > #92: FILE: hw/9pfs/9p.c:586:
> > > + return ((uint64_t)mirror8bit( value & 0xff) << 56) |
> > >
> > > ERROR: space prohibited before that close parenthesis ')'
> > > #98: FILE: hw/9pfs/9p.c:592:
> > > + ((uint64_t)mirror8bit((value >> 48) & 0xff) << 8 ) |
> > >
> > > ERROR: space prohibited before that close parenthesis ')'
> > > #99: FILE: hw/9pfs/9p.c:593:
> > > + ((uint64_t)mirror8bit((value >> 56) & 0xff) ) ;
>
> ... I would like to ignore this specific bot whining, because that particular
> function looks much more readable the way it is (in that patch) right now.
Prettier certainly but...
/* Same as mirror8bit() just for a 64 bit data type instead for a byte. */
static inline uint64_t mirror64bit(uint64_t value)
{
return ((uint64_t)mirror8bit(value & 0xff) << 56) |
((uint64_t)mirror8bit((value >> 8) & 0xff) << 48) |
((uint64_t)mirror8bit((value >> 16) & 0xff) << 40) |
((uint64_t)mirror8bit((value >> 24) & 0xff) << 32) |
((uint64_t)mirror8bit((value >> 32) & 0xff) << 24) |
((uint64_t)mirror8bit((value >> 40) & 0xff) << 16) |
((uint64_t)mirror8bit((value >> 48) & 0xff) << 8) |
((uint64_t)mirror8bit((value >> 56) & 0xff));
}
... is readable enough IMHO and makes checkpatch happy :)
>
> > > WARNING: Block comments use a leading /* on a separate line
> > > #102: FILE: hw/9pfs/9p.c:596:
> > > +/** @brief Parameter k for the Exponential Golomb algorihm to be used.
> > >
> > > WARNING: Block comments use a leading /* on a separate line
> > > #121: FILE: hw/9pfs/9p.c:615:
> > > +/** @brief Exponential Golomb algorithm for arbitrary k (including k=0).
> > >
> > > WARNING: Block comments use a leading /* on a separate line
> > > #148: FILE: hw/9pfs/9p.c:642:
> > > +/** @brief Converts a suffix into a prefix, or a prefix into a suffix.
next prev parent reply other threads:[~2019-09-02 15:37 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-22 19:53 [Qemu-devel] [PATCH v6 0/4] 9p: Fix file ID collisions Christian Schoenebeck via Qemu-devel
2019-08-22 19:28 ` [Qemu-devel] [PATCH v6 1/4] 9p: Treat multiple devices on one export as an error Christian Schoenebeck via Qemu-devel
2019-08-29 16:27 ` Greg Kurz
2019-09-01 17:38 ` Christian Schoenebeck via Qemu-devel
2019-08-22 19:33 ` [Qemu-devel] [PATCH v6 2/4] 9p: Added virtfs option 'multidevs=remap|forbid|warn' Christian Schoenebeck via Qemu-devel
2019-08-29 16:55 ` Greg Kurz
2019-09-01 18:40 ` Christian Schoenebeck via Qemu-devel
2019-09-02 10:16 ` Greg Kurz
2019-09-02 21:07 ` Christian Schoenebeck via Qemu-devel
2019-08-30 12:22 ` Greg Kurz
2019-09-01 18:56 ` Christian Schoenebeck via Qemu-devel
2019-09-02 11:49 ` Greg Kurz
2019-09-02 21:25 ` Christian Schoenebeck via Qemu-devel
2019-08-22 19:44 ` [Qemu-devel] [PATCH v6 3/4] 9p: stat_to_qid: implement slow path Christian Schoenebeck via Qemu-devel
2019-08-22 19:49 ` [Qemu-devel] [PATCH v6 4/4] 9p: Use variable length suffixes for inode remapping Christian Schoenebeck via Qemu-devel
2019-08-22 22:18 ` [Qemu-devel] [PATCH v6 0/4] 9p: Fix file ID collisions no-reply
2019-08-29 17:02 ` Greg Kurz
2019-09-01 19:28 ` Christian Schoenebeck via Qemu-devel
2019-09-02 15:34 ` Greg Kurz [this message]
2019-09-02 22:29 ` Christian Schoenebeck via Qemu-devel
2019-09-03 19:11 ` [Qemu-devel] DMARC/DKIM and qemu-devel list settings Ian Kelling
2019-09-04 8:13 ` Daniel P. Berrangé
2019-09-04 14:19 ` Ian Kelling
2019-09-04 14:30 ` Peter Maydell
2019-09-09 11:47 ` Markus Armbruster
2019-09-10 7:23 ` Stefan Hajnoczi
2019-09-03 19:38 ` [Qemu-devel] [PATCH v6 0/4] 9p: Fix file ID collisions Eric Blake
2019-09-04 13:02 ` Christian Schoenebeck via Qemu-devel
2019-09-05 12:25 ` Christian Schoenebeck via Qemu-devel
2019-09-05 12:59 ` Greg Kurz
2019-09-23 11:27 ` Christian Schoenebeck via
2019-09-09 14:05 ` Eric Blake
2019-09-09 14:25 ` Jeff King
2019-09-23 11:19 ` Christian Schoenebeck via
2019-09-23 22:24 ` Jeff King
2019-09-24 9:03 ` git format.from (was: 9p: Fix file ID collisions) Christian Schoenebeck via
2019-09-24 21:36 ` Jeff King
2019-09-09 18:41 ` [Qemu-devel] [PATCH v6 0/4] 9p: Fix file ID collisions Junio C Hamano
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=20190902173432.20f2637b@bahia.lan \
--to=groug@kaod.org \
--cc=antonios.motakis@huawei.com \
--cc=berrange@redhat.com \
--cc=dgilbert@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu_oss@crudebyte.com \
--cc=stefanha@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;
as well as URLs for NNTP newsgroup(s).