Introduce use of a virDomainDefPtr in the domain stats &
peek APIs to simplify introduction of ACL security checks.
The virDomainPtr cannot be safely used, since the app
may have supplied mis-matching name/uuid/id fields. eg
the name points to domain X, while the uuid points to
domain Y. Resolving the virDomainPtr to a virDomainDefPtr
ensures a consistent name/uuid/id set.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Introduce use of a virDomainDefPtr in the domain scheduler
APIs to simplify introduction of ACL security checks.
The virDomainPtr cannot be safely used, since the app
may have supplied mis-matching name/uuid/id fields. eg
the name points to domain X, while the uuid points to
domain Y. Resolving the virDomainPtr to a virDomainDefPtr
ensures a consistent name/uuid/id set.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Introduce use of a virDomainDefPtr in the domain autostart
APIs to simplify introduction of ACL security checks.
The virDomainPtr cannot be safely used, since the app
may have supplied mis-matching name/uuid/id fields. eg
the name points to domain X, while the uuid points to
domain Y. Resolving the virDomainPtr to a virDomainDefPtr
ensures a consistent name/uuid/id set.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Introduce use of a virDomainDefPtr in the domain hotplug
APIs to simplify introduction of ACL security checks.
The virDomainPtr cannot be safely used, since the app
may have supplied mis-matching name/uuid/id fields. eg
the name points to domain X, while the uuid points to
domain Y. Resolving the virDomainPtr to a virDomainDefPtr
ensures a consistent name/uuid/id set.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Introduce use of a virDomainDefPtr in the domain VCPU
APIs to simplify introduction of ACL security checks.
The virDomainPtr cannot be safely used, since the app
may have supplied mis-matching name/uuid/id fields. eg
the name points to domain X, while the uuid points to
domain Y. Resolving the virDomainPtr to a virDomainDefPtr
ensures a consistent name/uuid/id set.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Introduce use of a virDomainDefPtr in the domain create, migrate,
getxml, & define APIs to simplify introduction of ACL security
checks. The virDomainPtr cannot be safely used, since the app
may have supplied mis-matching name/uuid/id fields. eg
the name points to domain X, while the uuid points to
domain Y. Resolving the virDomainPtr to a virDomainDefPtr
ensures a consistent name/uuid/id set.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Introduce use of a virDomainDefPtr in the domain save
APIs to simplify introduction of ACL security checks.
The virDomainPtr cannot be safely used, since the app
may have supplied mis-matching name/uuid/id fields. eg
the name points to domain X, while the uuid points to
domain Y. Resolving the virDomainPtr to a virDomainDefPtr
ensures a consistent name/uuid/id set.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Introduce use of a virDomainDefPtr in the domain property
APIs to simplify introduction of ACL security checks.
The virDomainPtr cannot be safely used, since the app
may have supplied mis-matching name/uuid/id fields. eg
the name points to domain X, while the uuid points to
domain Y. Resolving the virDomainPtr to a virDomainDefPtr
ensures a consistent name/uuid/id set.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Introduce use of a virDomainDefPtr in the domain lifecycle
APIs to simplify introduction of ACL security checks.
The virDomainPtr cannot be safely used, since the app
may have supplied mis-matching name/uuid/id fields. eg
the name points to domain X, while the uuid points to
domain Y. Resolving the virDomainPtr to a virDomainDefPtr
ensures a consistent name/uuid/id set.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Introduce use of a virDomainDefPtr in the domain lookup
APIs to simplify introduction of ACL security checks.
The virDomainPtr cannot be safely used, since the app
may have supplied mis-matching name/uuid/id fields. eg
the name points to domain X, while the uuid points to
domain Y. Resolving the virDomainPtr to a virDomainDefPtr
ensures a consistent name/uuid/id set.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Several files called out COPYING or COPYING.LIB instead of using
the normal boilerplate.  It's especially important that we don't
call out COPYING from an LGPL file, since COPYING is traditionally
used for the GPL.  A few files were lacking copyright altogether.

* src/rpc/gendispatch.pl: Add missing copyright.
* Makefile.nonreentrant: Likewise.
* src/check-symfile.pl: Likewise.
* src/check-symsorting.pl: Likewise.
* src/driver.h: Likewise.
* src/internal.h: Likewise.
* tools/libvirt-guests.sh.in: Likewise.
* tools/virt-pki-validate.in: Mention copyright in comment, not just code.
* tools/virt-sanlock-cleanup.in: Likewise.
* src/rpc/genprotocol.pl: Spell out license terms.
* src/xen/xend_internal.h: Likewise.
* src/xen/xend_internal.c: Likewise.
* Makefile.am: Likewise.
* daemon/Makefile.am: Likewise.
* docs/Makefile.am: Likewise.
* docs/schemas/Makefile.am: Likewise.
* examples/apparmor/Makefile.am: Likewise.
* examples/domain-events/events-c/Makefile.am: Likewise.
* examples/dominfo/Makefile.am: Likewise.
* examples/domsuspend/Makefile.am: Likewise.
* examples/hellolibvirt/Makefile.am: Likewise.
* examples/openauth/Makefile.am: Likewise.
* examples/python/Makefile.am: Likewise.
* examples/systemtap/Makefile.am: Likewise.
* examples/xml/nwfilter/Makefile.am: Likewise.
* gnulib/lib/Makefile.am: Likewise.
* gnulib/tests/Makefile.am: Likewise.
* include/Makefile.am: Likewise.
* include/libvirt/Makefile.am: Likewise.
* python/Makefile.am: Likewise.
* python/tests/Makefile.am: Likewise.
* src/Makefile.am: Likewise.
* tests/Makefile.am: Likewise.
* tools/Makefile.am: Likewise.
* configure.ac: Likewise.
Signed-off-by: NEric Blake <eblake@redhat.com>

