Núcleo (sistema operacional)

Um n�cleo de sistema conecta o software aplicativo ao hardware de um computador

Na inform�tica, o kernel (em portugu�s: "n�cleo") � o componente central do sistema operativo da maioria dos dispositivos computacionais (computador e smartphone por exemplo); ele serve de ponte entre programas-aplicativos e o processamento real de dados feito a n�vel de hardware, cuja responsabilidades incluem gerenciar os recursos do sistema (a comunica��o entre componentes de hardware e software) usando o m�todo da abstra��o (encapsulamento) facilitando o uso do dispositivo.

Geralmente como um componente b�sico do sistema operativo, um n�cleo pode oferecer a camada de abstra��o de n�vel mais baixo para os recursos (especialmente processadores e dispositivos de entrada/sa�da) que softwares aplicativos devem controlar para realizar sua fun��o. Ele tipicamente torna estas facilidades dispon�veis para os processos de aplicativos atrav�s de mecanismos de comunica��o entre processos e chamadas de sistema. Para evitar um sistema com n�cleo, deve-se projetar o sistema que n�o trabalhe com abstra��o, por�m isto aumenta a complexidade do projeto.

Tarefas de sistemas operativos s�o feitas de maneiras diferentes por n�cleos diferentes, dependendo do seu desenho e abordagem. Enquanto n�cleos monol�ticos tentam alcan�ar seus objetivos executando todos os c�digos de sistema no mesmo espa�o de endere�amento para aumentar a performance do sistema, micron�cleos executam a maioria dos servi�os do sistema no espa�o de usu�rio como servidores, buscando melhorar a manuten��o e a modularidade do sistema operativo.

Vis�o geral

Na defini��o de n�cleo, o professor alem�o Jochen Liedtke disse que a palavra � "tradicionalmente usada para definir a parte do sistema operativo que � obrigat�ria e comum a todo software no sistema."

A maioria dos sistemas operativos depende do conceito de n�cleo. A exist�ncia de um n�cleo � uma consequ�ncia natural de projetar um sistema de computador como s�ries de camadas de abstra��o, cada uma das fun��es dependendo das fun��es das camadas abaixo de si. O n�cleo deste ponto de vista, � simplesmente o nome dado ao n�vel mais inferior de abstra��o que � implementado em software. Caso queira fazer/implementar um sistema operacional sem n�cleo, ter-se-ia que projetar todo o software no sistema de modo a n�o utilizar abstra��o alguma; isto iria aumentar a complexidade e o projeto a tal ponto que apenas os sistemas mais simples seriam capazes de ser implementados.

Enquanto isto hoje � chamado n�cleo, originalmente a mesma parte do sistema tamb�m foi chamado o nucleus ou caro�o (Nota, no entanto, este termo caro�o tamb�m foi usado para se referir a mem�ria primordial de um sistema de computador, por que alguns dos primeiros computadores usaram uma forma de mem�ria chamada mem�ria de caro�os magn�ticos), e foi concebido originalmente como contendo apenas os recursos de suporte essenciais do sistema operativo.

Na grande maioria dos casos, o processo de inicia��o come�a executando o n�cleo no modo supervisor. O n�cleo depois inicializa a si e depois o primeiro processo. Depois disto, tipicamente, o n�cleo n�o executa diretamente, apenas em resposta para eventos externos (ex., atrav�s de chamadas de sistema usados pelos aplicativos para requisitar servi�os do n�cleo, ou via interrup��es usadas pelo hardware para notificar o n�cleo sobre eventos). Al�m disso, tipicamente o n�cleo fornece um la�o que � executado sempre que nenhum processo esta dispon�vel para execu��o; geralmente chamado de processo desocupado.

O desenvolvimento do n�cleo � considerado uma das mais complexas e dif�ceis tarefas em programa��o. Sua posi��o central em um sistema operativo implica a necessidade de bom desempenho, que define o n�cleo como pe�a de software cr�tica e torna seu desenvolvimento correto e implementa��o correta dif�cil. Devido a diversas raz�es, o n�cleo pode at� n�o ser capaz de utilizar mecanismos de abstra��o, que ele fornece a outro software. Tais raz�es incluem preocupa��es com o gerenciamento de mem�ria e a falta de reentr�ncia, logo o seu desenvolvimento torna-se ainda mais dif�cil para engenheiros de software. A otimiza��o do uso de mem�ria faz-se necess�ria, pois o n�cleo n�o pode utilizar recursos de pagina��o por demanda, j� que ele pr�prio fornece esta facilidade, tendo, ent�o, que permanecer na mem�ria para tal.

Geralmente um n�cleo vai fornecer recursos para escalonamento de processos de baixo n�vel, comunica��o entre processos, sincroniza��o de processos, troca de contexto, manipula��o de blocos de controle de processo, gerenciamento de interrup��es, cria��o e destrui��o de processos, e suspens�o e continua��o de processos (veja estados de processos).

Finalidades b�sicas

O principal prop�sito do n�cleo � gerenciar os recursos do computador e permitir que outros programas rodem e usem destes recursos. Tipicamente estes recursos consistem de:

• Unidade de processamento central (CPU, o processador): principal parte de um sistema de computa��o, respons�vel por executar programas nele. O n�cleo tem a responsabilidade de decidir, em qualquer momento, qual dos programas em execu��o deve ser alocado para o processador ou processadores (cada um dos quais geralmente pode executar um programa por vez)
• Mem�ria: usada para armazenar instru��es do programa e dados. Tipicamente, ambos precisam estar presentes na mem�ria de modo a tornar a execu��o do programa poss�vel. Frequentemente m�ltiplos programas buscar�o acesso � mem�ria ao mesmo tempo, na maioria das vezes exigindo mais mem�ria do que o computador pode disponibilizar. O n�cleo � respons�vel pela decis�o de que mem�ria cada processo pode utilizar, e determinar o que fazer quando menos do suficiente est� dispon�vel.
• Dispositivos de entrada/sa�da, tais como teclado, mouse, entradas de disquete, impressoras, telas etc. O n�cleo aloca pedidos de aplicativos para realizar entrada/sa�da para um dispositivo apropriado (ou subse��o de um dispositivo, no caso de arquivos em um disco ou janelas em uma tela) e fornece m�todos convenientes para o uso do dispositivo (tipicamente abstra�do ao ponto onde o aplicativo n�o precisa mais conhecer os detalhes da implementa��o do dispositivo).

