[Devel] Re: [RFC][PATCH 1/5] Virtualization/containers: startup

Kirill Korotaev dev at sw.ru
Mon Feb 6 01:00:08 PST 2006


>>I think that a patch like this - particularly just the 1/5 part - makes 
>>total sense, because regardless of any other details of virtualization, 
>>every single scheme is going to need this.
> I strongly disagree with this approach.  I think Al Viro got it
> right when he created a separate namespace for filesystems.  
These patch set introduces separate namespaces as those in filesystems.
What exactly you don't like in this approach? Can you be more specific?

> First this presumes an all or nothing interface.  But that is not
> what people are doing.  Different people want different subsets
> of the functionality.   For the migration work I am doing having
> multiple meanings for the same uid isn't interesting.
What do you mean by that? That you don't care about virtualization of 
UIDs? So your migration doesn't care at all whether 2 systems have same 
uids? Do you keep /etc/passwd in sync when do migration?
Only full virtualization allows to migrate applications without bugs and 
different effects.

> Secondly by implementing this in one big chunk there is no
> migration path when you want to isolate an additional part of the
> kernel interface.
> 
> So I really think an approach that allows for incremental progress
> that allows for different subsets of this functionality to
> be used is a better approach.  In clone we already have
> a perfectly serviceable interface for that and I have
> seen no one refute that.  I'm not sure I have seen anyone
> get it though.
Just introduce config option for each virtualization functionality. 
That's it.

> My apologies for the late reply I didn't see this thread until
> just a couple of minutes ago.  linux-kernel can be hard to
> follow when you aren't cc'd.
> 
> 
> Patches hopefully sometime in the next 24hours.   So hopefully
> conversation can be carried forward in a productive manner.
Ok. I will remake them either :)

Kirill





More information about the Devel mailing list