The inotify Xen code causes a cast alignment warning, but this
is harmless since the kernel inotify interface will ensure
sufficient alignment of the inotify structs in the buffer being
read
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

These all existed before virfile.c was created, and for some reason
weren't moved.

This is mostly straightfoward, although the syntax rule prohibiting
write() had to be changed to have an exception for virfile.c instead
of virutil.c.

This movement pointed out that there is a function called
virBuildPath(), and another almost identical function called
virFileBuildPath(). They really should be a single function, which
I'll take care of as soon as I figure out what the arglist should look
like.

Make the Xen domain stats / peek and node memory driver
methods unconditionally call the sub-drivers which are
guaranteed to be open.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Unconditionally call into the XenD or XM drivers for autostart
handling, since they are guaranteed to be open

Make the Xen domain scheduler parameter methods directly
call into XenD or Xen hypervisor drivers
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Make the domain attach/dettach driver methods directly call
into either the XenD or XM drivers
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Make the domain define/undefine driver methods directly call
into either the XenD or XM drivers
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Directly call either the XenD or XM driver when starting
a persistent domain
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Directly call either XenD or the XM driver for handling
domain define operations.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

All the migration code is done by the XenD subdriver which
can be assumed to always be present
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The xenUnifiedDomainGetXMLDesc driver can assume that
the XM and XenD drivers are always present
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Unconditionally call the XenD APIs for save/restore, since that
driver will always be open.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Make the xenUnifiedDomainGetInfo and xenUnifiedDomainGetState drivers
call the correct sub-driver APIs directly.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Simplify the Xen memory limit driver methods to directly call
the most appropriate sub-driver
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The xenGetHostname entry point in the xenUnifiedDriver table
was unused.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Make xenUnifiedDomainGetOSType directly call either the
xenHypervisorDomainGetOSType or xenDaemonDomainGetOSType
method depending on whether the domain is active or not.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Unconditionally call the xenDaemonDomainDestroyFlags API
since the XenD driver is always available.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Make the xenUnifiedDomainShutdownFlags and xenUnifiedDomainReboot
driver methods unconditionally call the XenD APIs for shutdown
and reboot. Delete the unreachable impls in the XenStore driver.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Update xenUnifiedDomainSuspend and xenUnifiedDomainResume to
unconditionally invoke the XenD APIs for suspend/resume. Delete
the impls in the hypervisor driver which was unreachable.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Unconditionally call xenDaemonLookupByUUID, since the XenD
driver must always be present.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Unconditionally invoke the xenHypervisorLookupDomainByID,
xenHypervisorLookupDomainByUUID or xenDaemonLookupByName
for looking up domains. Fallback to xenXMDomainLookupByUUID
and xenXMDomainLookupByName for legacy XenD without inactive
domain support
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Unconditionally call xenDaemonCreateXML in the
xenUnifiedDomainCreateXML driver, since the XenD
driver is always present.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The XenStore driver is mandatory, so it can be used unconditonally
for the xenUnifiedConnectListDomains & xenUnifiedConnectNumOfDomains
drivers. Delete the unused XenD and Hypervisor driver code for
listing / counting domains
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Unconditionally call into xenHypervisorGetMaxVcpus and
xenDaemonNodeGetInfo respectively, since those drivers
are both mandatory
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The hypervisor driver is mandatory, so the the call to
xenHypervisorGetVersion must always succeed. Thus there
is no need to ever run xenDaemonGetVersion
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

There is no point iterating over sub-drivers since the user
would not have a virConnectPtr instance at all if opening
the drivers failed. Just return 'Xen' immediately.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Since the Xen driver was changed to only execute inside libvirtd,
there is no scenario in which it will be opened from a non-privileged
context. Thus all the code dealing with opening the sub-drivers can
be simplified to assume that they are always privileged.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The Xen driver uses a macro GET_PRIVATE as a supposed shorthand
for 'xenUnifiedPrivatePtr priv = (xenUnifiedPrivatePtr) (conn)->privateData'.
It does not in fact save any lines of code, and obscures what is
happening. Remove it, since it adds no value.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>