Aspectos importantes no gerenciamento de recursos s�o a defini��o de um dom�nio de execu��o (espa�o de endere�amento) e o mecanismo de prote��o utilizado para mediar o acesso a recursos dentro de um dom�nio.

N�cleos geralmente n�o oferecem m�todos para sincroniza��o e comunica��o entre processos (IPC (em ingl�s)).

Um n�cleo pode implementar estes recursos ele mesmo, ou depender de alguns processos que ele executa para fornecer estas facilidades a outros processos, no entanto neste caso ele deve oferecer algum modo do IPC permitir que processos acessem as facilidades fornecidas um pelo outro.

Finalmente, um n�cleo deve oferecer um m�todo de acesso a estas facilidades para os programas em execu��o.

Gerenciamento de processos

A principal tarefa de um n�cleo � permitir a execu��o de aplicativos e ajud�-los com recursos como abstra��es de hardware. Um processo define-se por um fluxo de atividades que se utiliza de recursos. Nesse caso, a execu��o de uma aplica��o gera um processo. Processo este que delimita as por��es da mem�ria o aplicativo pode acessar. O gerenciamento de processos do n�cleo deve levar em conta o equipamento de hardware embarcado para prote��o de mem�ria.

Para executar um aplicativo, um n�cleo geralmente cria um espa�o de endere�amento, carrega o arquivo contendo as instru��es do programa na mem�ria (talvez via pagina��o por demanda), cria uma pilha para o programa e ramos para uma dada localiza��o dentro do programa, iniciando, portanto, a sua execu��o.

N�cleos multitarefa s�o capazes de dar ao usu�rio a ilus�o de que um n�mero de processos que est� sendo executado simultaneamente no sistema � maior do que o n�mero de processos que aquele sistema � fisicamente capaz de executar. Usualmente, o n�mero de processos que um sistema pode executar simultaneamente � igual ao n�mero de CPUs que ele possui instaladas (no entanto, isto pode n�o ser o caso de processadores que suportam m�ltiplas linhas de execu��o simult�neas).

Em um sistema multitarefas preemptivo, o n�cleo d� a todos programas uma parcela do tempo e alterna entre os processos t�o rapidamente que d� ao usu�rio a impress�o de que eles est�o sendo executados simultaneamente. O n�cleo utiliza algoritmos de escalonamento para determinar qual processo ser� executado a seguir e quanto tempo lhe ser� dado. O algoritmo escolhido pode permitir que alguns processos tenham uma prioridade mais alta que muitos outros. O n�cleo geralmente tamb�m prov� a esses processos uma maneira de comunicarem-se; isto � chamado comunica��o entre processos (IPC (em ingl�s)) e as principais implementa��es s�o mem�ria compartilhada, troca de mensagens e chamadas de procedimento remoto (veja computa��o concorrente).

Outros sistemas (particularmente em computadores menos potentes) podem fornecer multitarefa de coopera��o, em que para cada processo � permitida execu��o ininterrupta at� que ele fa�a uma requisi��o especial ao n�cleo para que ele alterne para outro processo. Tais requisi��es s�o conhecidos como "indulg�ncias" (yield (em ingl�s)), e tipicamente ocorrem ou em resposta a um pedido para comunica��o entre processos, ou para esperar at� o acontecimento de um evento. Vers�es mais antigas do Microsoft Windows e do Mac OS utilizaram o conceito de multitarefa cooperativa, mas alternaram para esquemas preemptivos conforme a pot�ncia dos computadores alvo de seu mercado aumentava.

O sistema operativo pode tamb�m suportar o multiprocessamento (multiprocessamento sim�trico (SMP (em ingl�s)), ou, acesso n�o-uniforme a mem�ria); neste caso, diferentes programas e linhas de execu��o podem rodar em diferentes processadores. Um n�cleo para tal sistema deve ser projetado para ser reentrante, o que significa que ele pode rodar seguramente duas partes de seu c�digo simultaneamente. Isto tipicamente significa oferecer mecanismos de sincroniza��o (como trava-giros) para assegurar que dois processadores n�o tentar�o modificar os mesmos dados ao mesmo tempo.

Gerenciamento de mem�ria

O n�cleo possui acesso completo � mem�ria do sistema e deve permitir que processos acessem a mem�ria com seguran�a conforme suas necessidades. Frequentemente, o primeiro passo para isso � o endere�amento virtual, geralmente alcan�ado atrav�s da pagina��o e/ou segmenta��o. O endere�amento virtual permite ao n�cleo fazer com que um endere�o f�sico pare�a ser outro, o endere�o virtual. Espa�os de endere�o virtual podem ser diferentes para diferentes processos; a mem�ria acessada por um processo atrav�s de um endere�o virtual particular pode ser diferente da acessada por um outro processo atrav�s do mesmo endere�o virtual. Isto possibilita que todos os programas funcionem como se estivessem sendo executados sozinhos, al�m do n�cleo, e por isso evita que aplicativos travem uns aos outros.

Em v�rios sistemas, o endere�o virtual de um programa pode se referir a dados que n�o est�o na mem�ria atualmente. A cama de indire��o oferecida pelo endere�amento virtual permite que o sistema utilize meios de armazenagem de dados, como um disco r�gido, para armazenar o que de outro modo teria que permanecer na mem�ria RAM. Como resultado. sistemas operativos podem permitir que programas usem mais mem�ria do que est� fisicamente dispon�vel. Quando um programa precisa de dados que n�o est�o na RAM, a CPU avisa o n�cleo que isto ocorre, e este responde escrevendo o conte�do de um bloco de mem�ria inativo para o disco (se necess�rio) e substituindo-o na mem�ria com os dados requisitados pelo programa. O programa pode ent�o continuar sua execu��o do ponto em que foi suspenso. Este esquema � geralmente conhecido como pagina��o por demanda.

