Como o kernel do Linux sabe qual processo fez uma chamada do sistema? [fechadas]

Question

Digamos que um processo fez uma chamada de sistema para abrir um arquivo, quando o kernel Linux executa esta chamada de sistema, o kernel Linux deve adicionar o fd para o arquivo aberto ao processo fd table que fez a chamada do sistema .

Como o kernel do Linux sabe qual processo fez esse sistema chamar quando os argumentos passados para a chamada do sistema não incluem o PID?

    

Answer 1

Uma chamada do sistema kernel é executada dentro do contexto do processo de chamada, apenas em um nível de privilégio diferente e com infraestrutura de suporte diferente. O kernel do Linux tem uma variável por CPU que rastreia o processo atual, current_task ; Ele usa isso sempre que precisa saber qual é o processo atual. Em uma determinada CPU, a tarefa atual só é alterada quando o planejador decide, e a mudança de contexto se encarrega de salvar todas as informações necessárias para que o kernel possa acompanhar o que está acontecendo onde.

O LWN tem alguns artigos úteis em syscalls, Anatomia de uma chamada de sistema parte 1 e parte 2 . Eles explicam como as chamadas do sistema são definidas e como elas são executadas, embora talvez não com detalhes suficientes para responder à sua pergunta, pois elas não abordam a transição do espaço do usuário para o espaço do kernel em detalhes. mas isso é "apenas" qualquer suporte de transição baseado em armadilhas disponível na CPU.

    

Answer 2

Sua pergunta sugere que o aplicativo conhece e gerencia seu próprio PID e deve passá-lo ao kernel para que o último saiba como fazer seu trabalho. Este é um equívoco comum. A maneira como essa informação flui é, na verdade, o contrário. Um processo não precisa saber ou armazenar seu ID de processo, tabelas de descritor de arquivo e similares. Se quiser obter informações sobre eles, precisará recuperá-lo do kernel usando chamadas de sistema como getpid , ioctl e similares.

Enquanto o kernel é feito de um grande monte de linhas de código-fonte, não é um único programa rodando ao lado dele, com programas de área de usuário vivendo do outro lado e enviando pedidos para o kernel como um navegador da web está enviando solicitações para um servidor da web. Os parâmetros de chamada do sistema e o valor de retorno não são a única informação fluindo entre o aplicativo e o kernel e todas as informações de baixo nível sobre cada thread e processo, seja qual for seu estado (rodando, esperando, dormindo ...), armazenado na memória do kernel.

Você deve ver uma grande parte do código do kernel como uma grande biblioteca, ligada a cada processo em execução no sistema. Quando um processo (na verdade, um segmento) executa uma chamada de sistema, ele simplesmente mergulha nessa biblioteca especial e obtém superpoderes por um pequeno período de tempo. Mas ainda é o mesmo thread, então o kernel tem todas as informações necessárias para identificar e gerenciar o encadeamento em execução como seu dono, grupo, pid, tabelas de descritores de arquivos e assim por diante, porque é precisamente o kernel (aqui o agendador) que atribui encadeamentos a CPUs disponíveis (v).