CARP as a module; followup thoughts

[Will Andrews]

On Mon, May 4, 2009 at 10:04 AM, Bruce Simpson <bms at incunabulum.net> wrote:
> I'll have to take your word for that as I'm not using CARP just at the
> moment. I had to touch the mcast setup for the IPv6 SSM implementation. All
> compiles OK, but I haven't tested the code other than loading it. Only IPv6
> multicast group setup should be affected.
>
> Does your patch apply against these revisions OK?

It should.  I am using git to develop these patches.  I just did
another sync (to r191794) and the diff from svn to my local git branch
is the same as the patch I posted last night, so I presume it will
apply to a fresh svn checkout of -current as of that revision.

> Great stuff.
> Can this bug fix be merged separately, i.e. before other code is committed?
> That way it can get merged back to -STABLE more quickly, once RELENG_7 is
> unfrozen.

Yes, I can generate a separate patch for that one.  If I were able to
commit it myself, I'd certainly be doing it the way you suggest.  I'd
also suggest a more aggressive MFC timing for the free() bug fix than
for the module feature (perhaps 3 days vs. 1-2 months, as 7.2R is now
out).  I am going to backport this patch to RELENG_7.  Because of the
way it is implemented, I believe it should be safe to MFC.

> It would be good to have a more general code path for stuff like this to
> benefit from using the perfect hash filters in modern NICs, the main thing
> is that everything continues to work with no regressions :-)
>
> Thanks for the effort you've put into this, it will certainly help a lot of
> folk to be able to ship a CARP-capable GENERIC kernel.

Indeed, regressions will be difficult to prevent.  I'm planning to
work on virtual lladdrs for a bit to see if I can find a suitable
solution for the problem.  If nothing else, I think it provides a
reasonable method for getting rid of carp_forus(), and possibly for
implementing carpdev.

Thanks,
--Will.