On Wed, Apr 11, 2018 at 08:02:58AM -0500, Eric Blake wrote:
> You could always add qemu_fopen/qemu_fclose to match the existing
> qemu_open/qemu_close. But you do have a point that you can't call
> qemu_close/fclose (because fclose would be left with a stale fd that
> might spuriously close
On 04/11/2018 02:36 AM, Simon Ruderich wrote:
> On Tue, Apr 10, 2018 at 04:33:03PM -0500, Eric Blake wrote:
>>> +void qmp_pmemload(int64_t addr, int64_t size, const char *filename,
>>> + Error **errp)
>>> +{
>>> +FILE *f;
>>> +size_t l;
>>> +uint8_t buf[1024];
>>> +
On Tue, Apr 10, 2018 at 04:33:03PM -0500, Eric Blake wrote:
>> +void qmp_pmemload(int64_t addr, int64_t size, const char *filename,
>> + Error **errp)
>> +{
>> +FILE *f;
>> +size_t l;
>> +uint8_t buf[1024];
>> +
>> +f = fopen(filename, "rb");
>
> Use qemu_fopen()
On 04/10/2018 04:24 PM, Simon Ruderich wrote:
> Adapted patch from Baojun Wang [1] with the following commit message:
>
> I found this could be useful to have qemu-softmmu as a cross
> debugger (launch with -s -S command line option), then if we can
> have a command to load guest
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id:
0e59c79ddc01e195ddc59d77d9df2b95bf89b600.1523395243.git.si...@ruderich.org
Subject: [Qemu-devel] [PATCH] qmp: add pmemload command
=== TEST SCRIPT BEGIN ===
#!/bin/bash
Adapted patch from Baojun Wang [1] with the following commit message:
I found this could be useful to have qemu-softmmu as a cross
debugger (launch with -s -S command line option), then if we can
have a command to load guest physical memory, we can use cross gdb
to do some target
