Antes do kernel do Linux 2.6, struct task_struct estava presente no final da pilha de kernel de cada processo. Não havia nenhum conceito thread_info struct . Mas no kernel Linux 2.6, em vez de task_struct ser colocado no final da pilha do kernel para o processo, o thread_info struct é colocado no final. Esta estrutura thread_info contém um ponteiro para a estrutura task_struct .
Qual foi a necessidade da introdução da estrutura thread_info ? Poderíamos ter acessado a estrutura task_struct usando o stack pointer diretamente se task_struct fosse colocado no final da pilha do kernel do processo.
No Kernel 2.6, task_struct é alocado dinamicamente usando slab_allocator . Antes do kernel 2.6, foi alocado estaticamente?
Não sei por que isso foi feito. Mas seria fácil encontrá-lo se você fizer um git blame nesse arquivo e encontrar o commit que introduziu a mudança. Normalmente, a mensagem de confirmação terá uma explicação muito detalhada da alteração que está sendo cometida.
A razão pela qual precisamos do thread_info é devido ao fato de que estamos alocando a memória para task_struct usando o Slab Allocator . Agora você pode perguntar qual é a relação entre eles?
Para entender, você precisa entender como o Slab Allocator funciona.
Sem o Slab Allocator, os desenvolvedores do kernel poderiam alocar memória para task_struct na pilha do kernel para o processo em particular, para que ele possa ser acessado facilmente. Agora, com o advento do Slab Allocator, a memória é alocada para o task_struct, conforme determinado pelo Slab Allocator. Portanto, com o Slab Allocator você tem task_struct armazenado em algum outro lugar e não na pilha do kernel do processo em particular. Agora, os desenvolvedores do Kernel introduziram o thread_info e colocaram um ponteiro no local onde o task_struct reside. Assim, temos thread_info na pilha do kernel do processo em vez de task_struct . E é por isso que temos que viver com o thread_info.
Você pode ler sobre Slab Allocator no livro de Robert Love Linux Kernel Development.