On 03/27/2014 02:55 PM, Justin Brown wrote: > After quite a bit of work to get bridging setup correctly on VLAN > interfaces, I'm wondering if we can remove some keys that seem > unnecessary.
So, one thing to understand is that (a) the keyfile plugin is mostly a one-to-one mapping from NMSetting subclass properties, and (b) the NMSetting subclass properties have to maintain API stability. So some of what you're seeing is just accumulated cruft. In some cases, we could fix the keyfile plugin to allow some simplifications. > The [connection] section in keyfiles is confusing. It's clearly about > identification and general information (id, uuid, permissions, > autoconnect, zone, etc.). It's called "connection" because it corresponds to NMSettingConnection. But that mostly corresponds to the "General" page in nm-connection-editor, and perhaps should be called that. > The problem with type is that it's inferred by the rest of the > configuration. For example, if I have a VLAN interface, I am required > to have a [vlan] section. Right, but if you have an ethernet interface, you *aren't* required to have an [ethernet] section, because none of the properties on NMSettingWired are mandatory-to-set. The value of type could, perhaps, be inferred when a type-specific section was present. > Master is the most confusing of these keys because it is used so > erratically. It's actually used 100% consistently, and maps to a specific property of the kernel network interface. A device that has a master has no IP configuration of its own, because it is used only as part of the operation of its master device. This is a completely different situation from VLAN parent, where the VLAN interface and its parent are entirely independent of each other at the IP level. Also, "master" points to a device that requires this one, while "parent" points to a device that this one requires. And in particular, a VLAN device can have both a parent and a master. Eg, if you have bond0 containing eth0.1 and eth1.1, then eth0.1 would have parent=eth0 and master=bond0. Whereas a device can't have two masters. > The inconsistency is the problem. To me, it seems like every use of > [connection] master would be better served by using the "parent" key > in that interface's inferred type section (like bridge-port in the > example above). We could in theory have separate "master" properties for each slave type, and maybe we would have done it that way if we had added bridge support first. (Note that there's no slave-specific keyfile section / NMSetting subclass for bonds, because bond slaves have no slave-specific properties.) > slave-type > -------------- > > There's not much to say here. This key is basically an amalgamation of > master and type. The type and slave relationship can be inferred in > another section. As mentioned above, for bond slaves, there is no [bond-slave] section, so this could only be inferred by looking up the connection pointed to by "master", which is not always convenient. (However, see also https://bugzilla.gnome.org/show_bug.cgi?id=682052) > interface-name > --------------------- > > I don't understand why many of the sections have an interface-name key > in addition to connection. The connection interface-name property is new in 0.9.10. The bond/bridge/vlan/team-specific interface-name properties are now deprecated. If they're still required in keyfiles in git master, then file a bug please. They shouldn't be. -- Dan _______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
