[quagga-dev 12588] Re: [PATCH v3 00/22] VRF support in quagga

David Lamparter david at opensourcerouting.org
Mon Jun 1 16:17:18 BST 2015


On Mon, Jun 01, 2015 at 03:37:33PM +0100, Paul Jakma wrote:
> On Sun, 31 May 2015, David Lamparter wrote:
> > As such, I'd mark the entire field as experimental (i.e. we won't care
> > about API or CLI breakage for VRFs), and let the bright people on this
> > list apply their engineering chops to it.  If some patchsets are badly
> > engineered, we can point out those specific engineering issues at that
> > occasion.
> 
> I'm not so sure.
> 
> Not so long ago we weren't even able to change the default of the 
> link-state command to something that'd suit the overwhelming majority of 
> users, because there might be some (likely small and transient set) of 
> users with broken setups that might (incorrectly) depend on it.
> 
> If we put VRF in in a way that people start depending on aspects of this 
> particular implementation (or can be argued is possible), my experience 
> (not just from link-state, but other stuff) is that externally visible 
> things can be difficult to change once in.

Well, this is a nice argument for printing a more obvious CLI warning
when a user uses any VRF feature.  We should add that - anyone wanna do
a followup patch?

(FWIW, I strongly argued the link-detection issue because I personally
knew setups that get broken by this, and in a very subtle non-obvious
way.  This is not the case with VRF support.)

> > For all we know, we can later chop off the variants that didn't end up 
> > useful much.
> 
> Or we just design it right now.

Except, we don't now right now which ones are the useful bits.  More
interestingly, we *can't* know some of the answers, because they involve
determinations like "what will users run," "will someone put this on
OpenWRT," or "will someone provide feedback from adapting this to their
FancyHardwareSwitchChip or *BSD or NextLinuxKernelAPI."

> I'm sure no bright engineer would object to having a design discussion, 
> and ensuring that the proposal meets not just their own requirements but 
> any wider requirements of the community. That's part of good engineering.

I'm a bright engineer objecting to -further- design discussion.  We
already have discussed the process model, and the consensus is "do
both."  Further discussion IMHO crosses the line into bikeshedding.

The issue here is simply that "design" is not a well-delineated area.
First, we designed the process model.  Next, we're designing API
commands.  Then, we're designing how tasks are split into functions and
exposed in headers.  Then, we're "designing" what the code to read from
a socket looks like.  I bet /someone/ /somewhere/ had a design
discussion on what assembler instructions to use ;)

And, really, I don't see how we would arrive at a positive outcome from
this "design discussion" - especially since it appears to me that you're
having a discussion with... yourself?

At least, I don't see anyone else trying to further discuss this.  If
I'm having tomatoes on my eyes (wonderful german idiom ;) and am failing
to see someone, could that/these someone please speak up?


-David


P.S.: I really hope I didn't just jinx myself, I have code on my laptop
that uses ISO C11 stdatomic ops, which does go down to the asm level ;)




More information about the Quagga-dev mailing list