This series is a proposal to fix some users of netdev_open and introduce a new behavior for netdev_open when called with a different type than the one already opened.
Right now, if multiple callers open the same device with different types, the first caller creates the device with the correct type and the other callers get a handle for a device with an incorrect type. One of the problems already fixed for that was using the incorrect type on vswitchd/bridge.c, which caused failures for setting MAC address or supporting STP when using the netdev datapath. Even though that was not caused by the incorrect type being used during open, it was caused by a different type being used for comparison. Other problems that are expected to be fixed are more in the design area, where devices with the same name are currently allowed to have different types, and yet they will be incorrectly represented as the first type to be opened. Which causes failures in the routing area, for example, when a system device will be opened before a device in the database with a different type. One of the design decisions here is not allowing those different types to coexist. Though we could decide to allow them and have more than one netdev with the same name, it would not be always possible to open them. For example, a system br0 and an internal br0 could not co-exist. The other decision here is to keep dpif_port.type and ofproto_port.type refer to the configured/database type, not the netdev type. Otherwise, whenever using dpctl, for example, the netdev type would be shown (tap/dummy instead of internal). The other path, still viable, though maybe not as simple, but maybe more correct one is to have dpif types refer to their respective netdev types and convert them to the configured types either at the ofproto and dpctl levels, or also use the netdev types as ofproto_port types. But some reversal of the types would be needed and since they are not 1:1, it might require some bookkeeping. And last, the system type is kept as the default. Unless the user/database refers to it, it should not be used directly. Code that should work with any type must use NULL instead. The design decision here is to keep the behavior of opening a system type netdev in this case, instead of making NULL mean to use whatever is already opened, but not create a new device. This keeps some things simple, like not having to defer some operation when the proper netdev is created, and also allows potential conflicts to appear earlier. On the other hand, some conflicts might be created where they wouldn't exist, though I haven't run into it yet. Thadeu Lima de Souza Cascardo (5): in-band: use open_type when opening internal device in-band: don't use system type when opening netdev netdev-vport: don't use system type when opening netdev dpctl: uses open_type when calling netdev_open netdev: do not allow devices to be opened with conflicting types lib/dpctl.c | 17 ++++++++++++----- lib/netdev-vport.c | 2 +- lib/netdev.c | 8 +++++++- ofproto/in-band.c | 5 +++-- 4 files changed, 23 insertions(+), 9 deletions(-) -- 2.7.4 _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
