[quagga-dev 10526] Re: Adding "encapsulation dot1q" option to interfaces

Adrian Ban bluelightning at mantech.ro
Wed May 8 02:33:52 BST 2013


Starting from suggestion of David Lamparter (thanks again David) I've 
already created a new daemon with the new commands. Adding/removing 
commands and saving config into the file works flawless.
I've just added 2 MTYPEs: MTYPE_ADDON,  MTYPE_ADDON_IF in lib/memtypes.h 
and small changes in vtysh/vtysh.c and .h (just added the new daemon). 
So no other stuff needed to be changed in the Quagga.

I didn't have any inspiration to give a name to the daemon and I've 
called: addond.

Is fine to start with this name or do you have a better name for it?
The daemon is small right now and is a good moment to rename it if is 
the case.

Thanks in advance,

On 5/3/2013 3:33 PM, David Lamparter wrote:
> On Fri, May 03, 2013 at 03:20:52PM +0300, Adrian Ban wrote:
>> Ok, I understand. Thanks for supporting.
>> I will add patches to my own Quagga tree and I will add to the git-hub
>> if anybody doesn't have  anything against this solution naming the tree
>> something like this: quagga-SOMETHING.
>> I will try to keep up the patch for each Quagga release.
>> The bad part is that the distributions will never benefit for this features.
> There is actually a reasonable middle path here I think - make it a
> separate daemon within the Quagga daemon herd.  That way it can use the
> vtysh architecture, library code, and probably reuse code from zebra
> too.  It might be a little more work, but it's nicely isolated, you can
> switch it on/off, and if the code is good and well-maintained I believe
> we can merge it into mainline Quagga.  Call it grévy, to test OS support
> for UTF-8 process names ;).
> In the long run I believe we should modularise the Quagga CLI and
> configuration architecture anyway - in both daemon and user direction.
> Having other software components in the same fold (think ethernet,
> bridge, VPN, etc. config) would be good user interface as well as adding
> other ways to access the fold like better scriptable command-line tools
> (better "vtysh -c") and maybe interfaces to other parts of the system
> (stuff like configuration RPC and/or NETCONF).
> However, that's a rather large project and might fall to the inner
> platform effect.
> -David
>> On 5/3/2013 3:03 PM, James Carlson wrote:
>>> On 05/03/13 01:51, Adrian Ban wrote:
>>>> There is somewhere a documentation about Quagga which says that adding
>>>> interface functions are outside the scope? I'm curious where is written.
>>>> If other Quagga users will ask to add those kind of new features will be
>>>> refused by Quagga maintainers as well because is outside the scope even
>>>> the features will be fully complained with* **Unix platforms,
>>>> particularly FreeBSD, Linux, Solaris and NetBSD** *?
>>> Well, the good news is that there's a third zebra species name that's
>>> still up for grabs -- Grevy.  There for the taking by anyone who feels
>>> that another fork is necessary.
>>> For what it's worth, I agree with the maintainers.  It's well out of
>>> scope of routing protocols, and a serious pain to maintain per platform.
>>>    The Quagga command line is not actually the Cisco command line, and
>>> dumping the kitchen sink into it in an attempt at convergence sounds
>>> like a bad plan for Quagga.  It may make sense for some users, but can't
>>> be good for the project.

More information about the Quagga-dev mailing list