Encadeamentos do kernel e endereço virtual do processo

Question

Se o kernel é gerado como encadeamentos e reside na memória, então como o comando ps poderia identificá-los se esses não são processos normais e eu dou a você mais uma olhada aqui:

root         2     0  0 févr.04 ?     00:00:00 [kthreadd]
root         3     2  0 févr.04 ?     00:00:01 [ksoftirqd/0]
root         5     2  0 févr.04 ?     00:00:00 [kworker/0:0H]

os tópicos do kernel, como vemos, têm as mesmas informações que os filhos do processo linux id, parent id (que é 0) e user owner (que é root)

Por favor, explique isso.

Então, se esses threads são executados de maneira diferente, como a CPU poderia dizer a diferença entre um thread do kernel e o executável ou biblioteca do Linux do processo na memória, eu preciso saber isso.

Outra pergunta: quando o compilador constrói o executável, cria um vma (endereço de memória virtual) que é usado pela CPU para alocar espaço de memória; como o compilador poderia gerar esses endereços?

Obrigado a vocês.

    

Answer 1

Eu não posso responder definitivamente à pergunta "threads do kernel" para Linux. Para o Windows, posso dizer que os "encadeamentos do kernel" são simplesmente encadeamentos criados a partir de alguma outra rotina do modo kernel, executando procedimentos que nunca entram no modo de usuário. Quando o planejador escolhe um encadeamento para execução, ele retoma seu estado anterior (usuário ou kernel, o que quer que tenha sido); a CPU não precisa "dizer a diferença". O encadeamento é executado no modo kernel porque é o que estava fazendo na última vez que estava sendo executado.

No Windows, elas geralmente são criadas com o chamado processo "System" como pai, mas na verdade podem ser criadas em qualquer processo. Então, no Unix eles podem ter um ID pai de zero? ou seja, pertencendo a nenhum processo? Isso realmente não importa a menos que o thread tenta usar recursos de nível de processo.

Quanto aos endereços atribuídos pelo compilador ... Existem algumas maneiras possíveis de pensar sobre isso. Uma parte disso é que o compilador realmente não escolhe endereços para muito de qualquer coisa; quase tudo que um compilador produz (em um ambiente moderno) é em termos de compensações. Uma determinada variável local está em algum deslocamento de onde o ponteiro da pilha será quando a rotina é instanciada. (Observe que as próprias pilhas estão em endereços atribuídos dinamicamente, assim como as alocações de heap são.) Um ponto de entrada de rotina está em algum deslocamento desde o início da seção de código em que está. Etc.

A segunda parte da resposta é que os endereços, como eles são, são atribuídos pelo vinculador, não pelo compilador. O que realmente apenas adia a pergunta - como isso pode ser feito? Por que eu acho que você quer dizer, como ele sabe quais endereços estarão disponíveis em tempo de execução? A resposta é "praticamente todos eles".

Lembre-se de que todo processo começa como uma lousa quase completamente em branco, com uma nova instanciação do espaço de endereço do modo de usuário. por exemplo. Todo processo tem sua própria instância de 0x10000. Portanto, além de ter que evitar algumas coisas que estão em locais conhecidos (para o vinculador, de qualquer maneira) em cada processo na plataforma, o vinculador é livre para colocar as coisas onde elas desejarem dentro do espaço de endereço do processo. Não precisa saber ou se importar com qualquer outra coisa.

A terceira parte é que quase tudo (exceto os itens definidos pelo sistema operacional que estão em endereços conhecidos) pode ser movido para endereços diferentes em tempo de execução, devido a Randomização do Layout do Espaço de Endereço , que existe no Windows e no Linux (o Linux o lançou primeiro, na verdade). Então, não importa onde o linker coloca as coisas.