[...] >>> >> I see what you mean; however, IMO vstorage should be separate. Maybe >> there's another opinion out there, but since you're requiring >> "something" else to be installed in order to get the WITH_VSTORAGE to be >> set to 1, then a separate file is in order. >> >> Not sure they're comparable, but zfs has its own. Having separated >> vstorage reduces the chance that some day some incompatible logic is >> added/altered in the *fs.c (or vice versa). > > Ok. I will try. > >> >> I think you should consider the *_fs.c code to be the "default" of >> sorts. That is default file/dir structure with netfs added in. The >> vstorage may just be some file system, but it's not something (yet) on >> "every" distribution. > > I did not understand actually, what you mean "be the "default" of sorts." > As I have understood - what I need to do is to create backend_vstorage.c > with all create/delete/* functionality. > Sorry - I was trying to think of a better way to explain... The 'fs' and 'nfs' pool are default of sorts because one can "ls" (on UNIX/Linux) or "dir" (on Windows) and get a list of files. "ls" and "dir" are inherent to the OS, while in this case vstorage commands are installed separately. When you create a vstorage "file" is that done via touch? or edit some path or some other "common" OS command? Or is there a vstorage command that needs to be used. If the former, then using the common storage_backend API's should be possible. John >> >> Also I forgot to mention yesterday - you need to update the >> docs/formatstorage.html.in at the very least and also the storage driver >> page docs/storage.html.in. >> In addition there are storagepool tests (xml2xml) that would need to be >> updated to validate the new storage pool type. The tests would "show" >> how the pool XML would appear and validate whatever parsing has been >> done. > > I know. Will fix. > [...] -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
