[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m1ejk28eku.fsf@ebiederm.dsl.xmission.com>
Date: Sat, 23 Jun 2007 16:56:49 -0600
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Jeff Garzik <jeff@...zik.org>
Cc: David Miller <davem@...emloft.net>, kaber@...sh.net,
netdev@...r.kernel.org, hadi@...erus.ca,
shemminger@...ux-foundation.org, greearb@...delatech.com,
yoshfuji@...ux-ipv6.org, containers@...ts.osdl.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFD] L2 Network namespace infrastructure
Jeff Garzik <jeff@...zik.org> writes:
> David Miller wrote:
>> I don't accept that we have to add another function argument
>> to a bunch of core routines just to support this crap,
>> especially since you give no way to turn it off and get
>> that function argument slot back.
>>
>> To be honest I think this form of virtualization is a complete
>> waste of time, even the openvz approach.
>>
>> We're protecting the kernel from itself, and that's an endless
>> uphill battle that you will never win. Let's do this kind of
>> stuff properly with a real minimal hypervisor, hopefully with
>> appropriate hardware level support and good virtualized device
>> interfaces, instead of this namespace stuff.
>
> Strongly seconded. This containerized virtualization approach just bloats up
> the kernel for something that is inherently fragile and IMO less secure --
> protecting the kernel from itself.
>
> Plenty of other virt approaches don't stir the code like this, while
> simultaneously providing fewer, more-clean entry points for the virtualization
> to occur.
Wrong. I really don't want to get into a my virtualization approach is better
then yours. But this is flat out wrong.
99% of the changes I'm talking about introducing are just:
- variable
+ ptr->variable
There are more pieces mostly with when we initialize those variables but
that is the essence of the change.
And as opposed to other virtualization approaches so far no one has been
able to measure the overhead. I suspect there will be a few more cache
line misses somewhere but they haven't shown up yet.
If the only use was strong isolation which Dave complains about I would
concur that the namespace approach is inappropriate. However there are
a lot other uses.
Eric
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists