On Wed, Nov 25, 2015 at 05:15:27PM +0100, Vincent JARDIN wrote:
> On 25/11/2015 16:32, David Lamparter wrote:
> > That
> > component could either be in-process (using something like Swig or
> > Cython to access C memory structures) or external (using some wrapping
> > like Protobuf to access C memory structures) or badly-done external
> > (using the CLI to poke at Quagga).
> 
> I like the Cython option, but it is maybe to heavy for embedding 
> systems, do you have some data points?

Cython (or any python option really) is impossible to do in a current
OpenWRT system with 4~16 MB flash.  Python just takes up too much space
(Quagga itself already is a tight fit.)

In the long run, this will become a "null problem", but I'm also unsure
if this can be use for "high bandwith" things like accessing full
tables.  Unfortunately, I don't have data on the latter.

> I agree +1 for a kind of in-process would help close to CLI's DEFUN 
> related when needed.
> 
> To implement d- I was more on a lua + bson since lua is light compared 
> to Cython. But ideas are welcomed to be shared.

Lua is indeed lighter.  However, it's probably advantageous to have as
little code as possible inside Quagga - especially since it's still all
singlethreaded.  Lua is better than Python, but I think it's possible to
go further in this direction.

Either way the hard part is really the interfacing... the glue not only
needs to know what variables exist, it also needs to consider that
changing X (like a BGP capability) implies resetting Y (BGP session) by
internal function Z (bgp_clear()).  And, best case, this information is
exposed further towards the user so that the "final" upper level user
interface knows that changing the setting needs/results in a BGP session
reset.

(This is a downside of representing these dependencies in code:  the
code itself has the knowledge, but that knowledge is not accessible in
the schema or anything.  You need to read the code to know...)


-David

_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

Reply via email to