From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Christian Schoenebeck <qemu_oss@crudebyte.com>
Cc: qemu-devel@nongnu.org,
Antonios Motakis <antonios.motakis@huawei.com>,
Greg Kurz <groug@kaod.org>
Subject: Re: [Qemu-devel] [PATCH v3 1/5] 9p: mitigates most QID path collisions
Date: Tue, 7 May 2019 14:13:52 +0100 [thread overview]
Message-ID: <20190507131352.GR27205@redhat.com> (raw)
In-Reply-To: <3809087.3a1rNnKprp@silver>
On Tue, May 07, 2019 at 03:11:26PM +0200, Christian Schoenebeck wrote:
> On Dienstag, 7. Mai 2019 13:42:47 CEST Daniel P. Berrangé wrote:
> > > This first patch here is an updated version of Antonios Motakis'
> > > original 4-patch set (using fixed length 16 bit prefixes), merged to one
> > > patch:
> > >
> > > https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg02283.html
> > >
> > > * Updated to latest git master, specifically to new qht interface.
> > >
> > > * Merged the original 4 patches to this single patch.
> >
> > Why did you merge them all into one ? The split patches were "best
> > practice" IMHO. The original patch authorship & S-o-B lines could
> > be preserved if you kept them split as before too.
>
> Seems I misinterpreted an old comment of Greg that he would like to see them
> to be merged into less patches. I think it was this one:
>
> https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg02590.html
>
> No problem, I will restore Antonios' original individual 4 patches
> appropriately. What about SOB then? Should I just place Antonio's SOB on those
> 4 patches or does it need his and mine SOB lines? (I mean I need to rebase
> those 4 patches and address the old issues on them)
If the patch is unchanged from Antonio's original then it only needs to
have Antonio's SOB. If you have modified the patch yourself, then you
would add your own SOB, in addition to Antonio's original SOB.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2019-05-07 13:14 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-06 14:37 [Qemu-devel] [PATCH v3 0/5] 9p: Fix file ID collisions Christian Schoenebeck via Qemu-devel
2019-04-23 11:30 ` [Qemu-devel] [PATCH v3 1/5] 9p: mitigates most QID path collisions Christian Schoenebeck via Qemu-devel
2019-05-07 12:42 ` Daniel P. Berrangé
2019-05-07 13:11 ` Christian Schoenebeck via Qemu-devel
2019-05-07 13:13 ` Daniel P. Berrangé [this message]
2019-04-23 11:35 ` [Qemu-devel] [PATCH v3 2/5] 9P: trivial cleanup of QID path collision mitigation Christian Schoenebeck via Qemu-devel
2019-05-07 12:43 ` Daniel P. Berrangé
2019-04-23 11:41 ` [Qemu-devel] [PATCH v3 3/5] 9p: persistency of QID path beyond reboots / suspensions Christian Schoenebeck via Qemu-devel
2019-05-03 14:51 ` [Qemu-devel] [PATCH v3 4/5] 9p: use variable length suffixes for inode mapping Christian Schoenebeck via Qemu-devel
2019-05-05 21:41 ` [Qemu-devel] [PATCH v3 5/5] 9p: adds virtfs 'vii' device parameter Christian Schoenebeck via Qemu-devel
2019-05-06 17:58 ` [Qemu-devel] [libvirt patch] qemu: adds support for virtfs 9p argument 'vii' Christian Schoenebeck via Qemu-devel
2019-05-07 9:55 ` Greg Kurz
2019-05-07 12:23 ` Christian Schoenebeck via Qemu-devel
2019-05-07 15:42 ` Greg Kurz
2019-05-07 16:16 ` Christian Schoenebeck via Qemu-devel
2019-05-17 8:40 ` Christian Schoenebeck via Qemu-devel
2019-05-17 12:30 ` Greg Kurz
2019-05-17 13:23 ` Christian Schoenebeck via Qemu-devel
2019-05-17 14:47 ` Greg Kurz
2019-05-17 20:53 ` Christian Schoenebeck via Qemu-devel
2019-05-20 14:05 ` Greg Kurz
2019-05-22 16:03 ` Christian Schoenebeck via Qemu-devel
2019-06-03 6:57 ` Greg Kurz
2019-06-03 9:17 ` Christian Schoenebeck via Qemu-devel
2019-05-07 12:57 ` Daniel P. Berrangé
2019-05-07 13:48 ` Christian Schoenebeck via Qemu-devel
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=20190507131352.GR27205@redhat.com \
--to=berrange@redhat.com \
--cc=antonios.motakis@huawei.com \
--cc=groug@kaod.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu_oss@crudebyte.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).