Tejun Heo wrote:
> Hello,
> 
> Okay, some questions.
> 
> * What do you think about not allowing duplicate names across different
> tags?  ie. there's only one ethX anywhere but it's visible only in a
> specific namespace (and maybe in the default global one).  Or does
> everyone need its own eth0.  If this is acceptable, the problem becomes
> _much_ simpler.

at least on checkpoint/restart names should be restored as is
and conflicts are unavoidable.
this includes ifindex as well by the way.

> * I think we can do away with the magic tag and use a pointer to
> vfsmount instead.  So, a process which wants to be in certain namespace
> can bind-mount /sysfs to its own /sysfs and make needed sysfs nodes
> bound to the mount.  Does this sound okay?  Such process should probably
> be in its own chrooted environment to function properly.
> 
> * I haven't really followed the containers thread.  Do people generally
> agree on including it in mainline when we have all the fancy
> virtualization stuff?

Thanks,
Kirill
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers

Hi,

On 26.07.2007 10:00, Tejun Heo wrote:
> Okay, some questions.
> 
> * What do you think about not allowing duplicate names across different
> tags?  ie. there's only one ethX anywhere but it's visible only in a
> specific namespace (and maybe in the default global one).  Or does
> everyone need its own eth0.  If this is acceptable, the problem becomes
> _much_ simpler.

Duplicating names across different namespaces (eth0 for everyone) is a
feature which allows me to use a very similar configurations for
different namespaces.
There's also a security argument saying that one namespace shouldn't be
able to infer information about other namespaces. If an interface name
must not be reused across namespaces you can enumerate the obvious
interface name list from any namespace and find out which interface
names are used by other namespaces. I'm not suggesting that this
argument is valid, but it needs to be considered and if we decide it is
invalid, we should document why.

Regards,
Carl-Daniel

_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers

Tejun Heo <htejun@gmail.com> writes:

> Hello,
>
> Okay, some questions.
>
> * What do you think about not allowing duplicate names across different
> tags?  ie. there's only one ethX anywhere but it's visible only in a
> specific namespace (and maybe in the default global one).  Or does
> everyone need its own eth0.  If this is acceptable, the problem becomes
> _much_ simpler.

I agree, and unfortunately this is the problem I am really trying to solve.
Everyone namespace has it's own loopback interface.

> * I think we can do away with the magic tag and use a pointer to
> vfsmount instead.  So, a process which wants to be in certain namespace
> can bind-mount /sysfs to its own /sysfs and make needed sysfs nodes
> bound to the mount.  Does this sound okay?  Such process should probably
> be in its own chrooted environment to function properly.

That would actually be preferable.

> * I haven't really followed the containers thread.  Do people generally
> agree on including it in mainline when we have all the fancy
> virtualization stuff?

Generally.  Assuming all of the i's are dotted and all of the t's crossed.

Eric
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers

Hello, Eric.

Tejun Heo wrote:
> Eric W. Biederman wrote:
>> Further while there are a few little nits I think mostly Tejun is 
>> mostly objecting to the fundamental complexity of the problem rather
>> then to things that can be fixed by a cleaner implementation.
> 
> Oh well, I don't think so but I might be wrong.

And I'm wrong.  Mine didn't turn out to be much cleaner than yours.
What I did was (still broken)...

* No shadower/shadowee.  Each dentry is tagged.
* dentries of tagged sd's are taken out of dcache and always go through
->lookup() where the correct sd is looked up considering the current tag.

Tagging and adding new entries could be done rather cleanly but shooting
down existing dentries on rename/move turned out to be a mess.  Things
will be much simpler if no sysfs dentry is hashed on dcache and always
go through ->lookup() but that will hurt big machines.

The basic problem here is that dcache layer doesn't allow different
views and sysfs shadow is trying to work behind its back.  I don't think
this is a viable approach.  Both implementations bend too many rules and
 are too fragile.  It will be a genuine pain in the ass to maintain.

Sorry that I can't come up with an alternative but NACK.

-- 
tejun
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers

Tejun Heo wrote:
> Hello, Eric.
> 
> Tejun Heo wrote:
> 
>>Eric W. Biederman wrote:
>>
>>>Further while there are a few little nits I think mostly Tejun is 
>>>mostly objecting to the fundamental complexity of the problem rather
>>>then to things that can be fixed by a cleaner implementation.
>>
>>Oh well, I don't think so but I might be wrong.
> 
> 
> And I'm wrong.  Mine didn't turn out to be much cleaner than yours.
> What I did was (still broken)...
> 
> * No shadower/shadowee.  Each dentry is tagged.
> * dentries of tagged sd's are taken out of dcache and always go through
> ->lookup() where the correct sd is looked up considering the current tag.
> 
> Tagging and adding new entries could be done rather cleanly but shooting
> down existing dentries on rename/move turned out to be a mess.  Things
> will be much simpler if no sysfs dentry is hashed on dcache and always
> go through ->lookup() but that will hurt big machines.
> 
> The basic problem here is that dcache layer doesn't allow different
> views and sysfs shadow is trying to work behind its back.  I don't think
> this is a viable approach.  Both implementations bend too many rules and
>  are too fragile.  It will be a genuine pain in the ass to maintain.
> 
> Sorry that I can't come up with an alternative but NACK.

Imho then OpenOVZ approach with multiple sysfs trees is better.
it allows to use cached dentries with moultiple sysfs mounts
each having different view.
It also allows to hide hw-related entries and events from the containers
and has quite little modifications in the code.

Thanks,
Kirill

_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers

Hello, Kirill.

Kirill Korotaev wrote:
> Imho then OpenOVZ approach with multiple sysfs trees is better.
> it allows to use cached dentries with moultiple sysfs mounts
> each having different view.
> It also allows to hide hw-related entries and events from the containers
> and has quite little modifications in the code.

I thought something like supermount plus some twists or fuse based sysfs
proxy would fit better.  Dunno whether or how uevent and polling stuff
can work that way tho.  Note that sysfs no longer keeps dentries and
inodes pinned.  It might make the shared dentry stuff harder.

Thanks.

-- 
tejun
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers