"David S. Miller" a écrit :
> On 12 Aug 2003 08:59:17 -0400
> jamal <hadi@xxxxxxxxxx> wrote:
> > You dont think asking "what if the application dies" is in the same
> > calibre as "what happens when the kernel oopses"?
> Don't sweat it Jamal, some people just don't get it :-)
> Look, people, when userlevel routing daemon dies your system
> effectively stops to route.
That's why in really *safe* systems, we do not use routing daemon
but only static routes ;-)
And there is a BIG difference :
When user level daemon dies, you have to be sure that some stuff
exists to monitor and recover from that situation (either by
restarting the faulty deamon (if it could recover in time which
I doubt with the bonding case), or by switching to a new machine
in a fault tolerant configuration). With kernel ooops, there is
NOTHING to do in such in such a fault tolerant systems, since the
machine is unusable (this is the same as a hardware failure).
But people does not understand the constraints of really safe
> Policy belongs strictly at user space.
> One of the great things about what Jamal spends his time working
> on is finally a strict seperation of the control layer from everything
> else. And part of this is moving all of the control logic into userspace.
> Once that is accomplished, I can have my toilet flush every time a TCP
> packet is routed through my system and this won't crap up the kernel.
> If you don't see the value in that, perhaps you shouldn't be partaking
> in this discussion :-)
This is OK as long as your kernel and user space stuff remains suitable
for highly fault tolerant systems and which does not require big montains
of user stuff to do the same as a few line of code in the kernel. Remember
the aim of bonding : NIC fault tolerance or load balancing. I am not against
a user space configurable policy for more complex job but the initial aim of
the bonding shall remain coded in the kernel (and is only usable in the above
mentioned systems in that way).