On Thu, Jun 16, 2016 at 09:31:20AM -0400, Donald Sharp wrote:
> I personally don't see allot of value in making snmp support runtime
> -vs- compile time,
At the very least, it's a nice halfway step to kicking it out ;)
> but as a proof of concept I think it's fine for what it is.
Yay, mission accomplished!
(Still open for feedback - if people have opinions about my
implementation of plug loading & hook points, please voice them!)
> I do see value in shared libraries though.
>
> Should we be thinking a bit bigger? Could we modify the protocols to
> all be shared libraries that could be loaded and then modify
> watchquagga( or some other daemon ) and vtysh to be able to auto start
> the daemons as shared libraries when the appropriate cli comes in?
Yes and no - I think librarifying the daemons is a "if all you have is a
hammer" overapplication. DSOs are nice, but this is starting from the
tool trying to look for applications.
The daemons being separate processes is a *feature*:
- a crash doesn't propagate through everything (though it may corrupt
state)
- protocols run on their own CPUs without any threading support
- protocols can be individually upgraded in a very clean way
(even more so if we had more GR support)
Making them DSOs loses all of those ... for what gain? A dlopen() is
really not easier than a fork()/exec() ...
Now, for the "yes" part... there are quite a few things that make sense
to modularise:
- SNMP, if it stays around
- Sproute's/Avneesh's Protobuf stuff
- OSR's/my Cap'n Proto stuff
- the entire CLI
- kernel backends
Note all of those are in one way or another frontends or backends that
attach above or below Quagga's core functionality. Different users may
want different combinations, so theoretically you'd want to include all
of them, but at the same time they might consume considerable resources
either themselves (e.g. CLI) or have quite a few dependencies (Protobuf,
ZeroMQ, Cap'n Proto, Net-SNMP, etc.) Yet, all of these are most
sensible in-process, lest they create a chicken & egg situation for an
interface needing an interface. [*]
On a random sidenote, I'm trying to setup things so that direcly linking
a plugin into the executable vs. loading it dynamically makes as little
difference as possible.
So -- I'd summarise this as "modularise upwards and downwards, but not
sideways".
Hope this makes sense,
-David
[*] Except SNMP, that should probably use one of the other interfaces
and be out-of-process.
> On Tue, Jun 14, 2016 at 1:59 PM, David Lamparter
> <equi...@opensourcerouting.org> wrote:
> > Hi all,
> >
> >
> > this series contains support for loading dynamic modules (DSOs) that contain
> > additional functionality. bgpd's SNMP support is the test target.
> >
> > THIS IS AN UNFINISHED VERSION TO INVITE FEEDBACK.
> >
> > In the "big picture", there are some very broad topics that are non-trivial,
> > first and foremost interaction of plugin's DEFUNs with config saving and
> > startup. In the current version, the patchset only supports loading DSOs on
> > the command line, i.e. before config load. That means all config works as
> > usual. However, if you remove a module from startup parameters, leftover
> > config statements may result in startup failure. Not sure if this is a real
> > problem...
> >
> > FWIW, loading modules from the config wouldn't be much of a problem, as long
> > as the plugin-loading statements get pushed all the way to the top of the
> > config. That way, they'd be loaded before their respective config blocks
> > are
> > reached.
> >
> > Also, after unloading a module, config writes wouldn't include its config
> > anymore. The on-disk config file either has both the "load plugin" command
> > and the plugin's config (i.e. before-removal config), or would have neither
> > (as written out by a "write mem" after removing the module).
> >
> > That said, I haven't implemented unloading (or uninstalling hooks) yet :)
> >
> >
> > Cheers,
> >
> > -David
> >
> >
> > _______________________________________________
> > Quagga-dev mailing list
> > Quagga-dev@lists.quagga.net
> > https://lists.quagga.net/mailman/listinfo/quagga-dev
>
> _______________________________________________
> Quagga-dev mailing list
> Quagga-dev@lists.quagga.net
> https://lists.quagga.net/mailman/listinfo/quagga-dev
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
