The generator can handle DomainBlockPullAll and DomainBlockPullAbort.
DomainBlockPull and DomainBlockPullInfo must be written by hand.

* src/remote/remote_protocol.x: provide defines for the new entry points
* src/remote/remote_driver.c daemon/remote.c: implement the client and
  server side
* src/remote_protocol-structs: structure definitions for protocol verification
Signed-off-by: NAdam Litke <agl@us.ibm.com>

Signed-off-by: NMinoru Usui <usui@mxm.nes.nec.co.jp>

Signed-off-by: NMinoru Usui <usui@mxm.nes.nec.co.jp>

This patch implements the remote protocol for the new API
(virDomainPinVcpuFlags).

Detected by Coverity.  Only possible in OOM situations.

* daemon/remote.c (remoteDispatchDomainScreenshot): Plug leak.

This doesn't cover the getters that allow to query nparams yet.

Remove some special case code that took care of mapping hyper to the
correct C types.

As the list of procedures that is allowed to map hyper to long is fixed
put it in the generator instead annotations in the .x files. This
results in simpler .x file parsing code.

Use macros for hyper to long assignments that perform overflow checks
when long is smaller than hyper. Map hyper to long long by default.

Suggested by Eric Blake.

We commonly use "value, length" order, let's stick to this.

This introduces a new domain

  VIR_DOMAIN_EVENT_ID_CONTROL_ERROR

Which uses the existing generic callback

typedef void (*virConnectDomainEventGenericCallback)(virConnectPtr conn,
                                                     virDomainPtr dom,
                                                     void *opaque);

This event is intended to be emitted when there is a failure in
some part of the domain virtualization system. Whether the domain
continues to run/exist after the failure is an implementation
detail specific to the hypervisor.

The idea is that with some types of failure, hypervisors may
prefer to leave the domain running in a "degraded" mode of
operation. For example, if something goes wrong with the QEMU
monitor, it is possible to leave the guest OS running quite
happily. The mgmt app will simply loose the ability todo various
tasks. The mgmt app can then choose how/when to deal with the
failure that occured.
* daemon/remote.c: Dispatch of new event
* examples/domain-events/events-c/event-test.c: Demo catch
  of event
* include/libvirt/libvirt.h.in: Define event ID and callback
* src/conf/domain_event.c, src/conf/domain_event.h: Internal
  event handling
* src/remote/remote_driver.c: Receipt of new event from daemon
* src/remote/remote_protocol.x: Wire protocol for new event
* src/remote_protocol-structs: add new event for checks

* daemon/remote.c (remoteDispatchDomainGetSchedulerParameters):
New function.
* src/remote/remote_driver.c (remoteDomainGetSchedulerParameters):
Likewise.
* src/remote/remote_protocol.x
(remote_domain_get_scheduler_parameters_flags_args)
(remote_domain_get_scheduler_parameters_flags_ret): New types.
(remote_procedure): New RPC.
* src/remote_protocol-structs: Likewise.

* src/remote/remote_protocol.x (remote_typed_param_value)
(remote_typed_param):  New types.
(remote_sched_param_value, remote_sched_param)
(remote_blkio_param_value, remote_blkio_param)
(remote_memory_param_value, remote_memory_param): Delete.
(remote_domain_get_scheduler_parameters_ret)
(remote_domain_set_scheduler_parameters_args)
(remote_domain_set_scheduler_parameters_flags_args)
(remote_domain_set_blkio_parameters_args)
(remote_domain_get_blkio_parameters_ret)
(remote_domain_set_memory_parameters_args)
(remote_domain_get_memory_parameters_ret): Update clients.
* src/remote_protocol-structs: Likewise.
* src/remote/remote_driver.c (remoteSerializeTypedParameters)
(remoteDeserializeTypedParameters): New functions.
(remoteDomainSetMemoryParameters)
(remoteDomainGetMemoryParameters, remoteDomainSetBlkioParameters)
(remoteDomainGetBlkioParameters)
(remoteDomainGetSchedulerParameters)
(remoteDomainSetSchedulerParameters)
(remoteDomainSetSchedulerParametersFlags): Update clients.
* daemon/remote.c (remoteSerializeTypedParameters)
(remoteDeserializeTypedParameters): New functions.
(remoteDispatchDomainGetSchedulerParameters)
(remoteDispatchDomainSetSchedulerParameters)
(remoteDispatchDomainSetSchedulerParametersFlags)
(remoteDispatchDomainSetMemoryParameters)
(remoteDispatchDomainGetMemoryParameters)
(remoteDispatchDomainSetBlkioParameters)
(remoteDispatchDomainGetBlkioParameters): Update clients.

Rather mechanical in nature.

