Re: [PATCH v3 3/5] qemu: Propagate shared_filesystems
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 :)