Eric W. Biederman wrote:
When an outgoing packet has the loopback destination addres, the
skbuff is filled with the network namespace. So the loopback packets
never go outside the namespace. This approach facilitate the migration
of loopback because identification is done by network namespace and
Daniel Lezcano <[EMAIL PROTECTED]> writes:
> Andrey Savochkin wrote:
>
>> Ok, fine.
>> Now I'm working on socket code.
>> We still have a question about implicit vs explicit function parameters.
>> This question becomes more important for sockets: if we want to allow to use
>> sockets belonging to
James Morris <[EMAIL PROTECTED]> writes:
> On Wed, 28 Jun 2006, Daniel Lezcano wrote:
>
>> The attached patch can have some part interesting for you for the socket
>> tagging. It is in the IPV4 isolation (part 5/6). With this and the private
>> routing table you will probably have a good IPV4 isol
On Wed, 28 Jun 2006, Daniel Lezcano wrote:
> The attached patch can have some part interesting for you for the socket
> tagging. It is in the IPV4 isolation (part 5/6). With this and the private
> routing table you will probably have a good IPV4 isolation.
Please send patches inline, do not attac
Andrey Savochkin wrote:
Ok, fine.
Now I'm working on socket code.
We still have a question about implicit vs explicit function parameters.
This question becomes more important for sockets: if we want to allow to use
sockets belonging to namespaces other than the current one, we need to do
somet
On Wed, Jun 28, 2006 at 12:14:41PM -0600, Eric W. Biederman wrote:
> Andrey Savochkin <[EMAIL PROTECTED]> writes:
>
> > On Wed, Jun 28, 2006 at 10:51:26AM -0600, Eric W. Biederman wrote:
> >> Andrey Savochkin <[EMAIL PROTECTED]> writes:
> >>
> >> > One possible option to resolve this question is
Andrey Savochkin <[EMAIL PROTECTED]> writes:
>> In a slightly different vein your second patch introduced a lot
>> of #ifdef CONFIG_NET_NS in C files. That is something we need to look
>> closely
>> at.
>>
>> So I think the abstraction that we use to access per network namespace
>> variables ne
Andrey Savochkin <[EMAIL PROTECTED]> writes:
> Hi Eric,
>
> On Wed, Jun 28, 2006 at 10:51:26AM -0600, Eric W. Biederman wrote:
>> Andrey Savochkin <[EMAIL PROTECTED]> writes:
>>
>> > One possible option to resolve this question is to show 2 relatively short
>> > patches just introducing namespace
Andrey Savochkin <[EMAIL PROTECTED]> writes:
>> A general pattern that happens in cleanups is the discovery
>> that code using an old interface in a problematic way really
>> could be done much better another way. I didn't dig enough
>> to see if that was the case in any of the code that you chan
On Wed, Jun 28, 2006 at 09:22:40PM +0400, Andrey Savochkin wrote:
> Hi Eric,
>
> On Wed, Jun 28, 2006 at 10:51:26AM -0600, Eric W. Biederman wrote:
> > Andrey Savochkin <[EMAIL PROTECTED]> writes:
> >
> > > One possible option to resolve this question is to show 2
> > > relatively short patches j
Hi Eric,
On Wed, Jun 28, 2006 at 10:51:26AM -0600, Eric W. Biederman wrote:
> Andrey Savochkin <[EMAIL PROTECTED]> writes:
>
> > One possible option to resolve this question is to show 2 relatively short
> > patches just introducing namespaces for sockets in 2 ways: with explicit
> > function par
Andrey Savochkin <[EMAIL PROTECTED]> writes:
> Ok, fine.
> Now I'm working on socket code.
>
> We still have a question about implicit vs explicit function parameters.
> This question becomes more important for sockets: if we want to allow to use
> sockets belonging to namespaces other than the cu
Cedric Le Goater <[EMAIL PROTECTED]> writes:
> How that proposal differs from the initial Daniel's patchset ? how far was
> that patchset to reach a similar agreement ?
My impression is as follows. The OpenVz implementation and mine work
on the same basic principles of handling the network stack
"Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
> Quoting Eric W. Biederman ([EMAIL PROTECTED]):
>> > I think we're reaching the limits of namespaces. It would be much easier
>> > with a container id in each kernel object we want to isolate.
>>
>> Nope. Except for the fact that names are peculiar
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> > I think we're reaching the limits of namespaces. It would be much easier
> > with a container id in each kernel object we want to isolate.
>
> Nope. Except for the fact that names are peculiar (sockets, network
> device names, IP address, routes.
Cedric Le Goater <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>
>> Despite what it might look like unix domain sockets do not live in the
>> filesystem. They store a cookie in the filesystem that roughly
>> corresponds to the port number of an AF_INET socket. When you open a
>> socket
Hi Eric,
On Tue, Jun 27, 2006 at 10:20:32PM -0600, Eric W. Biederman wrote:
> Andrey Savochkin <[EMAIL PROTECTED]> writes:
[snip]
> > My first patchset covers devices but not sockets.
> > The only difference from what you're suggesting is ipv4 routing.
> > For me, it is not less important than dev
Hello,
Eric W. Biederman wrote:
> Thinking about this I am going to suggest a slightly different direction
> for get a patchset we can merge.
>
> First we concentrate on the fundamentals.
> - How we mark a device as belonging to a specific network namespace.
> - How we mark a socket as belonging
Eric W. Biederman wrote:
> Despite what it might look like unix domain sockets do not live in the
> filesystem. They store a cookie in the filesystem that roughly
> corresponds to the port number of an AF_INET socket. When you open a
> socket the lookup is done by the cookie retrieved from the f
Sam Vilain <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> In general it is possible to get file descriptors opened by someone
>> else because unix domain sockets allow file descriptor passing. Similarly
>> I think there are cases in both unshare and fork that allows you to sockets
>> o
Eric W. Biederman wrote:
> In general it is possible to get file descriptors opened by someone
> else because unix domain sockets allow file descriptor passing. Similarly
> I think there are cases in both unshare and fork that allows you to sockets
> open before you entered a namespace.
>
This
On Tue, Jun 27, 2006 at 10:33:48PM -0600, Eric W. Biederman wrote:
>
> Something to examine here is that if both network devices and sockets
> are tagged does that still allow implicit network namespace passing.
I think avoiding implicit network namespace passing expresses more
power/flexibility
Sam Vilain <[EMAIL PROTECTED]> writes:
> It sounds then like it would be a good start to have general socket
> namespaces, if it would merge more easily - perhaps then network device
> namespaces would fall into place more easily.
I guess I really see both sockets and devices as the fundamental
Andrey Savochkin <[EMAIL PROTECTED]> writes:
> Eric,
>
> On Tue, Jun 27, 2006 at 11:20:40AM -0600, Eric W. Biederman wrote:
>>
>> Thinking about this I am going to suggest a slightly different direction
>> for get a patchset we can merge.
>>
>> First we concentrate on the fundamentals.
>> - How
Andrey Savochkin wrote:
> On Tue, Jun 27, 2006 at 11:20:40AM -0600, Eric W. Biederman wrote:
>
>> Thinking about this I am going to suggest a slightly different direction
>> for get a patchset we can merge.
>>
>> First we concentrate on the fundamentals.
>> - How we mark a device as belonging to
Eric,
On Tue, Jun 27, 2006 at 11:20:40AM -0600, Eric W. Biederman wrote:
>
> Thinking about this I am going to suggest a slightly different direction
> for get a patchset we can merge.
>
> First we concentrate on the fundamentals.
> - How we mark a device as belonging to a specific network names
Thinking about this I am going to suggest a slightly different direction
for get a patchset we can merge.
First we concentrate on the fundamentals.
- How we mark a device as belonging to a specific network namespace.
- How we mark a socket as belonging to a specific network namespace.
As part of
27 matches
Mail list logo
