[libvirt RFCv4 03/20] iohelper: move runIO function to a separate module

Claudio Fontana cfontana at suse.de
Fri Apr 29 10:13:24 UTC 2022


On 4/29/22 12:08 PM, Claudio Fontana wrote:
> On 4/28/22 2:55 PM, Daniel P. Berrangé wrote:
>> On Wed, Apr 27, 2022 at 11:13:22PM +0200, Claudio Fontana wrote:
>>> where it can be reused by other helpers.
>>> No changes other than the move.
>>>
>>> Signed-off-by: Claudio Fontana <cfontana at suse.de>
>>> ---
>>>  po/POTFILES.in       |   1 +
>>>  src/util/iohelper.c  | 178 +----------------------------------
>>>  src/util/meson.build |   2 +
>>>  src/util/runio.c     | 214 +++++++++++++++++++++++++++++++++++++++++++
>>>  src/util/runio.h     |  23 +++++
>>>  5 files changed, 241 insertions(+), 177 deletions(-)
>>>  create mode 100644 src/util/runio.c
>>>  create mode 100644 src/util/runio.h
>>
>>
>>
>>> +off_t runIO(const char *path, int fd, int oflags);
>>
>> I think we could just put it in virfile.{ch} and call it
>> virFileCopyData
> 
> hmmm... it is not quite as generic as the name would imply though.
> 
> The API centers around a transfer between a disk (the focus of the API), and something else (pipe, socket).
> 
> What about VirFileDiskCopy?
> 

Btw what about

#define VIR_FROM_THIS ?

In virtfile.c it is

#define VIR_FROM_THIS VIR_FROM_NONE

while in iohelper it is

#define VIR_FROM_THIS VIR_FROM_STORAGE

I guess this is error-reporting related,

should we lose the #define VIR_FROM_THIS VIR_FROM_STORAGE with the move to virfile.c ?

Thanks,

Claudio



More information about the libvir-list mailing list