[Devel] [PATCH 10/12] L2 network namespace: playing with pass-through device

[Herbert Poetzl]

On Tue, Dec 12, 2006 at 04:50:50PM +0100, Daniel Lezcano wrote:
> Dmitry Mishin wrote:
> > On Tuesday 12 December 2006 17:19, Daniel Lezcano wrote:
> >> Dmitry Mishin wrote:
> >>
> >>>>>> Why do yo need to have a child list and sibling list ?
> >>>>> Because of the level2<->level3 hierarchy, for example.
> >>>> This hierarchy doesn't exist with ns->parent ? Do you have an example
> >>>> when the hierarchy should be used ? I mean when we need to browse from
> >>>> l2 -> l3 ?
> >>> For example, to check that new ifaddr is already used by child l3 namespace.
> >> The devinet isolation does already do that, you can not add a new ifaddr 
> >> if it already exists. Do you have another example ?
> > Could devinet isolation provide ifaddrs list with namespaces?
> > What will be with child namespaces if you decide to destroy parent namespace?
> > If we decide to destroy them, than how we could get their list?
> > It is a question of flexibility and easy management.
> > Why do you want to remove this code? 
> 
> I don't want to especially remove this code, I just want to understand 
> what it does and why. If it appears to be useless, let's remove it, if 
> it appears to be useful, let's keep it.
> 
> By the way, what is the meaning on destroying the namespaces directly, 
> is it not the kref mechanism which needs to do that ? For example, if 
> you  create a l2 namespace and after you create l3 namespaces. You want 
> to destroy the l2 namespace, the l2 namespace should stay "zombie" until 
> all the l3 namespaces exit. If you need to wipe out all the namespaces, 
> you should destroy all the related namespaces' ressources, like killing 
> all processes inside it. The namespaces will "put" their respective kref 
> and will trigger the freeing of the ressources.

networking (mostly sockets) will probably require
some mechanism to 'zap' them, ignoring the defined
timeouts. otherwise the spaces could hang around
for quite a while waiting for some response, which
might never come ...

but that should not be _that_ important right now

best,
Herbert

> _______________________________________________
> Containers mailing list
> Containers at lists.osdl.org
> https://lists.osdl.org/mailman/listinfo/containers
_______________________________________________
Containers mailing list
Containers at lists.osdl.org
https://lists.osdl.org/mailman/listinfo/containers