After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 747465 - [review] lr/veth-no-external-up: lift the external IFF_UP requirement for veths
[review] lr/veth-no-external-up: lift the external IFF_UP requirement for veths
Status: RESOLVED FIXED
Product: NetworkManager
Classification: Platform
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2015-04-07 16:14 UTC by Lubomir Rintel
Modified: 2015-04-13 11:56 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
types: make veth non-software device (1.02 KB, patch)
2015-04-07 16:14 UTC, Lubomir Rintel
none Details | Review

Description Lubomir Rintel 2015-04-07 16:14:59 UTC
Created attachment 301082 [details] [review]
types: make veth non-software device

For all practical purposes, the virtual ethernet should be treated as ordinary
ethernet. It should not wait until being upped externally inside a container.

Outside the container the udev rule still prevents veths from being managed.
---
 src/nm-types.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Comment 1 Thomas Haller 2015-04-07 16:54:01 UTC
this affects what nm_platform_link_is_software() returns, which affects priv->is_software of a device.

Also, it affects the exposed capabilities (NM_DEVICE_CAP_IS_SOFTWARE).


It seems that a veth should still have the capability NM_DEVICE_CAP_IS_SOFTWARE. Which part of "veth being is_software" causes a problem that this patch fixes?


I think the commit message should explain the actual consequences (beyond: a veth is no longer veth) and why we want that change.
Comment 2 Thomas Haller 2015-04-07 16:54:25 UTC
a veth is no longer veth
                    ^^^^ is_software
Comment 3 Lubomir Rintel 2015-04-08 17:12:31 UTC
Reworked as discussed with Thomas in person.

9fed01e device: turn off "unmanaged unless IFF_UP externally" for veth
d8ffe95 device: move the decision whether to wait for IFF_UP a virtual function
Comment 4 Thomas Haller 2015-04-08 19:33:31 UTC
(In reply to Lubomir Rintel from comment #3)
> Reworked as discussed with Thomas in person.
> 
> 9fed01e device: turn off "unmanaged unless IFF_UP externally" for veth
> d8ffe95 device: move the decision whether to wait for IFF_UP a virtual
> function

looks good, except that the name "manage_on_external_up" sounds to me like having the opposite meaning.

How about "can_unmanaged_external_down()"?


+     * didn't create it. */
+        return FALSE;
+}
^^^^^ whitespace
Comment 5 Lubomir Rintel 2015-04-09 09:16:54 UTC
lr/veth-no-external-up updated
Comment 6 Beniamino Galvani 2015-04-13 09:29:02 UTC
-	if (is_software_external (self)) {
+	if (NM_DEVICE_GET_CLASS (self)->can_unmanaged_external_down (self)) {

Maybe can be replaced with: "klass->can_unmanaged_external_down (self))" ?
Anyway, looks good to me.
Comment 7 Lubomir Rintel 2015-04-13 11:56:28 UTC
(In reply to Beniamino Galvani from comment #6)
> -	if (is_software_external (self)) {
> +	if (NM_DEVICE_GET_CLASS (self)->can_unmanaged_external_down (self)) {
> 
> Maybe can be replaced with: "klass->can_unmanaged_external_down (self))" ?

No strong opinion here. However, I think that we usually assign the macro expansion to a variable when we use it multiple times which is not the case here; I'm leaving it as it is.

> Anyway, looks good to me.

Thank you. Merged:

0b9a4cd device: merge branch 'lr/veth-no-external-up'
bcc79cc device: turn off "unmanaged unless IFF_UP externally" for veth
adb6e9a device: move the decision whether to wait for IFF_UP a virtual function