On Wed, Nov 05, 2014 at 03:23:24PM -0800, Andy Zhou wrote: > On Wed, Nov 5, 2014 at 2:56 PM, Flavio Leitner <f...@redhat.com> wrote: > > On Wed, Nov 05, 2014 at 02:07:08PM -0800, Ben Pfaff wrote: > >> On Wed, Nov 05, 2014 at 08:04:29PM -0200, Flavio Leitner wrote: > >> > The above is not available in Fedora 20. > >> > # stat /sys/module/openvswitch/version > >> > stat: cannot stat ???/sys/module/openvswitch/version???: No such file or > >> > directory > >> > # uname -r > >> > 3.16.7-200.fc20.x86_64 > >> > >> You only get it with the out-of-tree module (which is expected). > > > > Right, though I think the in-tree module could export the version > > as well, so that we could track that too. For example: > > > > $ modinfo openvswitch | grep vermagic > > vermagic: 3.16.7-200.fc20.x86_64... > Will this always be the same as the OS version? I think the > controller / user space may be more interested in OVS version,
Define OVS version, because to me that is the OVS datapath version. > For example, on my ubuntu system, I got the following output: > versmagic: 3.13.0-19-generic SMP mod_unload modversions > > It is hard to decipher which OVS version was selected by the > distribution, or contains modifications or back-ports by distribution > in general. > > On the other hand, if this feature is useful for redhat distribution, > and make sense within this scope, I don't see any harm in adding it in > case > OVS version is not directly obtainable. > > Make sense? What do you think? I think it makes sense not only for Red Hat, but for any other distribution shipping the in-tree module. It doesn't make sense to add a version to the in-tree OVS module. Any bugfix back-ported by any distribution will create version "major" and "minor" which in the end means the same as the kernel version. But if you have a controller exploring this feature, you can tell which hosts are running which versions, regardless of the distribution. fbl _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
