Imported Upstream version 1.1.91 upstream/1.1.91

4 files changed, 85 insertions, 17 deletions

diff --git a/introspection/all.xml.in b/introspection/all.xml.in
index 29cccdb5..273c0fda 100644
--- a/introspection/all.xml.in
+++ b/introspection/all.xml.in
@@ -6,7 +6,7 @@
 <tp:version>@VERSION@</tp:version>
 
 
-<tp:copyright>Copyright (C) 2008 - 2011 Red Hat, Inc.</tp:copyright>
+<tp:copyright>Copyright (C) 2008 - 2016 Red Hat, Inc.</tp:copyright>
 <tp:copyright>Copyright (C) 2008 - 2009 Novell, Inc.</tp:copyright>
 
 <tp:license xmlns="http://www.w3.org/1999/xhtml">
@@ -28,19 +28,24 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
 <xi:include href="nm-manager.xml"/>
 <xi:include href="nm-access-point.xml"/>
 <xi:include href="nm-device.xml"/>
+<xi:include href="nm-device-adsl.xml"/>
+<xi:include href="nm-device-bond.xml"/>
+<xi:include href="nm-device-bridge.xml"/>
+<xi:include href="nm-device-bt.xml"/>
 <xi:include href="nm-device-ethernet.xml"/>
-<xi:include href="nm-device-wifi.xml"/>
+<xi:include href="nm-device-generic.xml"/>
+<xi:include href="nm-device-infiniband.xml"/>
+<xi:include href="nm-device-ip-tunnel.xml"/>
+<xi:include href="nm-device-macvlan.xml"/>
 <xi:include href="nm-device-modem.xml"/>
-<xi:include href="nm-device-bt.xml"/>
 <xi:include href="nm-device-olpc-mesh.xml"/>
-<xi:include href="nm-device-wimax.xml"/>
-<xi:include href="nm-device-infiniband.xml"/>
-<xi:include href="nm-device-bond.xml"/>
-<xi:include href="nm-device-bridge.xml"/>
 <xi:include href="nm-device-team.xml"/>
-<xi:include href="nm-device-generic.xml"/>
+<xi:include href="nm-device-tun.xml"/>
+<xi:include href="nm-device-veth.xml"/>
 <xi:include href="nm-device-vlan.xml"/>
-<xi:include href="nm-device-adsl.xml"/>
+<xi:include href="nm-device-vxlan.xml"/>
+<xi:include href="nm-device-wifi.xml"/>
+<xi:include href="nm-device-wimax.xml"/>
 <xi:include href="nm-wimax-nsp.xml"/>
 <xi:include href="nm-ip4-config.xml"/>
 <xi:include href="nm-ip6-config.xml"/>
diff --git a/introspection/nm-active-connection.xml b/introspection/nm-active-connection.xml
index 4d5d15a1..203437b7 100644
--- a/introspection/nm-active-connection.xml
+++ b/introspection/nm-active-connection.xml
@@ -9,6 +9,15 @@
       The Connection.Active object tracks the life-cycle of the connection
       attempt and if successful indicates whether the connected network is the
       "default" or preferred network for access.
+      NetworkManager has the concept of connections, which can be thought of as
+      settings, a profile or a configuration that can be applied on a networking
+      device.
+      Such settings-connections are exposed as D-Bus object and the active-connection
+      expresses this relationship between device and settings-connection.
+      At any time a settings-connection can only be activated on one device and vice
+      versa. However, during activation and deactivation multiple active-connections
+      can reference the same device or settings-connection as they are waiting to
+      be activated or to be deactivated.
     </tp:docstring>
 
     <property name="Connection" type="o" access="read">
diff --git a/introspection/nm-device-vxlan.xml b/introspection/nm-device-vxlan.xml
index 4dd254a2..97c517fb 100644
--- a/introspection/nm-device-vxlan.xml
+++ b/introspection/nm-device-vxlan.xml
@@ -58,8 +58,8 @@
 
     <property name="Ageing" type="u" access="read">
       <tp:docstring>
