* Ben Pfaff (b...@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. > > +@BUILD_BRCOMPAT@ # If the bridge module is loaded, then that might be > > blocking > > +@BUILD_BRCOMPAT@ # @OVSKMOD@. 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 _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
