Eric W. Biederman wrote:
> Patrick McHardy <[EMAIL PROTECTED]> writes:
>
>
>>Eric W. Biederman wrote:
>>
>>>-- The basic design
>>>
>>>There will be a network namespace structure that holds the global
>>>variables for a network namespace, making those global variables
>>>per network namespace.
>>
Ben Greear wrote:
> Kirill Korotaev wrote:
>
>>Patrick McHardy wrote:
>>
>>
>>>I believe OpenVZ stores the current namespace somewhere global,
>>>which avoids passing the namespace around. Couldn't you do this
>>>as well?
>>>
>>
>>yes, we store a global namespace context on current
>>(can be
Jeff Garzik wrote:
> Eric W. Biederman wrote:
>
>>Jeff Garzik <[EMAIL PROTECTED]> 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
Kirill Korotaev wrote:
Patrick McHardy wrote:
I believe OpenVZ stores the current namespace somewhere global,
which avoids passing the namespace around. Couldn't you do this
as well?
yes, we store a global namespace context on current
(can be stored in per-cpu as well).
do you prefer
Kirill Korotaev wrote:
Patrick McHardy wrote:
I believe OpenVZ stores the current namespace somewhere global,
which avoids passing the namespace around. Couldn't you do this
as well?
yes, we store a global namespace context on current
(can be stored in per-cpu as well).
do you prefe
Patrick McHardy wrote:
> Eric W. Biederman wrote:
>
>>-- The basic design
>>
>>There will be a network namespace structure that holds the global
>>variables for a network namespace, making those global variables
>>per network namespace.
>>
>>One of those per network namespace global variables will
Ben Greear wrote:
> Patrick McHardy wrote:
>
>>Eric W. Biederman wrote:
>>
>>
>>>-- The basic design
>>>
>>>There will be a network namespace structure that holds the global
>>>variables for a network namespace, making those global variables
>>>per network namespace.
>>>
>>>One of those per netw
David Miller <[EMAIL PROTECTED]> writes:
> From: [EMAIL PROTECTED] (Eric W. Biederman)
> Date: Sun, 24 Jun 2007 06:58:54 -0600
>
>> I am convinced I can keep network namespaces something that is so
>> trivial and obvious to get right you won't have to pay attention
>> to them.
>
> Ok then, I'll ho
Quoting Jeff Garzik ([EMAIL PROTECTED]):
> Eric W. Biederman wrote:
> >Jeff Garzik <[EMAIL PROTECTED]> 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
Quoting David Miller ([EMAIL PROTECTED]):
> From: [EMAIL PROTECTED] (Eric W. Biederman)
> Date: Sat, 23 Jun 2007 11:19:34 -0600
>
> > Further and fundamentally all a global achieves is removing the need
> > for the noise patches where you pass the pointer into the various
> > functions. For long
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Sun, 24 Jun 2007 06:58:54 -0600
> I am convinced I can keep network namespaces something that is so
> trivial and obvious to get right you won't have to pay attention
> to them.
Ok then, I'll hold you to this when you post the rest of your
impleme
David Miller <[EMAIL PROTECTED]> writes:
> From: [EMAIL PROTECTED] (Eric W. Biederman)
> Date: Sat, 23 Jun 2007 15:41:16 -0600
>
>> If you want the argument to compile out. That is not a problem at all.
>> I dropped that part from my patch because it makes infrastructure more
>> complicated and t
David Miller <[EMAIL PROTECTED]> writes:
> From: [EMAIL PROTECTED] (Eric W. Biederman)
> Date: Sat, 23 Jun 2007 16:56:49 -0600
>
>> 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
> "DM" == David Miller <[EMAIL PROTECTED]> writes:
DM> Containers are I believe a step backwards, and we're better than
DM> that.
Are there any alternative proposals?
I guess it would be a start if you could run processes with a
different policy table as default. Ideally traffic from those
p
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Sat, 23 Jun 2007 16:56:49 -0600
> 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.
By your very admission the only appropriate use
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Sat, 23 Jun 2007 15:41:16 -0600
> If you want the argument to compile out. That is not a problem at all.
> I dropped that part from my patch because it makes infrastructure more
> complicated and there appeared to be no gain. However having a typ
From: Benny Amorsen <[EMAIL PROTECTED]>
Date: 23 Jun 2007 23:22:38 +0200
> Policy routing just doesn't cut it; it's cumbersome to set up, limited
> to 256 tables
False.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordo
Eric W. Biederman wrote:
Jeff Garzik <[EMAIL PROTECTED]> 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
Jeff Garzik <[EMAIL PROTECTED]> 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
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 o
David Miller <[EMAIL PROTECTED]> writes:
> From: [EMAIL PROTECTED] (Eric W. Biederman)
> Date: Sat, 23 Jun 2007 11:19:34 -0600
>
>> Further and fundamentally all a global achieves is removing the need
>> for the noise patches where you pass the pointer into the various
>> functions. For long term
> "DM" == David Miller <[EMAIL PROTECTED]> writes:
DM> To be honest I think this form of virtualization is a complete
DM> waste of time, even the openvz approach.
You are only considering the security values of OpenVZ. Where I work,
OpenVZ and Linux-vserver are used for their ability to clean
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Sat, 23 Jun 2007 11:19:34 -0600
> Further and fundamentally all a global achieves is removing the need
> for the noise patches where you pass the pointer into the various
> functions. For long term maintenance it doesn't help anything.
I don't ac
Eric W. Biederman wrote:
So it may be that we can cover your scenario. However it is just
enough off of the beaten path that I'm not going to worry about it
the first time through. It looks like it is a very small step from
where I am at to where you want to be. So you may be able to cook
up s
Ben Greear <[EMAIL PROTECTED]> writes:
> Any chance it could allow one to use a single threaded, single process and do
> something like
> int fd1 = socket(, namespace1);
> int fd2 = socket(, namespace2);
>
> Or, maybe a sockopt or similar call to move a socket into a particular
> namespace
Carl-Daniel Hailfinger <[EMAIL PROTECTED]> writes:
> Can one namespace DoS other namespaces' access to the routing cache?
> Two scenarios come to mind:
> * provoking hash collisions
> * lock contention (sorry, haven't checked whether/how we do locking)
My initial expectation is that the protectio
On 23.06.2007 19:19, Eric W. Biederman wrote:
> Patrick McHardy <[EMAIL PROTECTED]> writes:
>
>> Eric W. Biederman wrote:
>
>>> Depending upon the data structure it will either be modified to hold
>>> a per entry network namespace pointer or it there will be a separate
>>> copy per network namesp
Eric W. Biederman wrote:
Ben Greear <[EMAIL PROTECTED]> writes:
Will we be able to have a single application be in multiple name-spaces?
A single application certainly. But then an application can be composed
of multiple processes which can be composed of multiple threads.
In my cu
Stephen Hemminger wrote:
Will we be able to have a single application be in multiple name-spaces?
That would break the whole point of namespaces...
I was hoping that I could open a socket in one name-space and another in
another name
space, and send traffic between them, within a si
Patrick McHardy <[EMAIL PROTECTED]> writes:
Depending upon the data structure it will either be modified to hold
a per entry network namespace pointer or it there will be a separate
copy per network namespace. For large global data structures like
the ipv4 routing cache hash table
Stephen Hemminger <[EMAIL PROTECTED]> writes:
> On Sat, 23 Jun 2007 08:20:40 -0700
> Ben Greear <[EMAIL PROTECTED]> wrote:
>
>> Patrick McHardy wrote:
>> > Eric W. Biederman wrote:
>> >
>> >> -- The basic design
>> >>
>> >> There will be a network namespace structure that holds the global
>> >>
Eric W. Biederman wrote:
> Patrick McHardy <[EMAIL PROTECTED]> writes:
>
>>I believe OpenVZ stores the current namespace somewhere global,
>>which avoids passing the namespace around. Couldn't you do this
>>as well?
>
>
> It sucks. Especially in the corner cases. Think macvlan
> with the real
On Sat, 23 Jun 2007 08:20:40 -0700
Ben Greear <[EMAIL PROTECTED]> wrote:
> Patrick McHardy wrote:
> > Eric W. Biederman wrote:
> >
> >> -- The basic design
> >>
> >> There will be a network namespace structure that holds the global
> >> variables for a network namespace, making those global var
Ben Greear <[EMAIL PROTECTED]> writes:
> Patrick McHardy wrote:
>> Eric W. Biederman wrote:
>>
>>> -- The basic design
>>>
>>> There will be a network namespace structure that holds the global
>>> variables for a network namespace, making those global variables
>>> per network namespace.
>>>
>>> O
Patrick McHardy <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> -- The basic design
>>
>> There will be a network namespace structure that holds the global
>> variables for a network namespace, making those global variables
>> per network namespace.
>>
>> One of those per network names
Patrick McHardy wrote:
Eric W. Biederman wrote:
-- The basic design
There will be a network namespace structure that holds the global
variables for a network namespace, making those global variables
per network namespace.
One of those per network namespace global variables will be the
loopb
Eric W. Biederman wrote:
> -- The basic design
>
> There will be a network namespace structure that holds the global
> variables for a network namespace, making those global variables
> per network namespace.
>
> One of those per network namespace global variables will be the
> loopback device.
Currently all of the prerequisite work for implementing a network
namespace (i.e. virtualization of the network stack with one kernel)
has already been merged or is in the process of being merged.
Therefore it is now time for a bit of high level design review of
the network namespace work and tim
38 matches
Mail list logo
