The virXMLPropStringLimit is an equivalent of virXPathStringLimit
which should be preferred if you already have a XML dom node or
if you need to parse more than one property.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

In preparation to privatize the virNetworkObj - create an accessor function
to get the current @persistent value.  Also change the value to a bool rather
than an unsigned int (since that's how it's generated anyway).
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

In order to privatize the virNetworkObj create accessors in virnetworkobj
in order to handle the get/set of the active value.

Also rather than an unsigned int, convert it to a boolean to match other
drivers representation and the reality of what it is.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

In preparation for privatizing the virNetworkObj structure, create
accessors for the obj->autostart.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

In preparation for making the object private, create a couple of API's
to get the obj->def & obj->newDef and set the obj->def.

While altering networkxml2conftest.c to use the virNetworkObjSetDef
API, fix the name of the variable from @dev to @def
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

In preparation for making the object private, create a couple of API's
to get/set the obj->floor_sum.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

In preparation for privatizing virNetworkObj, create accessor function to
fetch the @classIdMap.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

In preparation for making the object private, create/use a couple of API's
to get/set the obj->dnsmasqPid and obj->radvdPid.

NB: Since the pid's can sometimes changed based on intervening functions,
be sure to always fetch the latest value.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

In preparation for having a private virNetworkObj - let's create/move some
API's that handle the obj->macmap. The API's will be renamed to have a
virNetworkObj prefix to follow conventions and the arguments slightly
modified to accept what's necessary to complete their task.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Move networkMacMgrFileName into src/util/virmacmap.c and rename to
virMacMapFileName. We're about to move some more MacMgr processing
files into virnetworkobj and it doesn't make sense to have this helper
in the driver or in virnetworkobj.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Rather than overload virObjectUnlock as commit id '77f4593b' has
done, create a separate virObjectRWUnlock API that will force the
consumers to make the proper decision regarding unlocking the
RWLock's. Similar to the RWLockRead and RWLockWrite, use the
virObjectGetRWLockableObj helper. This restores the virObjectUnlock
code to using the virObjectGetLockableObj.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Instead of making virObjectLock be the entry point for two
different types of locks, let's create a virObjectRWLockWrite API
which will only handle the virObjectRWLockableClass objects.

Use the new virObjectRWLockWrite for the virdomainobjlist code
in order to handle the Add, Remove, Rename, and Load operations
that need to be very synchronous.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Since the class it represents is based on virObjectRWLockableClass
and in order to make sure we differentiate just in case anyone somehow
believes they could use virObjectLockRead for a virObjectLockableClass,
let's rename the API to use the RW in the name. Besides the RW locks
refer to pthread_rwlock_{init|rdlock|wrlock|unlock|destroy} while the
other locks refer to pthread_mutex_{init|lock|unlock|destroy}.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

It doesn't access anything from conf/ and ti will be needed to use
from other util/ places.  This split makes the separation clearer.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

On Linux each network device *can* (but not necessarily *does*) have
an attribute called phys_port_id which can be read from the file of
that name in the netdev's sysfs directory. The examples I've seen have
been a many-digit hexadecimal number (as an ASCII string).

This value can be useful when a single PCI device is associated with
multiple netdevs (e.g a dual port Mellanox SR-IOV NIC - this card has
a single PCI Physical Function (PF), and that PF has two netdevs
associated with it (the "net" subdirectory of the PF in sysfs has two
links rather than the usual single link to a netdev directory). Each
of the PF netdevs has a different phys_port_id. The Virtual Functions
(VF) are similar - the PF (a PCI device) has "n" VFs (also each of
these is a PCI device), each VF has two netdevs, and each of the VF
netdevs points back to the VF PCI device (with the "device" entry in
its sysfs directory) as well as having a phys_port_id matching the PF
netdev it is associated with.

virNetDevGetPhysPortID() simply attempts to read the phys_port_id for
the given netdev and return it to the caller. If this particular
netdev driver doesn't support phys_port_id, it returns NULL (*not* a
NULL-terminated string, but a NULL pointer) but still counts it as a
success.

Rewrite virConfReadMem to take a null-terminated string.
All the callers were calling strlen on it anyway.

Export the function from the util module so that dynamic linking can
override it.

These functions were made exportable back in 3aa3e072 when I was
splitting network code into parsing and list management parts.
Since then the split is finished now and these two functions do
not need to be exported anymore.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Split out the worker loop into a separate function and export it.
Reviewed-by: NEric Blake <eblake@redhat.com>

The new virFileCache will nicely handle the caching logic for any data
that we would like to cache.  For each type of data we will just need
to implement few handlers that will take care of creating, validating,
loading and saving the cached data.

The cached data must be an instance of virObject.

