On Thu, May 09, 2024 at 02:17:21PM GMT, Peter Krempa wrote: > I'd go with 'exportedFilesystems' instead of 'sharedFilesystems' > throughout this patch(set) for any case when the list contains only the > paths configured by user (from previous commit). Isn't that all cases? We never build a list where we add the user-provided paths to those that have been detected as shared via other means AFAICT. > That way it'd be IMO more clear that the list contains only filesystems > which are local on this host, rather than having also anything that's > consiedered shared. > > It IMO would make sense to consider that e.g. also for the name of the > config option. I can certainly change the name, but if the goal is to make things clearer to someone looking at a function in isolation I'm not entirely sure "exportedFilesystems" will help much. What about "userSharedFilesystems"? As in, filesystems that are to be considered as shared specifically because the user told us to. > > @@ -1611,20 +1612,23 @@ qemuMigrationSrcIsAllowed(virDomainObj *vm, > > } > > > > static bool > > -qemuMigrationSrcIsSafe(virDomainDef *def, > > - virQEMUCaps *qemuCaps, > > +qemuMigrationSrcIsSafe(virDomainObj *vm, > > size_t nmigrate_disks, > > const char **migrate_disks, > > unsigned int flags) > > Sneaky refactor :) Do you want me to split it off to a separate patch? I can do that. -- Andrea Bolognani / Red Hat / Virtualization _______________________________________________ Devel mailing list -- devel@xxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
