It seems to me that the real problem here is that the API is wrong. I
see two reasons why a client opens a network device:
* To retrieve its configuration, fiddle with it a bit, send
and receive packets, etc.
These clients expect the device to already exist and be
configured, and won't be able to do anything sensible if it
does not.
Looking over the tree, I think that this accounts for all
but three or so uses of netdevs.
* To set a specific configuration on a network device,
creating the device if it does not yet exist, and then
continue as with the first case. This case is distinguished
by the fact that we want a particular configuration and that
we are willing to create a new device.
Under this rationale, though, there are *three* cases that we want to
distinguish when a netdev gets opened:
1. We're opening a netdev that we expect to already exist and
be configured (the first case above).
This should probably work as long as the netdev already
exists, regardless of whether it was created by this
process or another one. We may need to retrieve the
configuration from the kernel in this case.
2. We're opening a netdev to create and configure it. Nothing
else in the process has yet done this; the netdev is not
currently open.
In such a case we should set the new configuration,
ignoring whatever is already there.
3. We're opening a netdev to create and configure it, but
some other part of this process has already done this, and
that netdev is still open.
This should probably fail.
Currently the netdev implementation mixes up cases #2 and #3. Instead
of distinguishing these cases on whether *this process* has opened and
configured the netdev, it distinguishes it based on whether the netdev
has been opened and configured and the configurations appear to be
equal.
_______________________________________________
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev
