[prev in list] [next in list] [prev in thread] [next in thread] 

List:       quagga-dev
Subject:    [quagga-dev 9584] Re: [PATCH RFC] OSPF vertices memory exhaustion
From:       Joakim Tjernlund <joakim.tjernlund () transmode ! se>
Date:       2012-07-31 20:22:27
Message-ID: OF8098250A.043C5161-ONC1257A4C.006D2416-C1257A4C.006FEB4F () transmode ! se
[Download RAW message or body]

Paul Jakma <paul@jakma.org> wrote on 2012/07/25 22:07:44:
>
> On Tue, 19 Jun 2012, Joakim Tjernlund wrote:
>
> > On vacation now but you could try fixing this code:
> >
> >       * http://blogs.sun.com/paulj/entry/the_difference_a_line_makes
> >       */
> >      if (added)
> >        return added;
> >
> > It is wrong which I have pointed out earlier but Paul claimed it does
> > not matter.
>
> When was that discussion? Link to archives?

It is this thread, if you bother to dig a little bit.
Also, the patch itself has more info then what got committed to the repo.

>
> It seems you didn't convince me this was wrong before. I've just gone

Yes, I said as much already.

> through the original bug and refreshed my understanding from scratch as to
> why that was done as it is, and I still don't think it's wrong. Indeed,
> I'm not convinced you understand why that code is the way it is (based
> just on the commit comment, and my own refresh of the code, the blog
> entry, and bug #330 - I havn't gone over earlier discussions). ;)

Can you then explain why your old code is correct w.r.t the OSPF RFC?
Why is it correct to jump from within 16.1.1,para 5:
             * ...the parent vertex is a network that
	       * directly connects the calculating router to the destination
	       * router.  The list of next hops is then determined by
	       * examining the destination's router-LSA...
just because you didn't find any links to
  /* 16.1.1 para 4.  If there is at least one intervening router in the
   * current shortest path between the destination and the root, the
   * destination simply inherits the set of next hops from the
   * parent.
   */

Any way I read the RFC these two cases are mutually exclusive.


>
> Now, that's not meant as an insult, Just that my approach to maintenance
> was that the maintainer should take a sceptical stance on contributions
> and require that they come with convincing explanations as to what the
> problem is, and why the submitted patch fixes it. Otherwise, I felt then,
> we risked lots of pointless code churn from speculative or
> not-fully-understood patches.
>
> That said, maintenance approach today may be different.

Yes, thankfully.

_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-dev
[prev in list] [next in list] [prev in thread] [next in thread]