using carp(4)

[David Young <dyoung%pobox.com@localhost>]

Is it ok to remove carp(4)?  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?

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.

In sum, I doubt that carp(4) provides enough utility to justify its
maintenance cost.  If there are arguments to the contrary, I am
listening.

Dave

-- 
David Young             OJC Technologies is now Pixo
dyoung%pixotech.com@localhost     Urbana, IL   (217) 344-0444 x24