Re: [libvirt] [PATCH 02/14] storage: move storage file backend framework into util directory

On Thu, Jan 25, 2018 at 10:38:32 +0000, Daniel Berrange wrote: > On Thu, Jan 25, 2018 at 11:33:57AM +0100, Peter Krempa wrote: > > On Thu, Jan 25, 2018 at 09:38:13 +0000, Daniel Berrange wrote: > > > The QEMU driver loadable module needs to be able to resolve all ELF > > > symbols it references against libvirt.so. Some of its symbols can only > > > be resolved against the storage_driver.so loadable module which creates > > > a hard dependancy between them. By moving the storage file backend > > > framework into the util directory, this gets included directly in the > > > libvirt.so library. The actual backend implementations are still done as > > > loadable modules, so this doesn't re-add deps on gluster libraries. > > > > > > Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com&gt; > > > --- > > > > [...] > > > > > diff --git a/src/storage/storage_source_backend.h b/src/util/virstoragefilebackend.h > > > similarity index 94% > > > rename from src/storage/storage_source_backend.h > > > rename to src/util/virstoragefilebackend.h > > > index 8288bebb1f..6cd51750ee 100644 > > > --- a/src/storage/storage_source_backend.h > > > +++ b/src/util/virstoragefilebackend.h > > > @@ -1,5 +1,5 @@ > > > /* > > > - * storage_source_backend.h: internal storage source backend contract > > > + * virstoragefilebackend.h: internal storage source backend contracta > > > > I was actually striving to move and rename all the stuff dealing with > > virStorageSource to be called with the appropriate prefix. This will > > also need splitting of src/util/virstoragefile.c, so this would be a > > regression in naming in my opinion. > > All these APIs are currently called virStorageFileXXXX right now though, > so this is really fixing the inconsistency we already had between API > name and file name right now. I agree though, it could be nice to > further rename the APIs to be called virStorageSourceXXXX, and move > them into a virstoragesource.{c,h} file, but I think that's a separate > followup since its a pre-existing problem with virstoragefile.{c,h}. Hmm, yeah it's pre-existing for a long time and incidentally I don't know why I used the 'virStorageFile' prefix in this case.