On 11/02/2017 12:11 AM, John Ferlan wrote: > > > On 10/24/2017 07:41 AM, Michal Privoznik wrote: >> This function works over domain definition and not domain object. >> Its name is thus misleading. >> >> Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> >> --- >> src/conf/domain_conf.c | 4 ++-- >> src/conf/domain_conf.h | 2 +- >> src/libvirt_private.syms | 2 +- >> src/qemu/qemu_conf.c | 2 +- >> src/qemu/qemu_domain.c | 4 ++-- >> src/qemu/qemu_driver.c | 2 +- >> 6 files changed, 8 insertions(+), 8 deletions(-) >> > > Reviewed-by: John Ferlan <jferlan@xxxxxxxxxx> > > John > > BTW: I wonder if this function is somewhat broken - it's using def->id > in order to generate the output, right? Which means for paths generated > before the guest starts, they'll start with "-1"... IOW: Directory and > file names that start with "-". > > This wasn't a problem originally (commit id a042275a) since the > resulting path had "domain-" prepended to it - resulting in > "domain--1-QEMUGuest1, for example). > > Personally, this looks REALLY odd when (re)using for example with a > hugepage test where the path is "-mem-path > /dev/hugepages2M/libvirt/qemu/-1-QEMUGuest1". This is because we don't set an ID for domains when testing. However, in real scenarios this function is called over running domains. Therefore, the path will always start with a natural number. I don't think there's anything to fix really. We could go with "domain-" prefix but that'd be no better in fact. Yes, it would help with 'rm' case but other than that it has no added value. Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