* src/driver.h: Use newer virTypedParameter API names.
* src/libvirt.c: Likewise.
* daemon/remote.c: Likewise.
* src/esx/esx_driver.c: Likewise.
* src/libxl/libxl_driver.c: Likewise.
* src/lxc/lxc_driver.c: Likewise.
* src/qemu/qemu_driver.c: Likewise.
* src/remote/remote_driver.c: Likewise.
* src/test/test_driver.c: Likewise.
* src/xen/xen_driver.c: Likewise.
* src/xen/xen_hypervisor.c: Likewise.
* src/xen/xen_hypervisor.h: Likewise.
* src/xen/xend_internal.c: Likewise.
* tools/virsh.c: Likewise.

Extend procedure annotation in the .x file for stream handling.

Adds a missing remoteStreamRelease call to remoteDomainScreenshot
error path.

Add special case code for updating a given domain object instead of
returning a new one.

The current virDomainMigrateFinish3 method signature attempts to
distinguish two types of errors, by allowing return with ret== 0,
but ddomain == NULL, to indicate a failure to start the guest.
This is flawed, because when ret == 0, there is no way for the
virErrorPtr details to be sent back to the client.

Change the signature of virDomainMigrateFinish3 so it simply
returns a virDomainPtr, in the same way as virDomainMigrateFinish2
The disk locking code will protect against the only possible
failure mode this doesn't account for (loosing conenctivity to
libvirtd after Finish3 starts the CPUs, but before the client
sees the reply for Finish3).

* src/driver.h, src/libvirt.c, src/libvirt_internal.h: Change
  virDomainMigrateFinish3 to return a virDomainPtr instead of int
* src/remote/remote_driver.c, src/remote/remote_protocol.x,
  daemon/remote.c, src/qemu/qemu_driver.c, src/qemu/qemu_migration.c:
  Update for API change

The virDomainMigratePerform3 currently has a single URI parameter
whose meaning varies. It is either

 - A QEMU migration URI (normal migration)
 - A libvirtd connection URI (peer2peer migration)

Unfortunately when using peer2peer migration, without also
using tunnelled migration, it is possible that both URIs are
required.

This adds a second URI parameter to the virDomainMigratePerform3
method, to cope with this scenario. Each parameter how has a fixed
meaning.

NB, there is no way to actually take advantage of this yet,
since virDomainMigrate/virDomainMigrateToURI do not have any
way to provide the 2 separate URIs

* daemon/remote.c, src/remote/remote_driver.c,
  src/remote/remote_protocol.x, src/remote_protocol-structs: Add
  the second URI parameter to perform3 message
* src/driver.h, src/libvirt.c, src/libvirt_internal.h: Add
  the second URI parameter to Perform3 method
* src/libvirt_internal.h, src/qemu/qemu_migration.c,
  src/qemu/qemu_migration.h: Update to handle URIs correctly

This extends the v3 migration protocol such that the
virDomainMigrateBegin3 and virDomainMigratePerform3
methods accept an application supplied XML config for
the target VM.

If the 'xmlin' parameter is NULL, then Begin3 uses the
current guest XML as normal. A driver implementing the
Begin3 method should either reject all non-NULL 'xmlin'
parameters, or strictly validate that the app supplied
XML does not change guest ABI.

The Perform3 method also needed the xmlin parameter to
cope with the Peer2Peer migration sequence.

NB it is not yet possible to use this capability since
neither of the public virDomainMigrate/virDomainMigrateToURI
methods have a way to pass in XML.

* daemon/remote.c, src/remote/remote_driver.c,
  src/remote/remote_protocol.x, src/remote_protocol-structs:
  Add 'remote_string xmlin' parameter to begin3/perform3
  RPC messages
* src/libvirt.c, src/driver.h, src/libvirt_internal.h: Add
  'const char *xmlin' parameter to Begin3/Perform3 methods
* src/qemu/qemu_driver.c, src/qemu/qemu_migration.c,
  src/qemu/qemu_migration.h: Pass xmlin parameter around
  migration methods

support for virDomainSetSchedulerParametersFlags of remote driver.

virStreamNew needs to dispatch the error that virGetStream reports
on failure.

remoteCreateClientStream can fail due to virStreamNew or due to
VIR_ALLOC. Report OOM error for VIR_ALLOC failure to report errors
in all error cases.

Remove OOM error reporting from remoteCreateClientStream callers.

* daemon/remote.c: Free mime string

* daemon/remote.c: Update screenshot dispatcher to follow
  standard practice

* src/remote/remote_protocol.x: Define wire protocol for migration
  protocol v3
* daemon/remote.c: Server side dispatch
* src/remote/remote_driver.c: Client side serialization
* src/remote/remote_protocol.c, src/remote/remote_protocol.h,
  daemon/remote_dispatch_args.h, daemon/remote_dispatch_prototypes.h,
  daemon/remote_dispatch_ret.h, daemon/remote_dispatch_table.h:
  Re-generate files
* src/remote_protocol-structs: Declare new ABIs

