netdev
[Top] [All Lists]

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

To: shmulik.hen@xxxxxxxxx, hadi@xxxxxxxxxx
Subject: Re: [Bonding-devel] Re: [SET 2][PATCH 2/8][bonding] Propagating master's settings toslaves
From: Jeff Garzik <jgarzik@xxxxxxxxx>
Date: Mon, 11 Aug 2003 12:43:47 -0400
Cc: Laurent DENIEL <laurent.deniel@xxxxxxxxxxxxx>, bonding-devel@xxxxxxxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <200308111925.38278.shmulik.hen@xxxxxxxxx>
Organization: none
References: <E791C176A6139242A988ABA8B3D9B38A014C9474@xxxxxxxxxxxxxxxxxxxxxxx> <200308111720.38472.shmulik.hen@xxxxxxxxx> <1060612481.1034.15.camel@xxxxxxxxxxxxxxxx> <200308111925.38278.shmulik.hen@xxxxxxxxx>
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
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?

In practice, #3 is the showstopper that occurs most often.

This is why I push for a "bonding-utils" package from Jay.... because of the general rule above: put it into userspace, where possible.

        Jeff




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