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

Laurent DENIEL wrote:

Jeff Garzik a écrit :

quoted

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 :)

	Jeff