O kernel é um processo?


30
  1. No Linux, sempre dizemos que o primeiro processo é init(pid == 1). Mas por que não é o kernel (inicialização) que configura o sistema e cria o initprocesso. O kernel é um processo?
  2. Sabemos que todos os threads do espaço do usuário estão enraizados no processo init. E o agendador e outras coisas do kernel, como gerenciamento de memória?

Basicamente, o que me confunde é a estrutura do kernel. Se é um processo, é um processo único ou consiste em vários processos?

Respostas:


19

Respostas curtas:

  1. Não, não é um processo
  2. Os threads do usuário não estão enraizados no init.

Init é apenas o primeiro processo; ele não gerencia nenhum processo ou encadeamento. Ele cria alguns, usando o fork do syscalls do kernel () e o exec.

Eu acho que você tem uma idéia confusa do que é um processo. não significa apenas um pouco de código de execução. Sim, o kernel é executado antes do init (e o carregador de inicialização antes mesmo). Mas um 'processo' tem uma definição específica de:

  • Executa no espaço do usuário
  • Executa com um ID do processo
  • Muitas interações precisam passar pelo kernel
  • Todos os recursos precisam vir do kernel
  • Precisa ser agendado pelo kernel

Assim, uma vez que o kernel é inicializado, ele executa o init, que gera quaisquer outros processos que sua configuração solicite.

No que diz respeito ao número 2, todo o material do kernel está, bem, no kernel. Pense no kernel como uma grande área de código. Novamente, não um processo, mas um grande blob de código. Partes do kernel lidam com gerenciamento de memória, partes dele com partes de agendamento de si mesmo (como drivers, etc.) e partes dele com processos de agendamento.


3
Gostaria de saber se o OP sabe o suficiente para ter sua mente soprada por micro kernels? Não incluí minha edição porque achei que seria uma distração, pelo menos.
new123456

4
Uma maneira de pensar no kernel é como uma biblioteca gigantesca, com pontos de entrada (o sistema chama) para solicitar que ele faça algo em seu nome. Outra visão complementar é que fica aguardando a manipulação dos eventos, seja uma chamada do sistema do usuário ou uma interrupção do hardware (por exemplo, chegou um novo pacote de rede). Algumas coisas levam tempo para serem manipuladas, então o kernel apenas envia o trabalho para os threads internos e retorna para quem ligou.
vonbrand

15

O kernel realmente não se comporta como um processo. Ele não é agendado, é executado em nome de um processo (chamado de contexto do processo ou contexto do usuário) ou como resultado de uma interrupção ou exceção (o chamado contexto de interrupção).

Dito isto, o kernel do Linux gera threads do kernel para executar algumas tarefas ou para evitar executar algo no contexto de interrupção por muito tempo (é o que o thread do ksoftirqd faz, evitando latências excessivas que podem levar, por exemplo, a perda de áudio, ...) .

Você pode ver os threads do kernel na saída do pscomando. Eles são facilmente identificados: o nome está entre colchetes. Alguns deles executam uma instância por CPU, a CPU é identificada com um número após uma barra, então [ksoftirqd / 0] é a instância do ksoftirqd na CPU 0.


1

Existem conceitos nos micro-kernels em que várias partes do kernel são de fato processos com o sentinela primário, na maioria das vezes, gerencia o IPC.

Linux - para melhor ou para pior - não é um sistema de microssistema.


1

Não, não é ... O kernel (e as extensões do kernel) são carregados diretamente na memória. Se houver um código inseguro no kernel, nada ficará entre ele e um grande problema.

Além disso, o kernel basicamente executa / alterna entre processos. Obviamente, algo que realmente executa processos não será um processo em si.

(tl; dr 1. não 2. parte do kernel / sua extensão)


0

ninjalj escreveu: "O kernel não se comporta realmente como um processo. Não é agendado"

Bem, existe o processo inativo (basicamente o pid 0, embora não seja mostrado em nenhum lugar) que é agendado e quase sempre em um estado executável.


Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.