Harald,
My (stoopid) ISP doesnt like your email address. In any case, attached
patch of what i was alluding to. Maybe be missing some things.
Compiles - not tested and extremely dangerous becdause of side effects
to arp and forwarding - so needs a lot of testing.
damn spent my tim hortons coffee on this patch and too cold to go out.
cheers,
jamal
On Sun, 2004-12-19 at 17:59, jamal wrote:
> I had something much simpler in mind.
> Basically, promote the next one in line. This would be cleanly backward
> compatible and would be an improvement over whats there (however
> medievial it is). Let me see if i can whip something that at least
> compiles. Unfortunately i wont have time to chase it to completion of
> testing until around xmas when i have time off from work.
>
> cheers,
> jamal
>
> On Sun, 2004-12-19 at 17:02, Thomas Graf wrote:
> > * Harald Welte <20041219214120.GX17302@xxxxxxxxxxxxxxxxxxxxxxx> 2004-12-19
> > 22:41
> > > On Sun, Dec 19, 2004 at 03:18:37PM -0500, jamal wrote:
> > >
> > > > Having said the above, I think it would make sense to have a "promotion"
> > > > scheme so that in the case a primary address is deleted, one could
> > > > promote the next secondary address in line. But that should be optional.
> > >
> > > Oh yes, please. This would save a lot of headache. I'm much in favour
> > > of such a proposal.
> >
> > Agreed, would be nice to have.
> >
> > > > Now where is the fireman who wants to do this? I could help cheering
> > > > since i know the code.
> > >
> > > how would you think it fits best into the current netlink messages?
> >
> > 1) IFA_F_PROM_CAND flag and have inet_del_ifa* iterate over its
> > secondary addresses and elect the first with the flag set.
> >
> > 2) IFA_PROM_PRIO TLV of type u32 holding a priority where 0 means no
> > candiate. inet_del_ifa* iterates over its secondary addresses and
> > elects the one with the highest prio as new primary address or
> > deletes all addresses if none is found.
> >
> > * respectively the equivalent function of the other address families.
> >
> > Second variant requires more work but is more flexible so it's
> > definitely my favourite. I'm willing to put some effort into this,
> > I'm not familiar with all address families though.
> >
p5
Description: Text document
|