Seems like a reasonable explanation of the problem to me. I think in the near term we should have parse_tunnel_config return EINVAL on unsupported actions. When we have a bit more time, we can restructure the netdev code. Does that seem like a reasonable plan for now?
Ethan On Wed, Aug 3, 2011 at 13:21, Ben Pfaff <[email protected]> wrote: > 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
