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.mis...@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?? <berra...@redhat.co > > Suggested-by: Daniel P. Berrang?? <berra...@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: https://lore.kernel.org/all/20221213213850.1481858-2-pet...@redhat.com/ https://patchew.org/QEMU/20221213213850.1481858-1-pet...@redhat.com/20221213213850.1481858-2-pet...@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 https://patchew.org/QEMU/20221213213850.1481858-2-pet...@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.mis...@nutanix.com/mbox I found that it also happens in my local mail archive, so with my local mail client it doesn't show correctly either (mutt here). After I manually removed that extra Content-type line in the archive it went right even locally on mutt. So it seems the 2nd "Content-type: text/plain" overwrote the first one and it may not correctly apply utf-8 in the email client depending on what the email client uses as default. Said that, I'm pretty sure my muttrc has: set charset = "UTF-8" set send_charset = "UTF-8" So neither do I know why that mutt config didn't apply to these patches, nor do I (yet..) have an idea where that extra line comes from.. :-( -- Peter Xu