Endere�amento virtual tamb�m permite a cria��o de parti��es virtuais de mem�ria em duas �reas separadas, uma sendo reservada para o n�cleo (espa�o de n�cleo) e o outra para os aplicativos (espa�o de usu�rio). Os aplicativos n�o t�m permiss�o do processador para acessar a mem�ria do n�cleo, prevenindo, portanto, que um aplicativo possa danificar o n�cleo em execu��o. Esta parti��o fundamental de espa�o de mem�ria contribuiu muito para os projetos de n�cleos realmente de prop�sito geral e � quase universal em tais sistemas, embora alguns n�cleos de pesquisa (como o Singularity) usem outros m�todos.

Gerenciamento de dispositivos

Para realizar fun��es �teis, processos precisam acessar perif�ricos conectados ao computador, que s�o controlados pelo n�cleo atrav�s do driver do dispositivo. Por exemplo, para mostrar ao usu�rio algo utilizando a tela, um aplicativo teria que fazer uma requisi��o ao n�cleo que encaminharia a requisi��o para o seu driver de tela, que � o respons�vel por gerar a imagem atrav�s dos pixels.

Um n�cleo deve manter uma lista de dispositivos dispon�veis. Esta lista pode ser conhecida de antem�o (como em um sistema embarcado em que o n�cleo ser� reescrito se o hardware dispon�vel mudar), configurada pelo usu�rio (t�pico em computadores pessoais antigos e em sistemas projetados para uso pessoal) ou detectada pelo sistema durante a execu��o (normalmente chamado Plug and Play).

Num sistema "Plug and Play", um dispositivo realiza primeiro uma sondagem nos diferentes barramentos de hardware, como Interconector de Componentes Perif�ricos (PCI (em ingl�s)) ou Barramento Serial Universal (USB (em ingl�s)), para detectar os dispositivos instalados e depois procura os drivers apropriados.

Como a gest�o de dispositivos � uma tarefa muito especifica do SO, os drivers s�o manipulados de forma diferente pelo tipo de arquitetura do n�cleo. Em todos os casos, por�m, o n�cleo deve fornecer a entrada/sa�da para permitir que os drivers acessem fisicamente seus dispositivos atrav�s de alguma porta ou localiza��o da mem�ria. Decis�es muito importantes precisam ser feitas ao projetar o sistema de gest�o de dispositivos, j� que alguns projetos de acesso podem envolver trocas de contexto, tornando a opera��o custosa para o processador e causando um gasto excessivo de recursos.^{[carece de fontes]}

Chamadas do sistema

Para realmente realizar algo �til, um processo deve acessar os servi�os oferecidos pelo n�cleo. Isto � implementado por cada n�cleo, mas a maioria oferece uma Biblioteca padr�o do C ou uma Interface de programa��o de aplicativos, que envolve as fun��es relativas ao n�cleo.

O m�todo de invocar as fun��es do n�cleo varia entre diferentes n�cleos. Se o isolamento de mem�ria est� sendo usado, � imposs�vel para um processo de usu�rio chamar o n�cleo diretamente, visto que isso seria uma viola��o das regras de controle de acesso do processador. Algumas possibilidades s�o:

• Usar uma interrup��o de software simulada. Este m�todo est� dispon�vel na maioria dos hardwares, e �, portanto, muito comum.
• Usando um port�o de chamada. Um port�o de chamada � um endere�o especial armazenado pelo n�cleo em uma lista na mem�ria do n�cleo em uma localiza��o conhecida pelo processador. Quando o processador detecta uma chamada para este endere�o, ele ao inv�s disso redireciona para a localiza��o alvo sem causar nenhuma viola��o de acesso. Exige suporte no hardware, mas este tipo de hardware � muito comum.
• Usando uma instru��o de chamada de sistema especial. Esta t�cnica exige suporte especial no hardware, que em algumas arquiteturas habituais n�o possuem (notavelmente, x86). Instru��es de chamadas de sistema foram adicionadas a modelos recentes de processadores x86, embora, poucos (mas n�o todos) sistemas operativos fazem uso destes quando dispon�veis.
• Usando uma fila baseada na mem�ria. Um aplicativo que faz um grande n�mero de requisi��es, mas n�o precisa esperar o resultado de cada uma pode adicionar detalhes das requisi��es em uma �rea da mem�ria que o n�cleo sonda periodicamente para encontrar requisi��es.

Decis�es de desenho

Problemas com o suporte do n�cleo para prote��o

Uma considera��o importante no desenho do n�cleo � o suporte que ele oferece para prote��o contra faltas (toler�ncia a falhas) e comportamentos mal-intencionados (seguran�a). Estes dois aspectos geralmente n�o s�o claramente distinguidos, e a separa��o no desenho do n�cleo leva a rejei��o de uma estrutura hier�rquica de prote��o.

Os mecanismos ou pol�ticas oferecidas pelo n�cleo podem ser classificados de acordo com v�rios crit�rios, como: est�tico (for�ado durante o tempo de compila��o) ou din�mico (for�ado durante o tempo de execu��o); preemptivo ou p�s-detec��o; de acordo com os princ�pios de prote��o a que eles correspondem (ex. Denning); quer eles sejam suportados pelo hardware ou baseados em linguagem; quer eles sejam mais um mecanismo aberto ou m� pol�tica compulsiva; e muito mais.

Toler�ncia a falhas

Uma medida �til para o n�vel de toler�ncia a falhas de um sistema � qu�o estrito ele � com rela��o ao princ�pio do menor privil�gio. Em casos onde m�ltiplos programas est�o rodando em um �nico computador, � importante prevenir falhas em um dos programas de afetar negativamente outro. Estendendo-se ao desenho com m�s inten��es mais do que a falha em si, isto tamb�m implica a seguran�a, quando � necess�rio impedir processos de acessar informa��es sem que lhes seja dada a devida permiss�o.