Currently we cache QEMU capabilities which will start using
virFileCache.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

It is more related to a domain as we might use it even when there is
no systemd and it does not use any dbus/systemd functions.  In order
not to use code from conf/ in util/ pass machineName in cgroups code
as a parameter.  That also fixes a leak of machineName in the lxc
driver and cleans up and de-duplicates some code.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

This reverts commit 328bd244.

As it turns out, this is not portable and very Linux & glibc
specific. Worse, this may lead to not starving writers on Linux
but everywhere else. Revert this and if the starvation occurs
resolve it.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>

The original name didn't hint at the fact that PHBs are
a pSeries-specific concept.
Suggested-by: NPeter Krempa <pkrempa@redhat.com>
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Up until now we only had virObjectLockable which uses mutexes for
mutually excluding each other in critical section. Well, this is
not enough. Future work will require RW locks so we might as well
have virObjectRWLockable which is introduced here.

Moreover, polymorphism is introduced to our code for the first
time. Yay! More specifically, virObjectLock will grab a write
lock, virObjectLockRead will grab a read lock then (what a
surprise right?). This has great advantage that an object can be
made derived from virObjectRWLockable in a single line and still
continue functioning properly (mutexes can be viewed as grabbing
write locks only). Then just those critical sections that can
grab a read lock need fixing. Therefore the resulting change is
going to be way smaller.

In order to avoid writer starvation, the object initializes RW
lock that prefers writers.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

We already have virRWLockInit. But this uses pthread defaults
which prefer reader to initialize the RW lock. This may lead to
writer starvation. Therefore we need to have the counterpart that
prefers writers. Now, according to the
pthread_rwlockattr_setkind_np() man page setting
PTHREAD_RWLOCK_PREFER_WRITER_NP attribute is no-op. Therefore we
need to use PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP
attribute. So much for good enum value names.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Move it to virstring.c and improve it to parse and validate ports. New
name is virStringParsePort.

The virDomainDeviceInfo struct is defined in device_conf,
so generic functions that operate on it should also be
defined there rather than in domain_conf.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

All other virDomain*Def follow this naming convention for
their allocation function.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Since virBitmapSubtract is unused modify it to perform bitmap
intersection.

A new function virNetDevOpenvswitchUpdateVlan has been created to instruct
OVS of the changes. qemuDomainChangeNet has been modified to handle the
update of the VLAN configuration for a running guest and rely on
virNetDevOpenvswitchUpdateVlan to do the actual update if needed.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Now that we have a bit more control, let's convert our object into
a lockable object and let that magic handle the create and lock/unlock.

This also involves creating a virNodeDeviceEndAPI in order to handle
the object cleanup for API's that use the Add or Find API's in order
to get a locked/reffed object. The EndAPI will unlock and unref the
object returning NULL to indicate to the caller to not use the obj.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

In an overall effort to privatize access to virNodeDeviceObj and
virNodeDeviceObjList into the virnodedeviceobj module, move the
object list parsing from node_device_driver and replace with a
call to a virnodedeviceobj helper. This follows other similar
APIs/helpers which peruse the object list looking for some specific
data in order to get/return an @device (virNodeDevice) object to
the caller.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

We're about to move the call to nodeDeviceSysfsGetSCSIHostCaps from
node_device_driver into virnodedeviceobj, so move the guts of the code
from the driver specific node_device_linux_sysfs into its own API
since virnodedeviceobj cannot callback into the driver.

Nothing in the code deals with sysfs anyway, as that's hidden by the
various virSCSIHost* and virVHBA* utility function calls.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Ensure that any function that walks the node device object list is prefixed
by virNodeDeviceObjList.

Also, modify the @filter param name for virNodeDeviceObjListExport to
be @aclfilter.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

In preparation to make things private, make the ->devs be pointers to a
virNodeDeviceObjList and then manage everything inside virnodedeviceobj
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Rather than passing the object to be removed by reference, pass by value
and then let the caller decide whether or not the object should be free'd
and how to handle the logic afterwards. This includes free'ing the object
and/or setting the local variable to NULL to prevent subsequent unexpected
usage (via something like virNodeDeviceObjRemove in testNodeDeviceDestroy).

For now this function will just handle the remove of the object from the
list for which it was placed during virNodeDeviceObjAssignDef.

This essentially reverts logic from commit id '61148074' that free'd the
device entry on list, set *dev = NULL and returned. Thus fixing a bug in
node_device_hal.c/dev_refresh() which would never call dev_create(udi)
since @dev would have been set to NULL.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Create a common API to handle the instantiation path filter lookup.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

pSeries guests will soon need the new information; luckily,
we can figure it out automatically most of the time, so
users won't have to worry about it.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

There are no external users.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>