[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/5] io: Add support for MSG_PEEK for socket channel
From: |
Daniel P . Berrangé |
Subject: |
Re: [PATCH 1/5] io: Add support for MSG_PEEK for socket channel |
Date: |
Thu, 15 Dec 2022 09:40:41 +0000 |
User-agent: |
Mutt/2.2.7 (2022-08-07) |
On Wed, Dec 14, 2022 at 04:30:48PM -0500, Peter Xu wrote:
> On Wed, Dec 14, 2022 at 09:14:09AM +0000, Daniel P. Berrangé wrote:
> > On Tue, Dec 13, 2022 at 04:38:46PM -0500, Peter Xu wrote:
> > > From: "manish.mishra" <manish.mishra@nutanix.com>
> > >
> > > MSG_PEEK reads from the peek of channel, The data is treated as
> > > unread and the next read shall still return this data. This
> > > support is currently added only for socket class. Extra parameter
> > > 'flags' is added to io_readv calls to pass extra read flags like
> > > MSG_PEEK.
> > >
> > > Reviewed-by: Daniel P. Berrang?? <berrange@redhat.co
> > > Suggested-by: Daniel P. Berrang?? <berrange@redhat.com
> >
> > The last letter of my name has been mangled - whatever tools used
> > to pull in manish's patches seem to not be UTF-8 clean.
> >
> > Also the email addr isn't terminated, but that was pre-existing
> > in manish's previous posting.
>
> I'll fix at least the latter in my next post, sorry.
>
> For the 1st one - I am still looking at what went wrong.
>
> Here from the web interfaces it all looks good (besides the wrong
> ending..), e.g. on lore or patchew:
>
> 20221213213850.1481858-2-peterx@redhat.com/">https://lore.kernel.org/all/20221213213850.1481858-2-peterx@redhat.com/
> 20221213213850.1481858-1-peterx@redhat.com/20221213213850.1481858-2-peterx@redhat.com/">https://patchew.org/QEMU/20221213213850.1481858-1-peterx@redhat.com/20221213213850.1481858-2-peterx@redhat.com/
>
> It also looks good with e.g. Gmail webclient.
>
> Then I digged into the email headers and I found that comparing to Manish's
> original message, the patches I posted has one more line of "Content-type":
>
> Content-Type: text/plain; charset="utf-8"
> Content-type: text/plain
> 20221213213850.1481858-2-peterx@redhat.com/mbox">https://patchew.org/QEMU/20221213213850.1481858-2-peterx@redhat.com/mbox
>
> While Manish's patch only has one line:
>
> Content-Type: text/plain; charset="utf-8"
>
> https://patchew.org/QEMU/20221123172735.25181-2-manish.mishra@nutanix.com/mbox
Don't trust what is shown by patchew, as that's been through many
hops.
The copy I receieved came directly to me via CC, so didn't hit mailman,
nor patchew, and that *only* has "Content-type: text/plain". So the
extra Content-type line with utf8 must have been added either by
mailman or patchew.
So it probably looks like a config problem in the tool you use to send
the patches originally.
With 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 :|
[PATCH 2/5] migration: check magic value for deciding the mapping of channels, Peter Xu, 2022/12/13
[PATCH 4/5] migration: Add a semaphore to count PONGs, Peter Xu, 2022/12/13
[PATCH 5/5] migration: Postpone postcopy preempt channel to be after main, Peter Xu, 2022/12/13
[PATCH 3/5] migration: Rework multi-channel checks on URI, Peter Xu, 2022/12/13