As duas principais implementa��es via hardware para prote��o (de informa��es sens�veis) s�o dom�nios hier�rquicos de prote��o (tamb�m chamadas arquiteturas anel, arquiteturas de segmento ou modo supervisor), e endere�amento baseado em capacidades.

an�is de privil�gio, como na x86, s�o uma abordagem habitual de dom�nios hier�rquicos de prote��o usados em muitos sistemas comerciais para obter algum n�vel de toler�ncia a falhas.

Dom�nios hier�rquicos de prote��o s�o muito menos flex�veis, como no caso de qualquer n�cleo com uma estrutura hier�rquica presumida como um crit�rio de desenvolvimento global. No caso de prote��o n�o � poss�vel designar diferentes privil�gios a processos que n�o est�o no mesmo n�vel de privil�gio, e por isso n�o � poss�vel corresponder aos quatro princ�pios de Denning para a toler�ncia a falhas, particularmente o princ�pio do menor privil�gio. Dom�nios hier�rquicos de prote��o tamb�m carregam uma enorme desvantagem na performance, j� que a intera��o entre diferentes n�veis de prote��o, quando um processo tem que manipular uma estrutura de dados em ambos 'modo usu�rio' e 'modo supervisor', sempre exige c�pia de mensagens (transmiss�o por valor). Um n�cleo baseado em capacidades, no entanto, � mais flex�vel em designar privil�gios, pode corresponder aos princ�pios de Denning para a toler�ncia a falhas, e geralmente n�o sofrem de problemas de performance da c�pia por valor.

Ambas implementa��es tipicamente exigem algum suporte de hardware ou firmware para serem oper�veis e eficientes. O suporte de hardwarepara dom�nios hier�rquicos de prote��o geralmente � de "modos de CPU." Um modo simples e eficiente de fornecer suporte a hardware � delegar � unidade de gerenciamento de mem�ria a responsabilidade por checar as permiss�es de acesso para todos acessos a mem�ria, um mecanismo chamado endere�amento baseado em capacidades. Falta na maioria das arquiteturas comerciais, o suporte a MMU para capacidades.

Uma abordagem alternativa � simular capacidades usando dom�nios hier�rquicos comumente suportados; nesta abordagem, cada objeto protegido deve residir num espa�o de endere�amento ao qual o aplicativo n�o possui acesso; o n�cleo tamb�m mant�m uma lista de capacidades em tal mem�ria. Quando um aplicativo precisa acessar um objeto protegido por uma capacidade, ele realiza uma chamada de sistema e o n�cleo realiza o acesso a ele. O custo de performance de trocar de espa�o de endere�amento limita a praticabilidade desta abordagem em sistemas com intera��es complexas entre objetos, mas � utilizado nos sistemas operativos atuais para objetos que n�o s�o acessados frequentemente ou que n�o devem ser feitos rapidamente. Implementa��es onde os mecanismos de prote��o n�o suportados pelo firmware, mas s�o, ao inv�s disso, simulados em n�veos mais altos (ex. simulando capacidades ao manipular tabelas de p�ginas em hardware que n�o possui suporte direto), s�o poss�veis, mas h� implica��es de performance. No entanto, falta de suporte no hardware pode n�o ser problema, para sistemas que escolhem usar uma prote��o baseada em linguagem.

Uma decis�o importante no projeto do n�cleo � a escolha dos n�veis de abstra��o em que os mecanismos e pol�ticas de seguran�a devem ser implementados. Os mecanismos de seguran�a do n�cleo t�m um papel cr�tico no suporte a seguran�a nos n�veis superiores.

Uma abordagem � utilizar suporte no n�cleo e firmware para toler�ncia a falhas (ver acima), e montar as pol�ticas de seguran�a para comportamento malicioso em cima disso (adicionando recursos como mecanismos de criptografia quando necess�rio), delegar mais responsabilidade para o compilador. Implementa��es que delegam a aplica��o de pol�ticas de seguran�a para o compilador e/ou n�vel do aplicativo s�o geralmente chamados seguran�a baseada em linguagem.

A falta de muitos mecanismos cr�ticos de seguran�a nos principais sistemas operativos impede a implementa��o adequada de pol�ticas de seguran�a no n�vel de abstra��o do aplicativo. Na verdade, um engano muito comum na seguran�a de computadores � que qualquer pol�tica de seguran�a pode ser implementada no aplicativo, independentemente do suporte no n�cleo.

Prote��o baseada em hardware ou linguagem

Hoje, t�picos sistemas de computa��o usam regras aplicadas pelo hardware sobre quais programas t�m permiss�o para acessar quais dados. O processador monitora a execu��o e desliga um programa que viole uma regra (ex., um processo de usu�rio que tenta ler ou escrever na mem�ria do n�cleo, e assim por diante). Em sistemas que n�o possuem suporte para capacidades, processos s�o isolados um do outro, utilizando-se espa�os de endere�amento separados. Chamadas de um processo de usu�rio no n�cleo s�o regidas pela exig�ncia de que eles usem um dos m�todos de chamada do sistema descritos acima.

Uma abordagem alternativa � usar prote��o baseada em linguagem. Em um sistema de prote��o baseado em linguagem, o n�cleo vai permitir a execu��o apenas de c�digo produzido por um compilador em que ele confie. A linguagem pode ent�o, ser projetada de modo tal que ser� imposs�vel para o programador instruir algo que violaria os requisitos de seguran�a.

Desvantagens incluem:

• Demora maior para a inicializa��o efetiva do aplicativo. Aplica��es devem ser verificadas sempre que s�o iniciadas para garantir que foram compiladas utilizando um compilador "correto" ou podem necessitar de recompila��o de c�digo fonte ou bytecode.
• Sistemas de tipo inflex�vel. Em sistemas tradicionais, aplicativos realizam frequentemente opera��es que n�o s�o de tipagem forte. Tais opera��es n�o podem ser permitidas em um sistema de prote��o baseado em linguagem, o que significa que aplicativos podem precisar ser reescritos e podem, em alguns casos, perder performance.

