The following changes since commit 8e5dc9ba49743b46d955ec7dacb04e42ae7ada7c: Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20180116' into staging (2018-01-16 17:36:39 +0000) are available in the Git repository at: https://github.com/elmarco/qemu.git tags/dump-pull-request for you to fetch changes up to 48fb74965a8d8f2916da30d9c5b9945df25142af: dump-guest-memory.py: fix python 2 support (2018-01-17 15:47:14 +0100) ---------------------------------------------------------------- ---------------------------------------------------------------- Marc-André Lureau (1): dump-guest-memory.py: fix python 2 support scripts/dump-guest-memory.py | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- 2.16.0.rc1.1.gef27df75a1
On 01/17/2018 08:47 AM, Marc-André Lureau wrote: > The following changes since commit 8e5dc9ba49743b46d955ec7dacb04e42ae7ada7c: > > Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20180116' into staging (2018-01-16 17:36:39 +0000) > > are available in the Git repository at: > > https://github.com/elmarco/qemu.git tags/dump-pull-request > > for you to fetch changes up to 48fb74965a8d8f2916da30d9c5b9945df25142af: > > dump-guest-memory.py: fix python 2 support (2018-01-17 15:47:14 +0100) > The commit says it works with python 2.7, but we still require support for python 2.6. Is this pull request premature? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
On 17 January 2018 at 15:02, Eric Blake <eblake@redhat.com> wrote: > On 01/17/2018 08:47 AM, Marc-André Lureau wrote: >> The following changes since commit 8e5dc9ba49743b46d955ec7dacb04e42ae7ada7c: >> >> Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20180116' into staging (2018-01-16 17:36:39 +0000) >> >> are available in the Git repository at: >> >> https://github.com/elmarco/qemu.git tags/dump-pull-request >> >> for you to fetch changes up to 48fb74965a8d8f2916da30d9c5b9945df25142af: >> >> dump-guest-memory.py: fix python 2 support (2018-01-17 15:47:14 +0100) >> > > The commit says it works with python 2.7, but we still require support > for python 2.6. Is this pull request premature? So should I apply this, or not? thanks -- PMM
Hi On Fri, Jan 19, 2018 at 3:29 PM, Peter Maydell <peter.maydell@linaro.org> wrote: > On 17 January 2018 at 15:02, Eric Blake <eblake@redhat.com> wrote: >> On 01/17/2018 08:47 AM, Marc-André Lureau wrote: >>> The following changes since commit 8e5dc9ba49743b46d955ec7dacb04e42ae7ada7c: >>> >>> Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20180116' into staging (2018-01-16 17:36:39 +0000) >>> >>> are available in the Git repository at: >>> >>> https://github.com/elmarco/qemu.git tags/dump-pull-request >>> >>> for you to fetch changes up to 48fb74965a8d8f2916da30d9c5b9945df25142af: >>> >>> dump-guest-memory.py: fix python 2 support (2018-01-17 15:47:14 +0100) >>> >> >> The commit says it works with python 2.7, but we still require support >> for python 2.6. Is this pull request premature? > > So should I apply this, or not? I have not found how to translate a python 'buffer' to a bytes string in 2.6. For now, I think we should go with this patch, it's already an improvement.. Thanks
On 01/19/2018 08:35 AM, Marc-Andre Lureau wrote: >>>> dump-guest-memory.py: fix python 2 support (2018-01-17 15:47:14 +0100) >>>> >>> >>> The commit says it works with python 2.7, but we still require support >>> for python 2.6. Is this pull request premature? >> >> So should I apply this, or not? > > I have not found how to translate a python 'buffer' to a bytes string > in 2.6. For now, I think we should go with this patch, it's already an > improvement.. Argument in favor of applying: dump-guest-memory.py is not run as part of the build process, nor during 'make check'; rather, it is an add-on script for developer convenience after installation. If we apply the patch, we break developers on machines using python 2.6, but fix things for developers on machines with python 3 - and as time (and Fedora rawhide) march on, the balance swings in favor of the latter. I personally am not enough of a python expert to propose a fix that works across all versions supported by configure, but it was Marc-Andre reminding me on IRC that this is not a build script, so it can have different standards than our build when it comes to portability. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
On 19 January 2018 at 14:35, Marc-Andre Lureau <mlureau@redhat.com> wrote: > I have not found how to translate a python 'buffer' to a bytes string > in 2.6. A local python expert suggests that "bytes(buffer)" should work. thanks -- PMM
On 19 January 2018 at 15:24, Peter Maydell <peter.maydell@linaro.org> wrote: > On 19 January 2018 at 14:35, Marc-Andre Lureau <mlureau@redhat.com> wrote: >> I have not found how to translate a python 'buffer' to a bytes string >> in 2.6. > > A local python expert suggests that "bytes(buffer)" should work. ...and that it ought to work if handed a memoryview too, so do we just want self.elf.add_vmcoreinfo_note(bytes(vmcoreinfo)) ? thanks -- PMM
Hi On Fri, Jan 19, 2018 at 4:29 PM, Peter Maydell <peter.maydell@linaro.org> wrote: > On 19 January 2018 at 15:24, Peter Maydell <peter.maydell@linaro.org> wrote: >> On 19 January 2018 at 14:35, Marc-Andre Lureau <mlureau@redhat.com> wrote: >>> I have not found how to translate a python 'buffer' to a bytes string >>> in 2.6. >> >> A local python expert suggests that "bytes(buffer)" should work. > > ...and that it ought to work if handed a memoryview too, so do we > just want > > self.elf.add_vmcoreinfo_note(bytes(vmcoreinfo)) > Yes, I tested on 2.6 and 3.6, it works. I'll send a new patch. Thanks!
On 19 January 2018 at 16:08, Marc-Andre Lureau <mlureau@redhat.com> wrote: > Hi > > On Fri, Jan 19, 2018 at 4:29 PM, Peter Maydell <peter.maydell@linaro.org> wrote: >> On 19 January 2018 at 15:24, Peter Maydell <peter.maydell@linaro.org> wrote: >>> On 19 January 2018 at 14:35, Marc-Andre Lureau <mlureau@redhat.com> wrote: >>>> I have not found how to translate a python 'buffer' to a bytes string >>>> in 2.6. >>> >>> A local python expert suggests that "bytes(buffer)" should work. >> >> ...and that it ought to work if handed a memoryview too, so do we >> just want >> >> self.elf.add_vmcoreinfo_note(bytes(vmcoreinfo)) >> > > Yes, I tested on 2.6 and 3.6, it works. I'll send a new patch. Testing 2.7 as well would probably not be a bad plan. Apparently this works because: * on python 3, bytes(memoryview) and memoryview.to_bytes() are the same * gdb gives us a memoryview only if python 3 * so we don't have to handle the case of getting a memoryview and being python 2 (in which case we would need to use memoryview.to_bytes() as bytes() would do the wrong thing) thanks -- PMM
On Fri, Jan 19, 2018 at 5:21 PM, Peter Maydell <peter.maydell@linaro.org> wrote: > On 19 January 2018 at 16:08, Marc-Andre Lureau <mlureau@redhat.com> wrote: >> Hi >> >> On Fri, Jan 19, 2018 at 4:29 PM, Peter Maydell <peter.maydell@linaro.org> wrote: >>> On 19 January 2018 at 15:24, Peter Maydell <peter.maydell@linaro.org> wrote: >>>> On 19 January 2018 at 14:35, Marc-Andre Lureau <mlureau@redhat.com> wrote: >>>>> I have not found how to translate a python 'buffer' to a bytes string >>>>> in 2.6. >>>> >>>> A local python expert suggests that "bytes(buffer)" should work. >>> >>> ...and that it ought to work if handed a memoryview too, so do we >>> just want >>> >>> self.elf.add_vmcoreinfo_note(bytes(vmcoreinfo)) >>> >> >> Yes, I tested on 2.6 and 3.6, it works. I'll send a new patch. > > Testing 2.7 as well would probably not be a bad plan. Apparently > this works because: > * on python 3, bytes(memoryview) and memoryview.to_bytes() are the same > * gdb gives us a memoryview only if python 3 > * so we don't have to handle the case of getting a memoryview and > being python 2 (in which case we would need to use memoryview.to_bytes() > as bytes() would do the wrong thing) I just tested with 2.7 as well, works fine too. Updated patch sent.
© 2016 - 2025 Red Hat, Inc.