Milan Kocián wrote: > On Wed, 2007-04-11 at 20:19 +0200, Patrick McHardy wrote: > > >>I think having notifications for this case makes sense (IIRC I used >>to use a similar patch some time ago, but can't find it right now). >>But we need to indicate somehow that it is a replacement and not a >>completely new route, either by sending a RTM_DELROUTE for the old >>route first (which would match what devinet does for addresses) >>or by echoing the NLM_F_REPLACE flag. The former would probably be >>easier for userspace to understand since it wouldn't need to >>replicate the replacement logic just to find out which rule got >>replaced. >> >> > > > Hard to tell what is better. I slightly tried to test my patch with > quagga routing daemon. And then I tested second case: send RTM_DELROUTE > before RTM_NEWROUTE. Quagga updates internal rib in both cases (as I saw > in debug logs). I was in fear that quagga will try to install sefl route > but it doesn't catch. > So from my point of view is all the same :).
Looking at some old code of mine, it would treat a simple RTM_NEWROUTE without deletion in advance incorrectly, but it also would ignore NLM_F_REPLACE. Quagga doing the right thing seems to be a result of the fact that it doesn't care about some of the routes attributes and treats NEWROUTE messages as replacements as long as the attributes it cares about match. RTM_DELROUTE + RTM_NEWROUTE seem to be safer, although you're correct that it might cause userspace to perform some action upon receiving the DELROUTE message since the update is non-atomic. So I really don't know, I'm in favour of having notifications for replacements, but I fear we might break something. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html