- 26 4月, 2016 14 次提交
-
-
由 John Ferlan 提交于
Change 'ephemeral' to 'isephemeral' and 'private' to 'isprivate' since both are bools.
-
由 John Ferlan 提交于
Introduce the final accessor's to _virSecretObject data and move the structure from virsecretobj.h to virsecretobj.c The virSecretObjSetValue logic will handle setting both the secret value and the value_size. Some slight adjustments to the error path over what was in secretSetValue were made. Additionally, a slight logic change in secretGetValue where we'll check for the internalFlags and error out before checking for and erroring out for a NULL secret->value. That way, it won't be obvious to anyone that the secret value wasn't set rather they'll just know they cannot get the secret value since it's private.
-
由 John Ferlan 提交于
Introduce fetch and set accessor to the secretObj->def field for usage by the driver to avoid the driver needing to know the format of virSecretObj
-
由 John Ferlan 提交于
Move and rename the secretRewriteFile, secretSaveDef, and secretSaveValue from secret_driver to virsecretobj Need to make some slight adjustments since the secretSave* functions called secretEnsureDirectory, but otherwise mostly just a move of code.
-
由 John Ferlan 提交于
Move and rename secretDeleteSaved from secret_driver into virsecretobj and split it up into two parts since there is error path code that looks to just delete the secret data file
-
由 John Ferlan 提交于
Move to secret_conf.c and rename to virSecretLoadAllConfigs. Also includes moving/renaming the supporting virSecretLoad, virSecretLoadValue, and virSecretLoadValidateUUID.
-
由 John Ferlan 提交于
This patch replaces most of the guts of secret_driver.c with recently added secret_conf.c APIs in order manage secret lists and objects using the hashed virSecretObjList* lookup API's.
-
由 John Ferlan 提交于
Add function to return counted listed of uuids to from the hashed secrets object list. This will replace the guts of secretConnectListSecrets.
-
由 John Ferlan 提交于
Add function to return a "match" filtered list of secret objects. This function replaces the guts of secretConnectListAllSecrets. Need to also move and make global virSecretUsageIDForDef since it'll be used by both secret_driver.c and secret_conf.c
-
由 John Ferlan 提交于
Add function to count the hashed secret obj list with filters. This will replace the guts of secret_driver's secretConnectNumOfSecrets.
-
由 John Ferlan 提交于
Add the functions to add/remove elements from the hashed secret obj list. These will replace secret_driver functions secretAssignDef and secretObjRemove. The virSecretObjListAddLocked will perform the necessary lookups and decide whether to replace an existing hash entry or create a new one. This includes setting up the configPath and base64Path as well as being able to support the caller's need to restore from a previous definition in case something goes wrong in the caller.
-
由 John Ferlan 提交于
Move the driver specific secretUsageIDForDef into secret_conf.c. It could be more of a general purpose API.
-
由 John Ferlan 提交于
New API's including unlocked and Locked versions in order to be able to use in either manner. Support for searching hash object lists instead of linked lists will replace existing secret_driver functions secretFindByUUID and secretFindByUsage
-
由 John Ferlan 提交于
Move virSecretObj from secret_driver.c to virsecretobj.h To support being able to create a hashed secrets list, move the virSecretObj to virsecretobj.h so that the code can at least find the definition. This should be a temporary situation while the virsecretobj.c code is patched in order to support a hashed secret object while still having the linked list support in secret_driver.c. Eventually, the goal is to move the virSecretObj into virsecretobj.c, although it is notable that the existing model from which virSecretObj was derived has virDomainObj in src/conf/domain_conf.h and virNetworkObj in src/conf/network_conf.h, so virSecretObj wouldn't be unique if it were to remain in virsecretobj.h Still adding accessors to fetch and store hashed object data will be the end goal. Add definitions and infrastucture in virsecretobj.c to create and handle a hashed virSecretObj and virSecretObjList including the class, object, lock setup, and disposal API's. Nothing will call these yet. This infrastructure will replace the forward linked list logic within the secret_driver, eventually.
-
- 21 4月, 2016 13 次提交
-
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
Additionally avoid initializing it after being calloced.
-
由 Peter Krempa 提交于
Additionally switch to using a common temp variable for the xml elements.
-
由 Peter Krempa 提交于
Use a single temporary variable instead shortening the code.
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
Rather than checking individual fields in dubious places extract them to a central point.
-
- 20 4月, 2016 4 次提交
-
-
由 Cole Robinson 提交于
VIR_ERR_NO_SUPPORT maps to the error string this function is not supported by the connection driver and is largely only used for when a driver doesn't have any implementation for a public API. So its usage with invalid net-update requests is a bit out of place. Instead use VIR_ERR_OPERATION_UNSUPPORTED which maps to: Operation not supported And is what qemu's hotplug routines use in similar scenarios
-
由 Andrea Bolognani 提交于
Add information about GIC capabilities to virDomainCaps and update the formatter to include them in the XML output.
-
由 Andrea Bolognani 提交于
The struct contains a single boolean field, 'supported': the meaning of this field is too generic to be limited to devices only, and in fact it's already being used for other things like loaders and OSs. Instead of trying to come up with a more generic name just get rid of the struct altogether.
-
由 Laine Stump 提交于
Prior to this patch we didn't make any attempt to prevent two entries in the array of interfaces/PCI devices from pointing to the same device. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1002423
-
- 19 4月, 2016 1 次提交
-
-
由 Martin Kletzander 提交于
So in glibc-2.23 sys/sysmacros.h is no longer included from sys/types.h and we don't build because of the usage of major/minor/makedev macros. Autoconf already has AC_HEADER_MAJOR macro that check where exactly these functions/macros are defined, so let's use that. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 15 4月, 2016 8 次提交
-
-
由 Olga Krishtal 提交于
Ploop image consists of directory with two files: ploop image itself, called root.hds and DiskDescriptor.xml that contains information about ploop device: https://openvz.org/Ploop/format. Such volume are difficult to manipulate in terms of existing volume types because they are neither a single files nor a directory. This patch introduces new volume type - ploop. This volume type is used by ploop volume's exclusively. Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
-
由 Laine Stump 提交于
This controller provides a single PCIe port on a new root. It is similar to pci-expander-bus, intended to provide a bus that can be associated with a guest-identifiable NUMA node, but is for machinetypes with PCIe rather than PCI (e.g. q35-based machinetypes). Aside from PCIe vs. PCI, the other main difference is that a pci-expander-bus has a companion pci-bridge that is automatically attached along with it, but pcie-expander-bus has only a single port, and that port will only connect to a pcie-root-port, or to a pcie-switch-upstream-port. In order for the bus to be of any use in the guest, it must have either a pcie-root-port or a pcie-switch-upstream-port attached (and one or more pcie-switch-downstream-ports attached to the pcie-switch-upstream-port).
-
由 Laine Stump 提交于
This is a standard PCI root bus (not a bridge) that can be added to a 440fx-based domain. Although it uses a PCI slot, this is *not* how it is connected into the PCI bus hierarchy, but is only used for control. Each pci-expander-bus provides 32 slots (0-31) that can accept hotplug of standard PCI devices. The usefulness of pci-expander-bus relative to a pci-bridge is that the NUMA node of the bus can be specified with the <node> subelement of <target>. This gives guest-side visibility to the NUMA node of attached devices (presuming that management apps only assign a device to a bus that has a NUMA node number matching the node number of the device on the host). Each pci-expander-bus also has a "busNr" attribute. The expander-bus itself will take the busNr specified, and all buses that are connected to this bus (including the pci-bridge that is automatically added to any expander bus of model "pxb" (see the next commit)) will use busNr+1, busNr+2, etc, and the pci-root (or the expander-bus with next lower busNr) will use bus numbers lower than busNr.
-
由 Laine Stump 提交于
There are two places in qemu_domain_address.c where we have a switch statement to convert PCI controller models (VIR_DOMAIN_CONTROLLER_MODEL_PCI*) into the connection type flag that is matched when looking for an upstream connection for that model of controller (VIR_PCI_CONNECT_TYPE_*). This patch makes a utility function in conf/domain_addr.c to do that, so that when a new PCI controller is added, we only need to add the new model-->connect-type in a single place.
-
由 Laine Stump 提交于
The flags used to determine which devices could be plugged into which controllers were quite confusing, as they tried to create classes of connections, then put particular devices into possibly multiple classes, while sometimes setting multiple flags for the controllers themselves. The attempt to have a single flag indicate, e.g. that a root-port or a switch-downstream-port could connect was not only confusing, it was leading to a situation where it would be impossible to specify exactly the right combinations for a new controller. The solution is for the VIR_PCI_CONNECT_TYPE_* flags to have a 1:1 correspondence with each type of PCI controller, plus a flag for a PCI endpoint device and another for a PCIe endpoint device (the only exception to this is that pci-bridge and pcie-expander-bus controllers have their upstream connection classified as VIR_PCI_CONNECT_TYPE_PCI_DEVICE since they can be plugged into *exactly* the same ports as any endpoint device). Each device then has a single flag for connect type (plus the HOTPLUG flag if that device can e hotplugged), and each controller sets the CONNECT bits for all controllers that can be plugged into it, as well as for either type of endpoint device that can be plugged in (and the HOTPLUG flag if it can accept hotplugged devices). With this change, it is *slightly* easier to understand the matching of connections (as long as you remember that the flag for a device/upstream-facing connection of a controller is the same as that device's type, while the flags for a controller's downstream connections is the OR of all device types that can be plugged into that controller). More importantly, it will be possible to correctly specify what can be plugged into a pcie-switch-expander-bus, when support for it is added.
-
由 Laine Stump 提交于
When support for dmi-to-pci-bridge was added, it was assumed that, just as with the pci-root bus, slot 0 was reserved. This is not the case - it can be used to connect a device just like any other slot, so remove the restriction and update the test cases that auto-assign an address on a dmi-to-pci-bridge.
-
由 Laine Stump 提交于
Every other maxSlot was either set to 0 or to VIR_PCI_ADDRESS_SLOT_LAST, but this one was for some reason set to the literal value 31 (which is the same as VIR_PCI_ADDRESS_SLOT_LAST). This makes them all consistent.
-