-        The interval at which the kernel purges stale cached addresses
-	(in kernel jiffies, ie, centiseconds).
+        The interval in seconds at which the kernel purges stale
+        cached addresses.
       </tp:docstring>
     </property>
 
diff --git a/introspection/nm-device.xml b/introspection/nm-device.xml
index 2930cf06..f1033c73 100644
--- a/introspection/nm-device.xml
+++ b/introspection/nm-device.xml
@@ -172,8 +172,18 @@
     <method name="Reapply">
       <arg name="connection" type="a{sa{sv}}" direction="in">
         <tp:docstring>
-          The effective connection settings and properties to use. If empty, the connection
-          settings from the connection that is active on the device will be used.
+          The optional connection settings that will be reapplied on the device. If empty, the
+          currently active settings-connection will be used. The connection cannot arbitrarly
+          differ from the current applied-connection otherwise the call will fail.
+          Only certain changes are supported, like adding or removing IP addresses.
+        </tp:docstring>
+      </arg>
+      <arg name="version_id" type="t" direction="in">
+        <tp:docstring>
+          If non-zero, the current version id of the applied-connection must match.
+          The current version id can be retrieved via GetAppliedConnection.
+          This optional argument allows to catch concurrent modifications between
+          the GetAppliedConnection call and Reapply.
         </tp:docstring>
       </arg>
       <arg name="flags" type="u" direction="in">
@@ -183,10 +193,54 @@
         </tp:docstring>
       </arg>
       <tp:docstring>
-        Attempts to update the configuration of a device without deactivating it.
-        You can either modify the configuration by passing the desired setup via "connection"
-        argument or just omit the argument to bring it in sync with the connection that
-        has been activated but could have been modified  since.
+        Attempts to update the configuration of a device without deactivating it. NetworkManager
+        has the concept of connections, which are profiles that contain the configuration for
+        a networking device. Those connections are exposed via D-Bus as individual objects
+        that can be created, modified and deleted. When activating such a settings-connection
+        on a device, the settings-connection is cloned to become an applied-connection and used to
+        configure the device (see GetAppliedConnection). Subsequent modification of the
+        settings-connection don't propagate automatically to the device's applied-connection
+        (with exception of the firewall-zone and the metered property). For the changes to take
+        effect, you can either re-activate the settings-connection, or call Reapply.
+        The Reapply call allows you to directly update the applied-connection and reconfigure
+        the device.
+        Reapply can also be useful if the currently applied-connection is equal to the connection
+        that is about to be reapplied. This allows to reconfigure the device and revert external
+        changes like removing or adding an IP address (which NetworkManager doesn't revert
+        automatically because it is assumed that the user made these changes intentionally outside
+        of NetworkManager).
+        Reapply can make the applied-connection different from the settings-connection,
+        just like updating the settings-connection can make them different.
+      </tp:docstring>
+    </method>
+
+    <method name="GetAppliedConnection">
+      <arg name="flags" type="u" direction="in">
+        <tp:docstring>
+          Flags which would modify the behavior of the GetAppliedConnection call.
+          There are no flags defined currently and the users should use the value of 0.
+        </tp:docstring>
+      </arg>
+      <arg name="connection" type="a{sa{sv}}" direction="out">
+        <tp:docstring>
+            The effective connection settings that the connection has currently applied.
+        </tp:docstring>
+      </arg>
+      <arg name="version_id" type="t" direction="out">
+        <tp:docstring>
+            The version-id of the currently applied connection. This can be specified during
+            Reapply to avoid races where you first fetch the applied connection, modify it
+            and try to reapply it. If the applied connection is modified in the meantime, the
+            version_id gets incremented and Reapply will fail.
+        </tp:docstring>
+      </arg>
+      <tp:docstring>
+        Get the currently applied connection on the device. This is a snapshot of the last activated
+        connection on the device, that is the configuration that is currently applied on the device.
+        Usually this is the same as GetSettings of the referenced settings connection. However, it
+        can differ if the settings connection was subsequently modified or the applied connection was
+        modified by Reapply. The applied connection is set when activating a device or when calling
+        Reapply.
       </tp:docstring>
     </method>