David Young
2011-11-02 00:29:28 UTC
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
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
***@pixotech.com Urbana, IL (217) 344-0444 x24
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
David Young OJC Technologies is now Pixo
***@pixotech.com Urbana, IL (217) 344-0444 x24
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de