Vantagens desta abordagem incluem:

• Separa��o de espa�os de endere�amento desnecess�ria. A troca de espa�os de endere�amento � uma opera��o lenta que causa grande degrada��o na performance, e muito trabalho de otimiza��o � feito atualmente para prevenir trocar desnecess�rias nos sistemas operativos. Trocar � complemente desnecess�rio em um sistema de prote��o baseada em linguagem, j� que todo c�digo opera no mesmo espa�o de endere�amento.
• Flexibilidade. Qualquer esquema de prote��o que possa ser desenvolvida para ser expresso atrav�s de linguagem de programa��o pode ser implementada atrav�s deste m�todo. Mudan�as no esquema de prote��o (ex. de um sistema hier�rquico para um baseado em capacidades) n�o exigem novo hardware.

Exemplos de sistemas com prote��o baseada em linguagem incluem o JX e Singularity.

Coopera��o de processos

Edsger Dijkstra provou que partindo de um ponto de vista l�gico, opera��es at�micas de travamento e destravamento operando em sem�foros bin�rios s�o suficientemente primitivos para expressar a qualquer funcionalidade de coopera��o entre processos. No entanto esta abordagem � geralmente tomada como deficiente em termos de seguran�a e efici�ncia, enquanto que uma abordagem via troca de mensagens � mais flex�vel.

Gerenciamento de dispositivos de entrada/sa�da

A ideia de um n�cleo onde dispositivos de entrada/sa�da s�o gerenciados uniformemente com outros processos, como processos paralelos em coopera��o, foi proposta e implementada primeiramente por Brinch Hansen (embora ideias similares tenham sido sugeridas em 1967). Na descri��o de Hansen disto, os processos "comuns" s�o chamados processos internos, enquanto que os dispositivos de entrada/sa�da s�o chamados processos externos.

Formas de desenvolvimento

Naturalmente, as tarefas e recursos listados acima podem ser fornecidas de v�rios modos que diferem entre si em projeto e implementa��o.

O princ�pio da separa��o entre o mecanismo e a pol�tica � a diferen�a substancial entre a filosofia de micron�cleo e n�cleo monol�tico. Aqui um mecanismo � o apoio que permite a implementa��o de v�rias pol�ticas diferentes, enquanto uma pol�tica � um "modo de opera��o" particular. Por exemplo, um mecanismo pode oferecer �s tentativas de entrada de um usu�rio um m�todo de chamar um servidor de autoriza��o para determinar se um acesso deve ser dado; uma pol�tica pode ser para o servidor de autoriza��o exigir uma senha e chec�-la contra uma senha embaralhada armazenada numa base de dados. Devido ao fato de o mecanismo ser gen�rico, a pol�tica pode ser alterada com mais facilidade (ex. ao exigir o uso de um passe) do que se um mecanismo e pol�tica fossem integrados no mesmo m�dulo.

Em um micron�cleo m�nimo algumas pol�ticas b�sicas s�o inclu�das, e seus mecanismos permite que o que est� rodando sobre o n�cleo (a parte remanescente do sistema operativo e outras aplica��es) decida quais pol�ticas adotar (como gerenciamento de mem�ria, escalonamento de processo de alto n�vel, gerenciamento de sistema de arquivos, etc.). Um n�cleo monol�tico ao inv�s disso, tende a incluir v�rias pol�ticas, ent�o restringindo o resto do sistema dependente delas.

Per Brinch Hansen apresentou um argumento convincente a favor da separa��o do mecanismo e da pol�tica. A falha em preencher completamente esta separa��o, � uma das maiores causas para a falta de inova��o nos sistemas operativos existentes atualmente, um problema comum nas arquiteturas de computador. O projeto monol�tico � induzido pela abordagem de arquitetura "modo n�cleo"/"modo usu�rio" para prote��o (tecnicamente chamada de dom�nios hier�rquicos de prote��o), que � comum em sistemas comercias convencionais; na verdade, todo m�dulo que necessite de prote��o �, portanto, preferivelmente inclu�do no n�cleo. Esta liga��o entre projeto e "modo privilegiado" pode ser reconduzida at� o problema chave da separa��o do mecanismo e da pol�tica; de fato, a abordagem de arquitetura de "modo privilegiado" se funde ao mecanismo de prote��o com as pol�ticas de seguran�a, enquanto a principal abordagem de arquitetura alternativa, endere�amento baseado em capacidades, claramente distingue ambos, levando naturalmente ao desenvolvimento de um micron�cleo design (veja Separa��o entre prote��o e seguran�a).

Enquanto n�cleos monol�ticos executam todo seu c�digo no mesmo espa�o de endere�amento (espa�o de n�cleo) micron�cleos tentam executar a maior parte dos seus servi�os no espa�o de usu�rio, buscando aprimorar a manuten��o e modulabilidade do c�digo base. A maioria dos n�cleos n�o se encaixa exatamente em uma destas categorias, sendo mais encontrados entre estes dois projetos. Os chamados n�cleos h�bridos. Projetos mais ex�ticos como nanon�cleos e exon�cleos est�o dispon�veis, mas s�o usados raramente em sistemas produtivos. O virtualizador Xen, por exemplo, � um exon�cleo.

Diagrama de n�cleos monol�ticos

N�cleos monol�ticos

Ver artigo principal: n�cleo monol�tico

Em um n�cleo monol�tico, todos os servi�os do sistema operativo rodam junto com a linha de execu��o principal do n�cleo, portanto, tamb�m se encontram na mesma �rea de mem�ria. Esta abordagem permite o acesso vasto e poderoso de hardwares. Alguns desenvolvedores, como desenvolvedor do UNIX Ken Thompson, defendem que � "mais f�cil de implementar um n�cleo monol�tico" que micron�cleos. As principais desvantagens de n�cleos monol�ticos s�o as depend�ncias entre os componentes do sistema - um defeito em um driver de dispositivo pode paralisar todo o sistema - e o fato de n�cleos grandes podem se tornar muito dif�ceis de manter.

