[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: using carp(4)
On Sun, Nov 13, 2011 at 10:55:38PM +0100, Manuel Bouyer wrote:
> 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)
I also forgot to mention that I'm using the preempt mode.
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
NetBSD: 26 ans d'experience feront toujours la difference
Main Index |
Thread Index |