[Quagga-users 33] Re: so...
Stephan von Krawczynski
skraw at ithnet.com
Sun Aug 3 13:21:03 IST 2003
On Sun, 03 Aug 2003 12:44:00 +0300
Gilad Arnold <gilad.arnold at terayon.com> wrote:
> Stephan von Krawczynski wrote:
> > [...]
> > 1) platform independant code
> > 2) architecture specific "glue code"
> > throughout all the daemons. This would imply you need people for every arch
> > and people for independant parts.
> > Your thoughts?
> Nice thinking, although I believe is hard to employ: assigning
> committers (I prefer "reviewers", more democratic IMO) to components is
> rather easy; however, assigning responsibilities for architecture,
> keeping in mind that such people must actually be reponsible to certify
> that every committed change is working with their platform, implies that
> (1) these people are do-it-all experts wrt zebra (oops, quagga!), and
> (2) they'll have loads of work to do -- they must approve every change
> that happens anywhere in the code, namely each and every patch.
> Considering the fact that some platforms are quite singular, let alone
> some platforms are inconsistent (e.g. you may say Linux, while referring
> to some distro patched kernel, while in fact it isn't necessarily the
> same on others), this is quite complicated.
> What would I suggest? IMO, the majority of patches to quagga won't carry
> any platform-dependent properties:
Well, actually they don't because they can't :-)
My idea was (pretty obvious but nevertheless for completeness):
bgpd needs a maintainer who has deep knownledge about bgp
ospfd needs a maintainer who has deep knowledge about ospf
ripd needs - well, you name it ;-)
quaggad needs a maintainer who has deep knowledge about multitasking
application design (uh?)
quaggad-plugin-linux needs a maintainer who has deep knowledge about
interfacing to linux kernel routing code and process/thread stuff.
quaggad-plugin-solaris needs ...
You get the idea?
quaggad is in fact a very abstract piece of code that should have no idea at
all about the hw it runs on. It needs an abstraction layer that allows to use
all platforms equivalently.
Same goes for e.g. bgpd which very likely needs an abstraction layer for
process an timer-interrupt scheduling.
ospfd probably just the same.
So working idea should be top-down. bgpd-maintainer states what functionality
is needed to built a completely conform bgp implementation. Same for all other
routing protocols. Arch maintainer then should be able to cope with that and
implement the features needed.
This is all where basic brainstorming, and completely off-topic in the
More information about the Quagga-users