[libvirt] [PATCH 07/13] Add libvirt-admin library
mkletzan at redhat.com
Sat May 23 21:05:55 UTC 2015
On Fri, May 22, 2015 at 12:59:44PM +0100, Daniel P. Berrange wrote:
>On Thu, May 21, 2015 at 10:22:26PM -0700, Martin Kletzander wrote:
>> On Thu, May 21, 2015 at 05:46:59PM +0200, Michal Privoznik wrote:
>> >On 20.05.2015 07:19, Martin Kletzander wrote:
>> >>Initial scratch of the admin library. It has its own virAdmConnectPtr
>> >>that inherits from virAbstractConnectPtr and thus trivially supports
>> >>error reporting.
>> >>There's pkg-config file added and spec-file adjusted as well.
>> >>Since the library should be "minimalistic" and not depend on any other
>> >>library, the list of files is especially crafted for it. Most of them
>> >>could've been put to it's own sub-libraries that would be LIBADD'd to
>> >>libvirt_util, libvirt_net_rpc and libvirt_setuid_rpc_client to minimize
>> >>the number of object files being built, but that's a refactoring that
>> >>isn't the orginal aim of this commit.
>> >>+ datatypes.c \
>> >>+ util/viralloc.c \
>> >>+ util/viratomic.c \
>> >>+ util/virauth.c \
>> >>+ util/virauthconfig.c \
>> >>+ util/virbitmap.c \
>> >>+ util/virbuffer.c \
>> >>+ util/vircommand.c \
>> >>+ util/virerror.c \
>> >>+ util/virevent.c \
>> >>+ util/vireventpoll.c \
>> >>+ util/virfile.c \
>> >>+ util/virhash.c \
>> >>+ util/virhashcode.c \
>> >>+ util/virjson.c \
>> >>+ util/virkeyfile.c \
>> >>+ util/virlog.c \
>> >>+ util/virobject.c \
>> >>+ util/virpidfile.c \
>> >>+ util/virprocess.c \
>> >>+ util/virrandom.c \
>> >>+ util/virseclabel.c \
>> >>+ util/virsocketaddr.c \
>> >>+ util/virstorageencryption.c \
>> >>+ util/virstoragefile.c \
>> >>+ util/virstring.c \
>> >>+ util/virthread.c \
>> >>+ util/virtime.c \
>> >>+ util/virtypedparam.c \
>> >>+ util/viruri.c \
>> >>+ util/virutil.c \
>> >>+ util/viruuid.c \
>> >>+ util/virxml.c \
>> >>+ remote/remote_protocol.c \
>> >This drags in (de)serializers for all the public APIs we have. I guess
>> >you have it here just becase of serializers for some basic types (e.g.
>> >string). Well, if we introduce a separate libvirt_admin.x file, rpcgen
>> >will generate the serializers again, and just for the types we need. So
>> >I think it's safe to drop this line (and libvirt-admin.so will lose
>> >some weight).
>> Yes, but I have to rename that to something else than remote_string
>> because that would collide in the libvirt daemon. That would mean I
>> have to add each of the new names to gendispatch.pl. And so on and so
>> on, just to get rid of some (de)serializers in the client library.
>> I'll do that for remote_string for now, but if there are more than
>> that, we should probably put those into another file. Well, you'll
>> see how much bigger the diff will be even now.
>> >Then, I wonder if we need to recompile nearly all utils/ again. Can't
>> >we just link libvirt_utils.so in?
>> Well, I wanted to make it lightweight even when it increases
>> compilation time as it looks like we are constantly OK with that
>> (setuid_rpc_client, vbox libs, etc.), but as I said in the commit
>> message, I'd like to see a commit that minimizes the files being
>I don't think you are actually making this lightweight as you intend.
>In reality anyone who is using libvirt-admin.so will likely already
>have libvirt.so in memory. So by recompiling the files you are causing
>two copies of the same code to be kept in RAM. So if libvirt-admin.so
>just linked to libvirt.so, then we would in fact be more lightweight
>than this, and avoid the recompilation.
OK, I though that shouldn't be the case, so it is installable
separably, but since we allow only local socket for now, you're right
that there's libvirt.so already loaded.
>The recompilation for the setuid binary is a special case because
>we have security requirements that trump the extra overhead that
>the duplication implies both at compile time and runtime.
>So I don't think the recompilation is really justified in the case
>One day though, I do think we should perhaps turn things like
>libvirt_util.la, libvirt_rpc.la, etc into a formally installed
>.so's that we can dynamically link to from other libvirt parts.
>We'd /not/ include any header files, as these .so's would be
>solely for libvirt usage, not application usage. I think this
>would ultimately better achieve what you're trying todo here.
>|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
>|: http://libvirt.org -o- http://virt-manager.org :|
>|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
>|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: not available
More information about the libvir-list