Move the virObjectRef in virNetworkObjAssignDefLocked to after
the virHashAddEntry to make it "clearer" why the @ref is being
incremented. Upon return from the ObjNew we will have 1 ref on
the object already, adding it to the hash table requires the
increment.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Forces callers to use the virNetworkObjEndAPI properly.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Consistently use @obj for a virNetworkObjPtr.
Signed-off-by: NJohn Ferlan <jferlan@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>

Change the variable name to be a bit more descriptive and less confusing
when used with the data.network.actual->class_id.
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>

Since we can only ever have one reference to obj->macmap, rather
than only clearing obj->macmap during virNetworkObjUnrefMacMap
(e.g. virtual network from networkShutdownNetwork), let's just
unconditionally clear the obj->macmap to ensure that some future
change that created it's own reference to obj->macmap wouldn't
have that reference disappear if virNetworkObjDispose got called.
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>

Use @obj for a virNetworkObjPtr

Use @net for a virNetworkPtr
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Alter prototypes to utilize some more recent guidelines.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Since its introduction in f6134117 it was never
implemented nor there are plans to implement it. Drop it.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

If an environment specific _tls_x509_cert_dir is provided, then
do not VIR_STRDUP the defaultTLSx509secretUUID as that would be
for the "default" environment and not the vnc, spice, chardev, or
migrate environments. If the environment needs a secret to decode
it's certificate, then it must provide the secret. If the secrets
happen to be the same, then configuration would use the same UUID
as the default (but we cannot assume that nor can we assume that
the secret would be necessary).

Rather than assuming that what's passed to virObject{Ref|Unref}
would be a virObjectPtr as long as it's not NULL, let's do the
similar checks virObjectIsClass in order to prevent a possible
increment or decrement to some field at the obj->u.s.refs offset.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

The virObjectIsClass API has only ever checked object validity
based on if the @obj is not NULL and it was derived from some class.
While this has worked well in general, there is one additional
check that could be made prior to calling virClassIsDerivedFrom
which loops through the classes checking the magic number against
the klass expected magic number.

If by chance a non virObject is passed, rather than assuming the
void * @obj is a _virObject and thus offsetting to obj->klass,
obj->magic, and obj->parent, let's check that the void * @obj
has at least the "base part" of the magic number in the right
place and generate a more specific VIR_WARN message if not.

There are many consumers to virObjectIsClass, include the locking
primitives virObject{Lock|Unlock}, virObjectRWLock{Read|Write},
and virObjectRWUnlock. For those callers, the locking call will
not fail, but it also will not attempt a virMutex* call which
will "most likely" fail since the &obj->lock is used.

In order to avoid some possible future wrap on the 0xCAFExxxx
value, add a check during initialization that some new class
won't cause the wrap. Should be good for a few years at least!

It is still left up to the caller to handle the failed API calls
just as it would be if it passed a NULL opaque pointer anyobj.

If virObjectIsClass fails "internally" to virobject.c, create a
macro to generate the VIR_WARN describing what the problem is.
Also improve the checks and message a bit to indicate which was
the failure - whether the obj was NULL or just not the right class
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>

Introduce a helper to handle the error path more cleanly. The same
as virObjectGetLockableObj in order to essentially follow the original
logic of commit 'b545f65d' to ensure that the input argument at least
has some validity before using.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Now that virObjectRWLockWrite exists to handle the virObjectRWLockable
objects, let's restore virObjectLock to only handle virObjectLockable
class locks. There still exists the possibility that the input @anyobj
isn't a valid object and the resource isn't truly locked, but that
also exists before commit id '77f4593b'.

This also restores some logic that commit id '77f4593b' removed
with respect to a common code path that commit id '10c2bb2b' had
introduced as virObjectGetLockableObj. This code path merely does
the same checks as the original virObjectLock commit 'b545f65d',
but in callable/reusable helper to ensure the @obj at least has
some validity before using.
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>

The correct lock order is:

  nwfilter driver lock (not used in this code path)
  nwfilter update lock
  virt driver lock (not used in this code path)
  domain object lock

but the current code have this order:

  domain object lock
  nwfilter update lock
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

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

XPath is good for random search of elements, not for accessing
attributes of one node.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

XPath is good for random search of elements, not for accessing
attributes of one node.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

XPath is good for random search of elements, not for accessing
attributes of one node.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

XPath is good for random search of elements, not for accessing
attributes of one node.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

XPath is good for random search of elements, not for accessing
attributes of one node.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

The @remaining variable is leftover from old code and it's not
used anymore.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

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

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

This way later patches can add another structures with virResctrl
prefix without the meaning being even more confusing than it needs to
be.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

That means that returning negative values means error and non-negative
values differ in meaning, but are all successful.
Signed-off-by: NMartin Kletzander <mkletzan@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>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>