Na abordagem do micron�cleo, o pr�prio n�cleo fornece apenas funcionalidades b�sicas que permite a execu��o de servidores, programas separados que assumem fun��es que seriam do n�cleo monol�tico, como drivers de dispositivos, servidores de interface de usu�rio, etc.

• BSD
• Linux
• MS-DOS e derivados, incluindo Windows 95, Windows 98 e Windows ME
• Solaris
• Palm OS

Diagrama de intera��o de um micron�cleo

Micron�cleos

Ver artigos principais: Micronúcleo (informática) e Micronúcleo

A abordagem de micronúcleo consiste em definir abstrações simples sobre o hardware, com um conjunto de primitivos ou chamadas de sistema para implementar serviços mínimos do sistema operativo como gerenciamento de memória, multitarefas, e comunicação entre processos. Outros serviços, incluindo aqueles normalmente fornecidos por um núcleo monolítico como rede, são implementados em programas de espaço de usuário, conhecidos como servidores. Micronúcleos são mais fáceis de manter do que núcleos monolíticos, mas um grande número de chamadas de sistemas de trocas de contexto podem desacelerar o sistema por que eles geralmente geram mais degradação na performance do que simples chamadas de função.

Um micronúcleo permite a implementação das partes restantes do sistema operativo como aplicativos normais escritos em linguagem de alto nível, e o uso de diferentes sistemas operativos sobre o mesmo núcleo não modificado. Ele também torna possível alternar dinamicamente entre sistemas operativos e manter mais de um deles ativos simultaneamente.

• Hurd
• MINIX
• Mach

Núcleos monolíticos x micronúcleos

Conforme o núcleo do computador crescem, um número de problemas se torna evidente. Um dos mais óbvios é que o espaço de memória aumenta. Isto é mitigado de certo modo ao aperfeiçoar o sistema de memória virtual, mas nem todas arquitetura de computador suportam memórias virtuais. Para reduzir o espaço utilizado pelo núcleo, modificações extensivas precisam ser realizadas para remover cuidadosamente código inútil, que pode ser muito difícil devido a dependências pouco aparentes entre partes de um núcleo com milhões de linhas de código.

Pelo começo dos anos 1990, devido a vários problemas de núcleos monolíticos em comparação a micronúcleos, núcleos monolíticos foram considerados obsoletos por virtualmente todos pesquisadores de sistemas operativos. Como resultado, o projeto do Linux, um núcleo monolítico mais do que um micronúcleo foi o tópico da famosa discussão inflamada entre Linus Torvalds e Andrew Tanenbaum. Há méritos em ambos argumentos presentes no debate Tanenbaum–Torvalds.

Performance

Núcleos monolíticos são projetados para que todo o seu código fique no mesmo espaço de endereçamento (espaço de núcleo), que alguns desenvolvedores argumentam ser necessário para aumentar a performance do sistema. Alguns desenvolvedores também sustentam a hipótese de que núcleos monolíticos são extremamente eficientes se forem bem escritos.

A performance de micronúcleos construídos nos anos 1980 e começos dos 1990 era terrível. Estudos empíricos que mediram a performance destes micronúcleos não analisaram os motivos para tal ineficiência. As explicações para estes dados foram deixadas para o "folclore", com a suposição de que eles eram devido ao aumento da frequência da troca de modo núcleo para modo usuário, devido a maior frequência de comunicação entre processos e a maioria frequência de trocas de contexto.

De fato, como foi conjeturado em 1995, os motivos para a terrível performance dos micronúcleos podem também ter sido: (1) uma real ineficiência na implementação de toda a abordagem de micronúcleo, (2) conceitos particulares implementados nesses micronúcleos, e (3) a implementação individual destes conceitos. Portanto ainda falta estudar se a solução para construir um micronúcleo eficiente foi, ao contrário de tentativas anteriores, a de aplicar as técnicas corretas de construção.

No outro extremo, a arquitetura de domínios hierárquicos de proteção que leva a um projeto de núcleo monolítico gera impactos significativos na performance cada vez que há uma interação entre diferentes níveis de proteção (ex. quando um processo tem que manipular uma estrutura de dados em ambos 'modo usuário' e 'modo supervisor'), desde que isto exija cópia de mensagem por valor.

Em meados de 1990, a maioria dos pesquisadores abandonou a crença de que ajustes cuidadosos poderiam reduzir estes impactos dramaticamente,^{[carece de fontes]} mas recentemente, novos micronúcleos, otimizados para performance, tais como os L4 e K42 vêm trabalhando nestes problemas.

A abordagem de núcleo híbrido combina velocidade e projetos mais simples de um núcleo monolítico com a modularidade e execução segura de um micronúcleo.

Núcleos híbridos

Ver artigo principal: Núcleo híbrido

Núcleos híbridos são um acordo entre o desenvolvimento de micronúcleos e núcleos monolíticos. Isto implica executar alguns serviços (como a pilha de rede ou o sistema de arquivos) no espaço do núcleo para reduzir o impacto na performance^{[carece de fontes]} de um micronúcleo tradicional, mas ainda executar o código no núcleo (como drivers de dispositivos) como servidores no espaço de usuário.

• BeOS / Haiku
• Microsoft Windows NT
• XNU (núcleo do Darwin utilizado no Mac OS X)

Nanonúcleos

Ver artigo principal: Nanonúcleo

Um nanonúcleo delega virtualmente todos os serviços — incluindo até os mais básicos como controlador de interrupções ou o temporizador — para drivers de dispositivo para tornar o requerimento de memória do núcleo ainda menor do que o dos tradicionais micronúcleos.

• Adeos
• Dycos [4]
• EROS
• EKA2
• Jari Operating System [5]
• JNode
• KeyKOS
• LSE/OS
• Mac OS nanonúcleo
• OZONE
• Trion Operating System
• XtratuM [6]

Diagrama de interação de um exonúcleo

Exonúcleos

Ver artigo principal: Exonúcleo

