On Thu, May 09, 2024 at 06:48:36 -0700, Andrea Bolognani wrote: > 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. So I've considered 'exported' filesystem to be a local filesystem made available to other hosts. Basically based on /etc/exports and how NFS works. > What about "userSharedFilesystems"? As in, filesystems that are to be > considered as shared specifically because the user told us to. While 'shared' can be confused with something that is mounted from other host where the existing function "IsSharedFs" works correctly. Since this doesn't work only for exported filesystems, thus the name. > > > > @@ -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. No, not needed :) _______________________________________________ Devel mailing list -- devel@xxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
