2013-04-16 6 views
11

In 3.8.x kernel e versione successiva, la definizione per run_init_process è cambiato.Nel kernel 3.8, come il primo processo utente viene commutato in modalità utente mentre kernel_execve viene rimosso

Quello che segue è la nuova definizione per run_init_proces nel kernel 3.8.

static int run_init_process(const char *init_filename) { 
     argv_init[0] = init_filename; 
     return do_execve(init_filename, 
       (const char __user *const __user *)argv_init, 
       (const char __user *const __user *)envp_init); } 

Rispetto alla definizione nel kernel 3.7.x e versione precedente.

static int run_init_process(const char *init_filename) { 
     argv_init[0] = init_filename; 
     return kernel_execve(init_filename, argv_init, envp_init); } 

La parte più critica in kernel_execve è che chiamerà la ret_from_kernel_execve, che passa nella modalità utente poi.

Nella nuova definizione, kernel_execve non c'è più. La mia domanda è come il primo processo utente passa alla modalità utente, allora.

+8

L'articolo [https://lwn.net/Articles/520227/] (nuovo/disegno kernel_thread execve di Al Viro) è molto utile. Il cambiamento principale si trova al * * copy_thread – hseagle

+1

A [URL corrente] di più (https://lwn.net/Articles/520227/). –

+1

@artlessnoise: in realtà, ha solo bisogno di imparare ad usare '<>' intorno ai suoi URL invece di '[]' ... – SamB

risposta

0

successo do_execv() imposta il processo current per eseguire il nuovo programma (ad esempio attraverso load_elf_binary()), e quindi ritorna 0-run_init_process(), che restituisce 0-kernel_init(), che restituisce anche 0, ed è stato chiamato come parte di:

kernel_thread(kernel_init, NULL, CLONE_FS | CLONE_SIGHAND); 

Questo è dove le regole dalla https://lwn.net/Articles/520227/ sono disponibili in: il nostro fn() è tornato 0 dopo un execve, così "il filo procederà nel contesto userland creato da quel execve".

Problemi correlati