* src/remote/remote_protocol.x: Wire protocol definition
* daemon/remote.c: Daemon part
* src/remote/remote_driver.c: Client part
* src/remote_protocol-structs: Add structures

We were 31/73 on whether to translate; since less than 50% translated
and since VIR_INFO is less than VIR_WARN which also doesn't translate,
this makes sense.

* cfg.mk (sc_prohibit_gettext_markup): Add VIR_INFO, since it
falls between WARN and DEBUG.
* daemon/libvirtd.c (qemudDispatchSignalEvent, remoteCheckAccess)
(qemudDispatchServer): Adjust offenders.
* daemon/remote.c (remoteDispatchAuthPolkit): Likewise.
* src/network/bridge_driver.c (networkReloadIptablesRules)
(networkStartNetworkDaemon, networkShutdownNetworkDaemon)
(networkCreate, networkDefine, networkUndefine): Likewise.
* src/qemu/qemu_driver.c (qemudDomainDefine)
(qemudDomainUndefine): Likewise.
* src/storage/storage_driver.c (storagePoolCreate)
(storagePoolDefine, storagePoolUndefine, storagePoolStart)
(storagePoolDestroy, storagePoolDelete, storageVolumeCreateXML)
(storageVolumeCreateXMLFrom, storageVolumeDelete): Likewise.
* src/util/bridge.c (brProbeVnetHdr): Likewise.
* po/POTFILES.in: Drop src/util/bridge.c.

These VIR_XXXX0 APIs make us confused, use the non-0-suffix APIs instead.

How do these coversions works? The magic is using the gcc extension of ##.
When __VA_ARGS__ is empty, "##" will swallow the "," in "fmt," to
avoid compile error.

example: origin				after CPP
	high_level_api("%d", a_int)	low_level_api("%d", a_int)
	high_level_api("a  string")	low_level_api("a  string")

About 400 conversions.

8 special conversions:
VIR_XXXX0("") -> VIR_XXXX("msg") (avoid empty format) 2 conversions
VIR_XXXX0(string_literal_with_%) -> VIR_XXXX(%->%%) 0 conversions
VIR_XXXX0(non_string_literal) -> VIR_XXXX("%s", non_string_literal)
  (for security) 6 conversions
Signed-off-by: NLai Jiangshan <laijs@cn.fujitsu.com>

In preparation for removing generated files, it is necessary
to tell automake that the generated files must be distributed
but not directly compiled (since they are included into the
body of a larger .c file that is compiled).  Hence, even though
these files are code and not headers in the strict sense of
the word, it is easier to rename them to .h for automake's sake.

* daemon/remote_client_bodies.c: Rename to .h.
* daemon/qemu_client_bodies.c: Likewise.
* src/remote/remote_client_bodies.c: Likewise.
* src/remote/qemu_client_bodies.c: Likewise.
* daemon/Makefile.am (remote_dispatch_bodies.c)
(qemu_dispatch_bodies.c): Rename to .h.
(remote.c, EXTRA_DIST): Reflect rename.
* daemon/remote.c: Likewise.
* daemon/remote_generator.pl: Likewise.
* src/Makefile.am (remote/remote_driver.c): Likewise.
* src/remote/remote_driver.c: Likewise.
* po/POTFILES.in: Likewise.
* cfg.mk (exclude_file_name_regexp--sc_require_config_h)
(exclude_file_name_regexp--sc_require_config_h_first)
(exclude_file_name_regexp--sc_prohibit_empty_lines_at_EOF):
Likewise.

Once again rename members in the XDR definitions to avoid special case
code in the generator.

They require additional special cases.

Avoids special case handling in the remote generator.

This covers functions that return single wrapped objects and don't
involve complexer code in the body.

Again this will simplify the generator, due to less special case handling.

This simplifies the remote protocol code generator.

Also rename 'ret' to 'result' to resolve a naming conflict in the
generator.

This patch just covers the simple functions without explicit return
values. There is more to be handled.

The generator collects the members of the XDR argument structs and uses
this information to generate the function bodies.

Exclude the generated files from offending syntax-checks.

Suggested by Richard W.M. Jones

Clang found three instances of uninitialized use of nparams in
the cleanup path.  Unfortunately, one is a false positive: clang
couldn't see that ret->params.params_val is guaranteed to be
NULL unless allocated within a function, and that nparams is
guaranteed to be assigned prior to the allocation; hoisting the
assignment to nparams to be earlier in the function shuts up
that false positive.  But two of the reports also happened to
highlight a real bug - the error path can dereference NULL.

Regression introduced in commit 158ba873.

* daemon/remote.c (remoteDispatchDomainGetMemoryParameters)
(remoteDispatchDomainGetBlkioParameters): Don't clear fields if
array was not allocated.
(remoteDispatchDomainGetSchedulerParameters): Initialize nparams
earlier.