On Thu, Mar 1, 2012 at 9:28 PM, Chris Wright <chr...@sous-sol.org> wrote:
> This is just an RFC, partly because it ignores datapath/ so you could
> build a module that the runtime can't install. Now that the ovs datapath
> is upstream and named simply openvswitch, tools like ovs-ctl fail to
> function w/ the native datapath module. This is a simple example using
> an environment variable of making the name configurable with:
>
> ./configure OVSKMOD=openvswitch
>
> Thoughts?
>
> thanks,
> -chris
> ---
> Makefile.am | 1 +
> configure.ac | 6 ++++++
> utilities/ovs-ctl.in | 18 +++++++++---------
> 3 files changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/Makefile.am b/Makefile.am
> index 46de7fb..dc4a609 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -101,6 +101,7 @@ SUFFIXES += .in
> -e 's,[@]RUNDIR[@],$(RUNDIR),g' \
> -e 's,[@]VERSION[@],$(VERSION),g' \
> -e 's,[@]BUILDNR[@],$(BUILDNR),g' \
> + -e 's,[@]OVSKMOD[@],$(OVSKMOD),g' \
> -e 's,[@]localstatedir[@],$(localstatedir),g' \
> -e 's,[@]pkgdatadir[@],$(pkgdatadir),g' \
> -e 's,[@]sysconfdir[@],$(sysconfdir),g' \
> diff --git a/configure.ac b/configure.ac
> index a1c1fb4..7e4fdb7 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -93,6 +93,12 @@ AC_ARG_VAR(KARCH, [Kernel Architecture String])
> AC_SUBST(KARCH)
> OVS_CHECK_LINUX
>
> +AC_ARG_VAR(OVSKMOD, [Open vSwitch kernel module name (default
> openvswitch_mod)])
> +if test "X$OVSKMOD" = "X"; then
> + OVSKMOD=openvswitch_mod
> +fi
> +AC_SUBST(OVSKMOD)
> +
> AC_CONFIG_FILES([Makefile
> datapath/Makefile
> datapath/linux/Kbuild
> diff --git a/utilities/ovs-ctl.in b/utilities/ovs-ctl.in
> index 9bdb3df..07b9f32 100755
> --- a/utilities/ovs-ctl.in
> +++ b/utilities/ovs-ctl.in
> @@ -31,14 +31,14 @@ done
> ## ----- ##
>
> insert_openvswitch_mod_if_required () {
> - # If openvswitch_mod is already loaded then we're done.
> - test -e /sys/module/openvswitch_mod && return 0
> + # If @OVSKMOD@ is already loaded then we're done.
> + test -e /sys/module/@OVSKMOD@ && return 0
>
>From upgrade perspective: If the new user-space would want to use
openvswitch.ko, but the old one was using openvswitch_mod.ko,
then could we somehow make this part a little bit more intelligent,
so that upgrade would be seamless and the user would not have to
manually unload the old kernel module (see force-reload-kmod command)?
Although, I guess a system reboot would be anyway necessary if user
upgraded from a linux kernel that does not have openvswitch module and
the one that has. So it would be up to user to do both upgrades in one
shot.
> - # Load openvswitch_mod. If that's successful then we're done.
> - action "Inserting openvswitch module" modprobe openvswitch_mod &&
> return 0
> + # Load @OVSKMOD@. If that's successful then we're done.
> + action "Inserting openvswitch module" modprobe @OVSKMOD@ && return 0
>
> # If the bridge module is loaded, then that might be blocking
> - # openvswitch_mod. Try to unload it, if there are no bridges.
> + # @OVSKMOD@. Try to unload it, if there are no bridges.
> test -e /sys/module/bridge || return 1
> bridges=`echo /sys/class/net/*/bridge | sed
> 's,/sys/class/net/,,g;s,/bridge,,g'`
> if test "$bridges" != "*"; then
> @@ -47,8 +47,8 @@ insert_openvswitch_mod_if_required () {
> fi
> action "removing bridge module" rmmod bridge || return 1
>
> - # Try loading openvswitch_mod again.
> - action "Inserting openvswitch module" modprobe openvswitch_mod
> + # Try loading @OVSKMOD@ again.
> + action "Inserting openvswitch module" modprobe @OVSKMOD@
> }
>
> insert_brcompat_mod_if_required () {
> @@ -289,8 +289,8 @@ force_reload_kmod () {
> if test -e /sys/module/brcompat_mod; then
> action "Removing brcompat module" rmmod brcompat_mod
> fi
> - if test -e /sys/module/openvswitch_mod; then
> - action "Removing openvswitch module" rmmod openvswitch_mod
> + if test -e /sys/module/@OVSKMOD@; then
> + action "Removing openvswitch module" rmmod @OVSKMOD@
> fi
>
> start
> --
> 1.7.7.6
>
> _______________________________________________
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
