[PATCH v1 01/12] libxl: add API wrapper for libxl_domain_create_restore

[Daniel P. Berrangé]

On Thu, Mar 25, 2021 at 05:54:07PM -0600, Jim Fehlig wrote:
> On 3/22/21 4:28 AM, Daniel P. Berrangé wrote:
> > On Thu, Mar 18, 2021 at 09:51:18PM -0600, Jim Fehlig wrote:
> > > On 3/18/21 5:00 PM, Olaf Hering wrote:
> > > > Am Thu, 18 Mar 2021 16:26:14 -0600
> > > > schrieb Jim Fehlig <jfehlig at suse.com>:
> > > > 
> > > > > Maybe libxlDomainCreateRestoreWrap?
> > > > > The 'Wrap' suffix compliments the libxl_api_wrap.h name suggestion.
> > > > 
> > > > "Naming conventions" does not cover API wrapping.
> > > 
> > > I was referring to the use of '_' in the names. From the coding style doc:
> > > "Underscores should not be used in function names". The style doc doesn't
> > > dictate the words used to form function names, but does suggest a
> > > vir$object$verb$subject pattern.
> > > 
> > > > Some of the names are already taken, like libxl_domain_shutdown/libxlDomainShutdown.
> > > 
> > > In hindsight I would have probably used the 'vir' prefix in the driver entry
> > > points, e.g. virlibxlDomainShutdown (libxl_driver.c), giving some
> > > flexibility for driver-internal function naming. There is nothing preventing
> > > such change now, other than the future annoyance of backport conflicts.
> > 
> > FWIW, in retrospect, I think we shouldn't have used "libxl" as a naming
> > convention anywhere in libvirt - neither filenames or method names. This
> > is a Xen driver, and libxl is just an impl detail. IOW, I we ought to
> > have just use  "virXen" as the method name / typedef prefix, and
> > xen_driver.c  as filename, etc.
> 
> Agreed. I had a memory lapse about our previous discussions around
> s/libxl/xen/, e.g.
> 
> https://listman.redhat.com/archives/libvir-list/2020-May/msg00081.html
> 
> It would have all come back if I started doing the work. Just thinking about
> it again reminds me of all the "difficult" places libxl has leaked. I
> mentioned the build option in above thread, but there's also deployment
> (/etc/libvirt/libxl*) and runtime (/var/{lib,log,run}/libvirt/libxl*)
> leakage. If starting on such an adventure I'm not sure where to stop.
> Handling the deployment/runtime leakages likely requires symlinks,
> %post{un,trans} hacks, etc.
> 
> I'd be interested in the basic strategy you (or others) would take if
> embarking on such adventure :-).

We've only done a rename of stuff on disk once IIRC, when we introduced
the use of XDG dirs for the session libvirtd instances. In that case we
just renamed all the dirs during libvirtd startup IIRC. This of course
prevents downgrades entirely. We had to keep the rename logic around
for a very long time too.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|