Thanks Rob,
Here ABC_stack or XYZ_stack mean different vendor networking stack, these two
network stack want to run in one namespace as tow different process.
Similarly I have to create N number of namespaces.
Main()
{
int flags= CLONE_NEWNS| CLONE_NEWNET;
pid1= clone(do_clone, stack, flags ,&clone_arg)
}
do_clone()
{
int flags=0;
pid2= clone(do_clone2, stack, flags ,&clone_arg)
}
Does this way both pid1 and pid2 run in the same namespace? Or in the min
itself I can run clone() with flags=0
Thnaks
Mahesh
-----Original Message-----
From: Rob Landley [mailto:rland...@parallels.com]
Sent: Thursday, February 17, 2011 3:03 PM
To: Maheswara Reddy C - ERS, HCL Tech
Cc: lxc-devel@lists.sourceforge.net
Subject: Re: [lxc-devel] Two process on a same namespcae with clone()
On 02/17/2011 12:48 AM, Maheswara Reddy C - ERS, HCL Tech wrote:
> Hi,
>
> Fine,fork() always create new process, but here both the processes are
> different stacks.
Different processes have different stacks, yes. Even if you use
pthread_create() each thread still has its own stack. That's not one of
the resources you have the option to share, because it just doesn't work
that way...
(Well, ok, vfork() does but it has to freeze the parent process until
the child calls fork() or _exit() in order to make that work, and the
child can't write to local variables or return from the calling function
or else it trashes the parent's stack. So they only "share" the
resource on the condition that they can't both use it at the same time,
and it's really an implementation detail of nommu systems.)
> If I use foek(), it will run the same instance of ABC_stack ,rather XYZ_stack.
The stack pointer, a register in the CPU, will point at a different
address in DRAM, presumably mapping through different page tables to
different physical memory. This is normal, isn't it?
I've heard some managers use the phrase "software stack" as a marketing
term to refer to a root filesystem, or a set of installed packages, or
occasionally a package management system, or... it's not really well
defined, actually, it's a marketing term for glossy brochures and sales
meetings that has nothing to do with engineering.
I've also heard "network stack" to describe ipv4 on top of an underying
transport like ethernet or ppp.
Although "stack" by itself has existing meaning going back half a
century, it's possible you mean one of those other types of stacks and
simply aren't communicating clearly? (But even assuming that's what you
intend that word to mean, it doesn't help me understand the rest of your
message...)
> Shall we call the clone() with out CLONE_NEW* flags, so that it will run in
> the same name space.
Um, yes? If you want two processes to have the same namespace, that's
the default behavior, so if you want the default behavior don't set the
flag that would change that default behavior when creating a new process.
Or if you mean "Under the covers fork(), vfork(), and thread creation
are all implemented via the clone() system call", then the answer there
is yes too...
For many years you've been able to specify that they could share things
like heap and filehandles with various flags, and these days you can
specify that they share _less_ than the default amounts using namespace
flags. But you are not required to use those flags when creating new
processes...
I'm really not sure what you're asking here.
> See the below scenario, multiple namespaces each namespace has to run two
> different processes.
>
> Main
> {
This runs in an initial context which includs various namespaces.
> Ns1=Clone(CLONE_NEWNS) ----> process1 (ABC_Stack)
> |
> . ---------->Process2 (XYZ_stack)
That would create a new child with its own mount namespace. So now you
have two mount namespaces: the parent's and the one belonging to the new
child process.
This second mount namespace starts as a clone of the parent process's
namespace, I.E. the new process's /proc/mounts list is initialized with
a copy of the parent's /proc/mounts contents, but they are different
lists and changes made to that copy (mounting an unmounting new
filesystmes) won't affect the parent, and vice versa. (Don't ask me
about -o remount, changing attributes of existing mounts fiddles with
superblocks and those are shared. Since you can make a bind mount read
only these days I think VFS flags are per-mountpoint attributes rather
than per-superblock attributes now, but don't quote me on that...)
But all this doesn't do anything like a chroot, it just says that any
new mount/umount aren't shared with processes outside this namespace.
So to start with the new process _looks_ like it's using the same mount
tree as the old process, because the copy is initialized in an identical
state. (Thus if you did mean the pointy-hair "software stack" phrase
above... your child is still in the same root filesystem. If your
parent was running in a debian root filesystem, the child is still
running in that debian root filesystem.)
> Ns2=Clone(CLONE_NEWNS) ----> process1 (ABC_Stack)
> |
> . ---------->Process2 (XYZ_stack)
This creates a new process inside a third mount namespace.
> .
> .ns100clone(CLONE_NEWNS)
This creates a new process inside a fourth independent mount namespace.
It looks like the computer is doing what you asked, and apparently
you're unhappy with this. I have no idea what you _want_ to ask the
computer to do, becuase you're not clearly asking _me_ either.
If you want to create more processes in any of those three new
namespaces, have the existing child process already in that namespace be
the one to spawn a new process, which would share that namespace
Let me go back to your original question and I'll try to figure out what
question you're trying to ask.
>> I want to run the two process on same name space, shall it possible
>> using the clone()
Running two processes in the same namespace is the default behavior.
When new processes are created, they share their parent's namespace.
Creating new namespaces is associated with creating new procesess to
live in those namespaces. (You can't have a namespace with no processes
in it.)
This is conceptually similar to the way creating a new heap or sharing
the existing heap. If you CLONE_VM then you share the parent's memory
mappings. If you clone without that flag you get your own set of page
tables implementing your own virtual memory mappings.
It is theoretically possible to read from or write to an existing
process's memory mappings via ptrace(). It's kind of disgusting to
depend on that as part of an application design, but debuggers and
rootkits do it all the time. This does _not_ mean that your postgresql
daemon adds a new thread to your apache daemon by having spawning the
postgresql process spawn a thread and then transfer that thread to
apache. It doesn't work that way. You use an IPC mechanism to have
postgresql request apache to spawn its own new thread.
Note that according to the clone man page the CLONE_NEWNS flag was
introduced circa 2.4.19 (which predates the LXC project by a number of
years), and then the 2.6 series updated it when the shared subtrees
patch was merged:
http://lwn.net/Articles/159077/
If you simply want more granular control over what gets shared and what
doesn't, look at the shared subtrees stuff, and the --make-unbindable
and --make-shared flags to current version of the mount command line
utility.
Rob
::DISCLAIMER::
-----------------------------------------------------------------------------------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and intended
for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates.
Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect the
opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of
this message without the prior written consent of the author of this e-mail is
strictly prohibited. If you have
received this email in error please delete it and notify the sender
immediately. Before opening any mail and
attachments please check them for viruses and defect.
-----------------------------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
