On 11/11/2017 9:57 AM, William Tu wrote:
yes, this is an artificial dependency. Another way I'm thinking is for
ovs-vswitchd
to hold the geneve.ko dependency instead of openvswitch.ko, when user creates
a geneve device. Is there a way to do that through rtnetlink or at
dpif_netlink_rtnl_create()?
It should be vport-netdev doing the magic. It creates the linkage with
netdev_master_upper_dev_link(), but apparently that is not enough to
bump the kernel module refcnt and thus prevent unloading. Maybe you can
dig into why that is. AFAICS, it should be linking openvswitch.ko and
and geneve.ko with that call.
Sure, will take a look.
I'm extremely uncomfortable with this approach of manually bumping a
driver refcnt.
I worry we're going to get into a situation where the driver won't
*unload*. In a properly
configured system this shouldn't be necessary. Driver dependencies
shouldn't have to
be manually configured.
Why do we have a vport-geneve driver loaded when there is a geneve
driver already
built in to the kernel? What is the OVS vport-geneve driver providing
that the built-in
kernel geneve driver does not provide?
- Greg
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
