[ovs-dev] configure --disable-brcompat?

[Chris Wright]

* Ben Pfaff (blp at nicira.com) wrote:
> On Thu, Mar 01, 2012 at 11:09:07PM -0800, Chris Wright wrote:
> > I'm pondering adding a way to disable brcompat.  This would keep from
> > building it and strip it from config templates, init scripts, ovs-ctl,
> > etc...  Here's a quick hack to give an idea.
> > 
> > Any thoughts whether this is worth pursuing, and if so ideas on best way
> > to do it?
> 
> I support the idea of adding a configure option to disable building
> ovs-brcompatd and the brcompat kernel module (though I suppose the
> latter doesn't matter for Fedora).

Right, I didn't add anything for kernel module; quick hack, and not needed
for my local Fedora testing.  So, I could hack up the basic bits...don't
build either daemon or module, and figure out anything more invasive
for follow on (or even drop that idea altogether).

> The part I don't like is the @BUILD_BRCOMPAT@ markers.  They are ugly,
> but, worse, they will make maintenance of those bits of the scripts
> difficult.

I completely agree.  I figured I'd post something to show what I was
thinking, and w/ something terribly ugly motivate someone w/ better
auto*-fu to point me in a better direction ;)

>  Why is there such a strong motivation to entirely excise
> all the brcompat-related shell script code, instead of just disabling
> it?  If you want to disable it in a pretty strong fashion, then it
> wouldn't be hard to just throw in an explicit "BRCOMPAT=no" somewhere
> in the script, disable the command line option, etc. (and maybe
> --disable-brcompat could do that automatically).

The script is reasonably well-hidden from users, so probably not as big
a deal as the config files.  Users love to tweak things and expect it
to Just Work...that's my motivation for eradicating it from a package
that doesn't support it.  Also, figuring long term, it will go away, so
we'd have an easy way to simply turn off the support.

> The following block isn't strictly related to brcompat.  Instead, it
> has to do with kernels that don't support loading both the bridge and
> openvswitch kernels at the same time.  That's almost orthogonal to
> brcompat, in that it can be useful with older kernels even if the user
> doesn't want brcompat.  So, I understand if it should be disabled
> (maybe we can be smarter about it?) but I don't think it should be
> tied to disabling brcompat.
> > + at BUILD_BRCOMPAT@    # If the bridge module is loaded, then that might be blocking
> > + at BUILD_BRCOMPAT@    # @OVSKMOD at .  Try to unload it, if there are no bridges.

<snip rest of block>
True, although in a modern (upstream provided datapath), this wouldn't
happen, so I've conflated !brcompat w/ upstream provided datapath.

thanks,
-chris