2011/8/24 Lennart Poettering :
> On Wed, 24.08.11 14:38, Stef Bon (stef...@gmail.com) wrote:
>
>>
>> Please let me explain why I think this is strange to me:
>>
>> in line 713 there is a call to clone, so here the cloned child process
>> has it's own namespace.
>>
>> in line 759 all the submount li
On Wed, 24.08.11 14:38, Stef Bon (stef...@gmail.com) wrote:
>
> Please let me explain why I think this is strange to me:
>
> in line 713 there is a call to clone, so here the cloned child process
> has it's own namespace.
>
> in line 759 all the submount like proc, dev and sys are done on the
>
Please let me explain why I think this is strange to me:
in line 713 there is a call to clone, so here the cloned child process
has it's own namespace.
in line 759 all the submount like proc, dev and sys are done on the
directory to change to.
in line 775 the mount is done were talking about, us
On Wed, 24.08.11 11:41, Stef Bon (stef...@gmail.com) wrote:
>
> I see, but why the MS_MOVE?
In the namespace we are not interested anymore in the original mount. We
want to move it to our root dir.
> As I already tried to explain, a move is a little bit strange, you do
> not want to move the ro
I see, but why the MS_MOVE?
As I already tried to explain, a move is a little bit strange, you do
not want to move the root.
Does the combination MS_BIND | MS_MOVE first do a bind, and moves that
bind to the desired location?? If this is the case, it makes more
sense.
Stef
2011/8/23 Lennart Po
On Mon, 22.08.11 16:15, Stef Bon (stef...@gmail.com) wrote:
> Why the combination MS_BIND | MS_MOVE here??
> A move is a little bit confucing, since a move of the root, while the
> subirectories are already mounted.
> It looks more a bit to make the new namespace consistent or something like
> th