Um exonúcleo é um tipo de núcleo que não abstrai hardware em modelos teóricos. Ao invés disso, ele aloca recursos físicos de hardware (como o tempo de um processador), páginas de memória e blocos de disco, para diferentes programas. Um programa rodando em um exonúcleo pode ligar para uma biblioteca do sistema operacional que usa o exonúcleo para simular as abstrações de um sistema operativo conhecido, ou ele pode desenvolver abstrações específicas para aquele aplicativo para uma performance superior.

História do desenvolvimento do núcleo

Os primeiros sistemas operativos

Ver artigo principal: História dos sistemas operacionais

Falando estritamente, um sistema operativo (e, isto inclui um núcleo) não é obrigado a rodar um computador. Programas podem ser carregados diretamente e executados na máquina de "bare metal", desde que os autores destes programas estiverem dispostos a trabalhar sem nenhuma abstração de hardware ou suporte a sistema operativo. Os primeiros computadores operaram desta maneira durante os anos de 1950, começo dos 1960, eram reiniciados e recarregados entre cada execução de diferentes programas. Eventualmente, pequenos programas auxiliares como carregadores de programas e depuradores foram mantidos na memória entre as execuções, ou carregados de memória somente de leitura. Conforme estas eram desenvolvidas, elas formaram a base do que depois se tornaria o núcleo dos sistemas operativos. A abordagem de "bare metal" ainda é usada hoje em alguns consoles de videogame e sistemas embarcados, mas no geral, computadores novos usam sistemas operativos e núcleos modernos.

Em 1969 o RC 4000 Multiprogramming System (microcomputador RC-4000) introduziu a filosofia de desenvolvimento de sistemas de pequeno núcleo "na qual sistemas operativos para diferentes propósitos poderiam ser criados de maneira metódica", algo que poderia ser chamado de abordagem de micronúcleo.

Sistemas operativos de tempo compartilhado

Ver artigo principal: tempo compartilhado

Na década precedendo o fenômeno Unix, computadores aumentaram muito em poder de processamento — ao ponto de os operadores de computador estarem buscando novos modos de conseguir com que as pessoas usassem o tempo livre em suas máquinas. Uma das maiores evoluções durante esta era foi o tempo compartilhado, em que um número de usuários conseguiria pequenas parcelas do tempo do computador, em uma taxa que fazia parecer que cada um estava conectado à sua própria máquina, embora mais lenta.

O desenvolvimento dos sistemas de tempo compartilhado levou a inúmeros problemas. Um deles foi que usuários, particularmente em universidades, em que os sistemas estavam sendo desenvolvidos, pareciam tentar hackear o sistema para conseguir mais tempo de processamento. Por esta razão, segurança e controles de acesso se tornaram um foco principal do projeto Multics em 1965. Outro problema corrente era gerenciar apropriadamente os recursos do sistema: usuários gastavam a maior parte do tempo iniciando na tela e pensando ao invés de realmente utilizar os recursos do computador, e o sistema de tempo compartilhado deveria dar tempo de processamento para um usuário ativo durante estes períodos. Por fim, tipicamente os sistemas ofereciam uma hierarquia de memória de várias camadas de profundidade, e particionar este recurso caro levou a um grande desenvolvimento nos sistemas de memória virtual.

Unix

Ver artigo principal: Unix

Diagrama da relação de família de predecessor/sucessor para os sistemas tipo Unix.

Durante a fase de projeto do Unix, os programadores decidiram modelar todo dispositivo de alto nível como um arquivo, por que eles acreditavam que o propósito da computação era a transformação de dados. Por exemplo, impressoras eram representadas como um "ficheiro" em uma localização conhecida — quando dados eram copiados para o arquivo, ela realizava a impressão destes. Outros sistemas, para fornecer uma funcionalidade similar, possuem a tendência de virtualizar dispositivos em um nível mais baixo — ou seja, ambos dispositivos e ficheiros seriam instâncias de algum conceito de nível inferior. Virtualizar o sistema a nível de ficheiros permitiu aos usuários manipular todo o sistema usando seus conceitos e ferramentas de gerenciamento de ficheiros, simplificando a operação dramaticamente. Como uma extensão do mesmo paradigma, o Unix permite que programadores manipulem arquivos usando uma série de pequenos programas, usando o conceito de encadeamento, que permite aos usuários completar operações em etapas, alimentando um ficheiro através de uma cadeia de ferramentas de propósito único. Embora o resultado final fosse o mesmo, usar programas menores aumentou drasticamente a flexibilidade, assim como o uso e desenvolvimento, permitindo que o usuário modificasse seu fluxo de trabalho ao adicionar ou remover um programa da cadeia.

No modelo Unix, o sistema operativo consiste de duas partes: a primeira é uma enorme coleção de programas de utilidades que guiam a maioria das operações; a segunda, o núcleo que executa os programas. No Unix, do ponto de vista da programação, a distinção entre os dois é extremamente tênue: o núcleo é um programa rodando no modo supervisor, que age como um carregador de programas e supervisor para os pequenos programas de utilidade que integram o resto do sistema e fornecem travas e serviços de entrada/saída para estes programas; além disso, o núcleo não intervém de modo algum no espaço de usuário.

Ao longo dos anos o modelo de computação mudou, e o tratamento do Unix de tudo como um ficheiro ou fluxo de bytes não era mais universalmente aplicável como antes. Embora um terminal pudesse ser tratado como um ficheiro ou fluxo de bytes, de que se exibia ou lia, o mesmo não parecia ser verdade para a interface gráfica. As redes se tornaram outro problema. Mesmo se a comunicação de rede pudesse ser comparada ao acesso de ficheiros, a arquitetura de baixo nível orientada a pacotes lidava com pedaços discretos de dados e não com ficheiros completos. Conforme a capacidade dos computadores crescia, o Unix se tornava cada vez mais desorganizado com relação a código. Enquanto núcleos podiam ter 100.000 linhas de código nos anos 1970 e 1980, núcleos sucessores modernos do núcleo do Unix como o Linux possuem mais de 4,5 milhões de linhas.

