Re: [PATCH v3 3/5] qemu: Propagate shared_filesystems

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux