Re: using carp(4)

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Tue, Nov 01, 2011 at 07:29:28PM -0500, David Young wrote:
> Is it ok to remove carp(4)?

I'm using it heavyly (and have even more usaeages in mind) at work.

>  I ask because it seems like a peculiar
> function for the kernel to provide, it may already be bitrotten, and the
> implementation will be difficult to maintain for the future.
> 
> The automated tests have recently detected a regression in carp(4),
> possibly my fault, so I have been trying to figure out what this
> creature is and how it works.
> 
> I learned from the carp(4) manual page that it is not a fish. I found a
> more helpful description of carp(4) in an old email of Liam J. Foy's,
> and now I think that I understand what it is trying to do.
> 
> I have reproduced the ATF test-case failure, and I have had a look at
> the code, and experimented with it on a dev box of mine.  No kernel
> but i386/ALL actually contains carp(4), and carp(4) is not built as a
> module, so I had to add it to my GENERIC-derived kernel configuration
> in order to begin experimenting.  The ATF test runs in the RUMP
> environment, not the test-host environment.
> 
> During my experiments, I ran across a bug where 'ifconfig carp0 destroy'
> causes a panic in callout_destroy().  That is not the same bug that ATF
> trips over.  I have a hunch that it has been there for a long time, but
> I don't see a PR for it.  That makes me wonder whether anyone is using
> carp(4) on -current?  Is anyone using it at all?

Well, I don't destroy carp interfaces in regular use :)

> 
> The code for carp(4) seems to have grown roots deep into the kernel.  I
> see code that fiddles with ifnet internals and with routes, and I see
> that carp(4) has its own protocol-switch entry.
> I anticipate it causing trouble for developers who would try to keep it
> up-to-date with changing/disappearing kernel APIs (such as they are) and
> a more modular, more SMP-friendly network stack.
> 
> Considering the function of carp(4), I wonder why it is a kernel
> function instead of a user daemon?  It seems that you could accomplish
> the same thing with a daemon that runs the CARP protocol and
> adds/removes a backup interface from a bridge(4) as it is necessary.

I'm not sure that's enough. The kernel would still consider this
interface as up and running, which a carp in backup mode is not really.

Also there's some load balancing facilities in carp (I'm not using this
right now, but it could be comming)

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--