Derivados modernos do Unix são geralmente baseados em núcleos monolíticos que carregam módulos. Exemplos disto são o Linux, um núcleo monolítico com suporte a núcleos, e diversas distribuições que o incluem, assim como os núcleos das variantes do BSD como FreeBSD, DragonflyBSD, OpenBSD, NetBSD etc. Além destas alternativas, desenvolvedores amadores mantém uma comunidade ativa de desenvolvimento de sistemas operativos, cheia de núcleos que são criados como passatempo que acabam compartilhando vários dos recursos com o Linux e/ou os núcleos do FreeBSD, DragonflyBSD, OpenBSD e NetBSD e/ou sendo compatíveis com eles.

macOS

Ver artigos principais: macOS, Mac OS Classic e História do macOS

A Apple lançou Mac OS pela primeira vez em 1984, empacotado com o seu computador pessoal Apple Macintosh. Nos primeiros lançamentos, o Mac OS (ou Sistema de Software, como ele foi chamado) careceu de muitos recursos básicos, como multitarefas e um sistema hierárquico. Com o passar tempo, o sistema operacional evoluiu e se tornou o Mac OS 9 com alguns recursos adicionados, mas o núcleo se manteve basicamente o mesmo.^{[carece de fontes]} Em oposição a isto, o macOS é baseado no Darwin, que utiliza um conceito de núcleo híbrido chamado XNU, criado combinando o núcleo do 4.3BSD e o Mach.

Amiga

Ver artigo principal: AmigaOS

O Amiga da Commodore foi lançado em 1985, e estava dentre os primeiros (e certamente mais bem sucedidos) computadores domésticos a apresentar um sistema operativo com um micronúcleo. O núcleo do Amiga, a exec.library, era pequena mas capaz, oferecendo multitarefas rápidas e preemptivas em hardware similar ao do Apple Macintosh, e um sistema avançado de ligações dinâmicas que permitia uma expansão fácil.

Microsoft Windows

Ver artigo principal: Microsoft Windows

O Microsoft Windows foi lançado em 1985 como uma extensão para o MS-DOS. Devido à sua dependência de outro sistema operativo, todas as versões até a 95 são consideradas um ambiente operacional (e não um sistema operativo propriamente dito). Tal linha de produtos continuou por 1980 e 1990, resultando nos lançamentos das séries Windows 9x, atualizando as capacidades do sistema para endereçamento de 32 bits e multitarefas preemptivo, ao longo dos anos 1990, terminando com o lançamento do Windows Me em 2000.

O lançamento do Windows XP em outubro de 2001 uniu as duas linhas de produto, com a intenção de combinar a estabilidade do núcleo NT com os recursos ao consumidor das séries 9x. A arquitetura do núcleo do Windows NT é considerada híbrida pois o próprio núcleo contém tarefas como o gerenciador de janelas e o gerenciador de comunicação entre processos, mas vários subsistemas são executados no modo de usuário. O ponto de quebra exato entre espaço de usuário e espaço de núcleo têm deslocado conforme a versão, mas a introdução do UMDF (User-Mode Driver Framework) no Windows Vista e do escalonamento de linha de execução no espaço de usuário no Windows 7, deslocou mais recursos do núcleo para processos no espaço de usuário.

Desenvolvimento de micronúcleos

Embora o Mach, desenvolvido na Universidade Carnegie Mellon de 1985 a 1994, é o micronúcleo de propósito geral mais conhecido, outros micronúcleos foram desenvolvidos com objetivos mais específicos. Uma família de micronúcleos L4 (principalmente o micronúcleo L3 e o L4) foi criada para demonstrar que micronúcleos não são necessariamente lentos. Implementações mais novas como Fiasco e Pistachio são capazes de executar o Linux junto com outros processos L4 em espaços de endereçamento separados.

QNX é um Sistema operativo de tempo-real com um projeto de micronúcleo minimalista que vem sendo desenvolvido desde 1982, sendo mais bem-sucedido do que o Mach em alcançar os objetivos do paradigma do micronúcleo. Ele é usado principalmente em sistemas embarcados e em situações em que o software não pode falhar, como nos braços robóticos do ônibus espacial e máquinas que controlam a moeção de vidro a tolerâncias extremamente finas, onde um minúsculo erro poderia custar centenas de milhares de reais.

Ver também

• Comparação entre núcleos
• Compilador
• Driver de dispositivo
• Entrada/saída
• Falha (tecnologia)
• Filosofia Unix
• Pedido de interrupção
• Memória
  • Memória de acesso aleatório
  • Memória virtual
  • Paginação, Segmentação
  • Espaço de troca
  • Espaço de usuário
  • Unidade de gerenciamento de memória
• Multitarefa
  • Processo
  • Linha de execução
  • Escalonamento
  • Tempo compartilhado
  • Troca de contexto
  • Comunicação entre processos
• Sistema operativo

Leituras importantes

• Andrew Tanenbaum, Operating Systems - Design and Implementation (Third edition);
• Andrew Tanenbaum, Modern Operating Systems (Second edition);
• Daniel P. Bovet, Marco Cesati, The Linux Kernel;
• David A. Peterson, Nitin Indurkhya, Patterson, Computer Organization and Design, Morgan Koffman (ISBN 1-55860-428-6);
• B.S. Chalk, Computer Organisation and Architecture, Macmillan P.(ISBN 0-333-64551-0).

Ligações externas

• KERNEL.ORG, sítio oficial do Linux.
• Núcleos de Sistemas Operativos no SourceForge
• Núcleos de Sistemas Operativos no Freshmeat
• MIT Sistemaoperacional de Exonúcleo
• Imagem de núcleo - Wiki Debian
• A arquitetura do nanonúcleo do KeyKOS, um artigo de 1992 por Norman Hardy e outros..
• Uma visão geral do Ssistema Operativo NetWare, um artigo de 1994 por Drew Major, Greg Minshall, e Kyle Powell (arquitetos pfincipais por trás do SO NetWare).
• Kernelnewbies, uma comunidade para aprender a hackear o Linux.
• Comparação detalhada entre os núcleos dos sistemas operativos mais populares