Messages in this thread | | | Date | Thu, 30 Mar 2006 14:26:14 +1100 | From | Nick Piggin <> | Subject | Re: [RFC] Virtualization steps |
| |
Eric W. Biederman wrote:
>Nick Piggin <nickpiggin@yahoo.com.au> writes: > > >>I don't think I could give a complete answer... >>I guess it could be stated as the increase in the complexity of >>the rest of the code for someone who doesn't know anything about >>the virtualization implementation. >> >>Completely non intrusive is something like 2 extra function calls >>to/from generic code, changes to data structures are transparent >>(or have simple wrappers), and there is no shared locking or data >>with the rest of the kernel. And it goes up from there. >> >>Anyway I'm far from qualified... I just hope that with all the >>work you guys are putting in that you'll be able to justify it ;) >> > >As I have been able to survey the work, the most common case >is replacing a global variable with a variable we lookup via >current. > >That plus using the security module infrastructure you can >implement the semantics pretty in a straight forward manner. > >The only really intrusive part is that because we tickle the >code differently we see a different set of problems. Such >as the mess that is the proc and sysctl code, and the lack of >good resource limits. > >But none of that is inherent to the problem it is just when >you use the kernel harder and have more untrusted users you >see a different set of problems. > >
Yes... about that; if/when namespaces get into the kernel, you guys are going to start pushing all sorts of per-container resource control, right? Or will you be happy to leave most of that to VMs?
--
Send instant messages to your online friends http://au.messenger.yahoo.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |