On Tue, Aug 25, 2020 at 11:15:11 +0200, Ján Tomko wrote:
On a Monday in 2020, Daniel P. Berrangé wrote:
> On Mon, Aug 24, 2020 at 05:24:51PM +0200, Peter Krempa wrote:
> > On Mon, Aug 24, 2020 at 16:18:40 +0100, Daniel Berrange wrote:
> > > On Thu, Aug 06, 2020 at 11:55:12AM +0200, Peter Krempa wrote:
> > > > Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
> > > > ---
> > > > src/libvirt_private.syms | 1 +
> > > > src/qemu/qemu_driver.c | 138
++-------------------------------------
> > > > src/util/virqemu.c | 130 ++++++++++++++++++++++++++++++++++++
> > > > src/util/virqemu.h | 7 ++
> > > > 4 files changed, 144 insertions(+), 132 deletions(-)
> > >
> > > The original source files were not built on Win32, the new
> > > source files are. This causes a build failure due to...
> >
> > Sigh. I thought that I could make it to be an universal helper. Not very
> > useful, but universal.
> >
> > An alternative solution could be to dump it to qemu_domain.c ...
>
How about qemu_util.c?
qemu_domain.c already is a dump.
Yes, I've already mentioned that in the commit moving it to
qemu_domain.c (for now).
The thing is that qemu_util doesn't exist at this point, it would also
increase confusion of the differenece between qemu_util.c and util/virq
emu.c, which I'd like to avoid in a build fix.
Additionally it's used mostly by qemuDomainOpenFile which kind of
belongs to qemu_domain.c.
If we consider that the confusion between qemu_util.c and util/virqemu.c
is not big enough to add qemu_util.c, I'm willing to make
virQEMUFileOpenAs the first thing to move there.