Re: [uml-devel] RE: Explaination of system call function flow in TT mode

[Blaisorblade <blaisorblade@yahoo.it>]

On Wednesday 02 February 2005 16:29, Alex LIU wrote:
> Hi,Blaisorblade. You wrote:
> >do_syscall is called, and then this is done:
> >
> >                                sig = SIGUSR2;
> >                                tracing = 0;
> >... after, this saves the new tracing value inside "task", which is a
> > struct task_struct.
> >
> >                       set_tracing(task, tracing);
Pre-question: I hope for you that you use a ctags/etags enabled editor (or at 
least LXR) to help in source browsing, otherwise you'll get lost.

There is more than one good introduction about ctags (which is supported at 
least by Vim and Emacs, and maybe even by Kate).

> But what's the exact meaning of the task in the tracer function? It is
> defined as:
>
>  task = cpu_tasks[proc_id].task
>
> Is it the task struct of the traced thread?

Yes, it is... proc_id is the ID of the virtual processor (it will be always 0 
on a uniprocessor UML instance). 

If you look at the comment before that line (when it is re-executed) and at 
do_proc_op(), you'll see that when doing an exec the host process is changed.

> What's the difference between "task->pid" and
> "task->thread.mode.tt.extern_pid"?

> I know in TT mode every thread in UML 
> will has a corresponding thread in host.

Yes, and while task->pid (which is a field also existing in i386 Linux) is the 
pid you see inside UML for that task, extern_pid is the pid of the matching 
host thread.

> But I don't know the exact 
> relationship between them.

It's 1-1 I think, and the code does not show sign of working otherwise (even 
if, probably, it could be changed to make sure that multiple threads have 
only one corresponding host thread)...

I don't know the relation between tracer() running instances and childs... in 
SKAS mode, the scheduler does a context switch (through sigsetjmp() / 
siglongjmp()) between multiple tracers (i.e. ; when  a new tracer is 
scheduled inside UML, it makes the host process switch to the right thread 
and execute it.

Instead, in TT mode there is just one tracer, which does a waitpid() on every 
thread... a process is scheduled away by making it wait on a pipe 
(task->thread.mode.tt.switch_pipe[]).

> And I didn't found how UML creat the 
> corresponding thread in host.

To create a process (with fork(), vfork() or clone()) the do_fork() call is 
executed with appropriate flags...

The arch-dependent hook for the process creation is copy_thread()... and 
copy_thread_tt() calls start_fork_tramp() which creates the host thread with 
clone (actually with 2 clone calls, I dunno why) and returns the pid of the 
newly created thread, which is then assigned inside copy_thread to 
task->.....extern_pid.

Also notice the messages sent with SIGUSR1 named by OP_* (OP_FORK, OP_EXEC...)
> Thanks a lot!
Well, this was also an occasion to learn these things myself (I didn't need 
understanding it in detail until now since I've not been working on TT code, 
I had a feeling of what happened), so thanks to you.

Regards
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade




-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel