|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|
|References:||<E791C176A6139242A988ABA8B3D9B38A014C9474@xxxxxxxxxxxxxxxxxxxxxxx> <200308111720.38472.shmulik.hen@xxxxxxxxx> <1060612481.1034.15.camel@xxxxxxxxxxxxxxxx> <200308111925.38278.shmulik.hen@xxxxxxxxx>|
|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.
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:|
|Next by Date:||[PATCH] Duplicate access_ok in sunrpc, davej|
|Previous by Thread:|
|Next by Thread:|
|Indexes:||[Date] [Thread] [Top] [All Lists]|