[Top] [All Lists]

Re: [Bonding-devel] Re: [SET 2][PATCH 2/8][bonding] Propagating master'

To: Laurent DENIEL <laurent.deniel@xxxxxxxxxxxxx>
Subject: Re: [Bonding-devel] Re: [SET 2][PATCH 2/8][bonding] Propagating master'ssettings toslaves
From: Jeff Garzik <jgarzik@xxxxxxxxx>
Date: Mon, 11 Aug 2003 13:43:27 -0400
Cc: shmulik.hen@xxxxxxxxx, hadi@xxxxxxxxxx, bonding-devel@xxxxxxxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <3F37D2ED.B4B9223C@xxxxxxxxxxxxx>
Organization: none
References: <E791C176A6139242A988ABA8B3D9B38A014C9474@xxxxxxxxxxxxxxxxxxxxxxx> <200308111720.38472.shmulik.hen@xxxxxxxxx> <1060612481.1034.15.camel@xxxxxxxxxxxxxxxx> <200308111925.38278.shmulik.hen@xxxxxxxxx> <3F37C7C3.7070807@xxxxxxxxx> <3F37D2ED.B4B9223C@xxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk
Laurent DENIEL wrote:
Jeff Garzik a écrit :

The answer is, like life, it's a balance.

As a general rule, we do prefer to move all code possible out of the
Linux kernel.  We have even created "initramfs", which for 2.7, will be
used as a vehicle to move code from the kernel to userspace, that
previously had to be in the kernel only because it was a task that "had
to be performed at boot time".

However, one must consider
(1) does moving code to userspace create any security holes?
(2) does moving code to userspace dramatically increase the number of
context switches?
(3) does moving code to userspace violate some atomicity that being
inside the kernel guarantees?

You forgot one important aspect : (4) does moving code to userspace break compatibility (or behavior) with user land applications (or systems)

I agree... assuming these userland interfaces are fairly standard and widely deployed.

What can one do if say, kernel 2.[4|5] switches the NIC in 10 mseconds while kernel 2.7 with user land daemon switches in a few seconds ? nothing but stay with the previous version or fork the driver development ;-(

This is a silly example. If that happens in practice, then that is a bug in the configuration of the userland daemon, or a bug in the kernel<->userland ABI.

But I agree that it is interesting to do some stuff at user land, and if the bonding had an option to disable the automatic failover policy, this could be implemented with trigger towards user land application that could use an ioctl call to switch to the appropriate NIC according to the user lan configuration ...

Remember, ioctls are bad.  :)  Unix design mistake.

But the fast and simple failover policy shall remain in kernel code.

I would not make such absolute predictions, especially about policy :)


<Prev in Thread] Current Thread [Next in Thread>