Núcleo (sistema operacional)

Esta página cita fontes, mas que não cobrem todo o conteúdo. Ajude a inserir referências (Encontre fontes: ABW  • CAPES  • Google (N • L • A)). (Outubro de 2019)

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)^[1] 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.

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."^[2]

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,^[3] 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^[1][4][5][6] (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.^[7] 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.^[8] 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,^[9] 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).^[4][6]

O principal propósito do núcleo é gerenciar os recursos do computador e permitir que outros programas rodem e usem destes recursos.^[1] 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.^[1]

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.

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.^[10] O gerenciamento de processos do núcleo deve levar em conta o equipamento de hardware embarcado para proteção de memória.^[11]

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.^[12]

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^[13].

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.

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.^[12]

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.

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.^[12]

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?]}

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.^[14]

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.

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.^[1]

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^[15][16]); 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.

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.^[17] 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^[18] 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),^[19] e endereçamento baseado em capacidades.^[20]

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.^[1] 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,^[15][16] 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).^[21] 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,^[22] 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^[23] 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.^[22] 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.^[24][25] 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.^[26] No entanto, falta de suporte no hardware pode não ser problema, para sistemas que escolhem usar uma proteção baseada em linguagem.^[27]

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.^{[22][28][29][30][31]}

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.^[28] 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.^[28]

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.^[32] 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.^[27]

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.

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.^[33] 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.^[6]

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^[34][35]). 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.^[6]

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.^[36][37] 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,^[37] 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.).^[1][6] 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.^[1][6] A falha em preencher completamente esta separação, é uma das maiores causas para a falta de inovação nos sistemas operativos existentes atualmente,^[1] um problema comum nas arquiteturas de computador.^[38][39][40] 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;^[41] na verdade, todo módulo que necessite de proteção é, portanto, preferivelmente incluído no núcleo.^[41] Esta ligação entre projeto e "modo privilegiado" pode ser reconduzida até o problema chave da separação do mecanismo e da política;^[1] 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^[1] (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.^[42] 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.

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"^[43] 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.

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

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.^[6] Ele também torna possível alternar dinamicamente entre sistemas operativos e manter mais de um deles ativos simultaneamente.^[6]

• Hurd
• MINIX
• Mach

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.^[44] 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.^[45] Há méritos em ambos argumentos presentes no debate Tanenbaum–Torvalds.

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.^[46] Alguns desenvolvedores também sustentam a hipótese de que núcleos monolíticos são extremamente eficientes se forem bem escritos.^{[46][fonte confiável?]}

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

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.^[2] 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.^[2]

No outro extremo, a arquitetura de domínios hierárquicos de proteção que leva a um projeto de núcleo monolítico^[41] 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.^[21]

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^[48] e K42 vêm trabalhando nestes problemas.^{[necessário verificar]}

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)

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.^[49]

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

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.^[50]

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^[51]) 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",^[52] algo que poderia ser chamado de abordagem de micronúcleo.

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.^[53]

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.^[54] 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.

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.^[55] 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.^[55] 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,^[7] 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.^[56]

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.^[57]

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.^[58]

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.^[59]

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.^[60] 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.^[61] 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,^[62] deslocou mais recursos do núcleo para processos no espaço de usuário.

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.^[48] 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.^[63][64]

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.^[65] 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.

A Wikiversidade possui materiais sobre Operating Systems/Kernel Models at: Modelos de Núcleo

• 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

Referências

1. ↑ ^{a b c d e f g h i j k} Wulf 74 pp.337-345
2. ↑ ^{a b c d e f g h} Liedtke 95
3. ↑ Tanenbaum 79, chapter 1
4. ↑ ^{a b} Deitel 82, p.65-66 cap. 3.9
5. ↑ Lorin 81 pp.161-186, Schroeder 77, Shaw 75 pp.245-267
6. ↑ ^{a b c d e f g h} Brinch Hansen 70 pp.238-241
7. ↑ ^{a b} O nível de privilégio mais alto possui vários nomes pelas diferentes arquiteturas, tais como modo supervisor, modo núcleo, CPL0, DPL0, Anel 0, etc. Veja [Anel (segurança)] para mais informações.
8. ↑ «Desenvolvimento do SO Bona Fide - Tutorial do Bran para Desenvolvimento de Núcleo, por Brandon Friesen» 
9. ↑ Para escalonamento de processos de baixo nível veja Deitel 82, ch. 10, pp. 249–268.
10. ↑ Levy 1984, p.5
11. ↑ Needham, R.M., Wilkes, M. V. Domínio de proteção e gerenciamento de processos, Computer Journal, vol. 17, no. 2 de maio de 1974, pp 117-120.
12. ↑ ^{a b c} Silberschatz 1990
13. ↑ «Definition of non-preemptive multitasking». PCMAG (em inglês). Consultado em 2 de agosto de 2020 
14. ↑ Tanenbaum, Andrew S. (2008). Modern Operating Systems 3rd Edition ed. [S.l.]: Prentice Hall. pp. 50–51. ISBN 0-13-600663-9. . . . quase todas as chamadas de sistemas [são] invocadas de programas C ao chamar uma biblioteca de procedimento . . . A biblioteca de procedimento . . . executa uma instrução TRAP para alternar do modo usuário para o modo núcleo e começar a execução . . . 
15. ↑ ^{a b} Denning 1976
16. ↑ ^{a b} Swift 2005, p.29 quote: "isolação, controle de recursos, verificação de decisão (checagem), e recuperação de erros."
17. ↑ Cook, D.J. Medindo a proteção da memória, aceito na terceira Conferência Internacional da Engenharia de Software, Atlanta, Georgia, Maio de 1978.
18. ↑ Swift 2005 p.26
19. ↑ Intel Corporation 2002
20. ↑ Houdek et al. 1981
21. ↑ ^{a b} Hansen 73, Seção 7.3 p.233 "interações entre diferentes níveis de proteção exigem a transmissão de mensagens por valor"
22. ↑ ^{a b c} Linden 76
23. ↑ Schroeder 72
24. ↑ Stephane Eranian & David Mosberger, Memória Virtual no núcleo Linux IA-64, Prentice Hall PTR, 2002
25. ↑ Silberschatz & Galvin, Conceitos de Ssistema Operativo, 4th ed, pp445 & 446
26. ↑ Hoch, Charles; J. C. Browne (Universidade do Texas, Austin) (Julho de 1980). «An implementation of capabilities on the PDP-11/45» (pdf). ACM SIGOPS Operating Systems Review. 14 (3): 22–32. doi:10.1145/850697.850701. Consultado em 7 de janeiro de 2007  A referência emprega parâmetros obsoletos |coautor= (ajuda)
27. ↑ ^{a b} «Uma Abordagem a Segurança Baseada em Linguagem, Schneider F., Morrissett G. (Universidade Cornell) e Harper R. (Universidade Carnegie Mellon)» (PDF) 
28. ↑ ^{a b c} P. A. Loscocco, S. D. Smalley, P. A. Muckelbauer, R. C. Taylor, S. J. Turner, and J. F. Farrell. A Inevitabilidade do Futuro: A Presunção Falsa de Segurança no Ambiente de Computação Moderna Arquivado em 21 de junho de 2007, no Wayback Machine.. Em procedimentos da 21ª Conferência Nacional de Segurança de Sistemas de Informação, páginas 303–314, Out. de 1998. [1].
29. ↑ J. Lepreau e outros. A Relevância Persistente do Ssistema Operativo Local aos Aplicativos Globais. Procedimentos da 7ª ACM SIGOPS Eurcshelf/book001/book001.html Segurança da Informação: Uma Coleção Integrada de Dissertações], IEEE Comp. 1995.
30. ↑ J. Anderson, Estudo de Planejamento de Segurança de Computadores Arquivado em 21 de julho de 2011, no Wayback Machine., Air Force Elect. Systems Div., ESD-TR-73-51, Outubro de 1972.
31. ↑ * Jerry H. Saltzer, Mike D. Schroeder (Setembro de 1975). «A proteção de informação em sistemas de computador». Proceedings of the IEEE. 63 (9): 1278–1308. doi:10.1109/PROC.1975.9939 
32. ↑ Jonathan S. Shapiro; Jonathan M. Smith; David J. Farber. «EROS: um sistema de capacidades rápido». Procedimentos da 70º simpósio ACM sobre princípios de sistemas operativos  !CS1 manut: Nomes múltiplos: lista de autores (link)
33. ↑ Dijkstra, E. W. Processos Sequenciais Cooperadores. Math. Dep., Technological U., Eindhoven, Set. 1965.
34. ↑ «SHARER, um sistema de compartilhamento de tempo para o CDC 6600». Consultado em 7 de janeiro de 2007 
35. ↑ «Supervisores Dinâmicos - seu projeto e construção». Consultado em 7 de janeiro de 2007 
36. ↑ Baiardi 1988
37. ↑ ^{a b} Levin 75
38. ↑ Denning 1980
39. ↑ Jürgen Nehmer A Imoralidade dos sistemas operativos, ou: Pesquisa nos sistemas operativos ainda é Justificável? Notas em Ciência da Computação; Vol. 563. Processo da Oficina Internacional sobre sistemas operativos dos anos 90 em diante. pp. 77 - 83 (1991) ISBN 3-540-54987-0 [2] citação: "Os últimos 25 anos mostraram que a pesquisa sobre arquiteturas de sistemas operativos teve pouco efeito nos principais sistemas operativos." [3] Arquivado em 14 de outubro de 2007, no Wayback Machine.
40. ↑ Levy 84, p.1 citação: "Embora a complexidade dos aplicativos de computador aumenta anualmente, a arquitetura de hardware subjacente para aplicativos se manteve intocada por décadas."
41. ↑ ^{a b c} Levy 84, p.1 citação: "Arquiteturas convencionais suportam um único modo privilegiado de operação. Esta estrutura leva a um desenvolvimento monolítico; qualquer módulo precisando de proteção deve ser parte do único núcleo do sistema operativo. Se, ao contrário, qualquer módulo pudesse executar em um domínio protegido, sistemas poderiam ser construídos como uma coleção de módulos independentes ampliáveis por qualquer usuário."
42. ↑ Roch 2004
43. ↑ «Códigos Abertos : Vozes da Revolução do Código Aberto» 
44. ↑ Endereçamento virtual é comumente mais obtido através da unidade de gerenciamento de memória incorporado.
45. ↑ Registros do debate entre Torvalds e Tanenbaum podem ser encontrados em dina.dk Arquivado em 3 de outubro de 2012, no Wayback Machine., groups.google.com, oreilly.com e Sítio do Andrew Tanenbaum
46. ↑ ^{a b} Matthew Russell. «O que é Darwin (e como ele sustenta o Mac OS X)». O'Reilly Media  citação: "A natureza fortemente unida do núcleo monolítico permite torná-lo eficiente no uso do hardware subjacente [...] Micronúcleos, por outro lado, rodam um número muito maior de processos no espaço de usuário. [...] Infelizmente, estes benefícios trazem o custo de micronúcleos terem a necessidade de passar informações dentro e fora do espaço do núcleo através de um processos chamado troca de contexto. Trocas de contexto trazem uma degradação de performance considerável." Estas afirmações não fazem parte de um artigo revisto por partes.
47. ↑ Härtig 97
48. ↑ ^{a b} «A família de núcleos L4 - Visão geral» 
49. ↑ «Arquitetura de nanonúcleo do KeyKOS». Consultado em 9 de janeiro de 2010. Arquivado do original em 21 de junho de 2011 
50. ↑ «Ssistema Operativo de Exonúcleo do MIT». Consultado em 9 de janeiro de 2010. Arquivado do original em 23 de março de 2011 
51. ↑ «Nuclear · Lecture Note for 221». yutingwang.gitbooks.io. Consultado em 10 de abril de 2024 
52. ↑ Hansen 2001 (os), pp.17-18
53. ↑ «Versão BSTJ do C.ACM Jornal Unix» 
54. ↑ «Introdução e Visão Geral do Sistema Multics, por F. J. Corbató e V. A. Vissotsky.» 
55. ↑ ^{a b} «O Sistema UNIX — A Única Especificação do Unix» 
56. ↑ «Linux 2.6: Ele Vale Mais!, por David A. Wheeler, 12 de outubro de 2004» 
57. ↑ Esta comunidade se reúne em sua maioria no Desenvolvimento de SO Bona Fide, O Fórum de Mensagens Mega-Tokyo e outros sítios de entusiastas de sistemas operativos.
58. ↑ «XNU: O núcleo». Consultado em 9 de janeiro de 2010. Arquivado do original em 22 de agosto de 2011 
59. ↑ Sheldon Leemon. «O que torna isso tão ótimo! (Amiga Commodore)». Creative Computing. Consultado em 5 de fevereiro de 2006 
60. ↑ «LinuxWorld IDC: Consolidação de Windows acontece». Consultado em 9 de janeiro de 2010. Arquivado do original em 16 de dezembro de 2008 
61. ↑ «Histórico do Windows: Histórico de Produtos de Mesa de Trabalho» 
62. ↑ Holwerda, Thom (7 de fevereiro de 2009). «Windows 7 ganha escalonamento de espaço de usuário». OSNews. Consultado em 28 de fevereiro de 2009 
63. ↑ «O micronúcleo Fiasco - Visão geral» 
64. ↑ «L4Ka - A família L4 de micronúcleos e amigos» 
65. ↑ «Visão Geral do SSistema operativo de tempo-real» 

Referências

[editar | editar código-fonte]

• Roch, Benjamin (2004). «Núcleo Monolítico x Micronúcleo» (PDF). Consultado em 12 de outubro de 2006. Arquivado do original (PDF) em 1 de novembro de 2006 
• Silberschatz, Abraham; James L. Peterson, Peter B. Galvin (1991). Operating system concepts. Boston, Massachusetts: Addison-Wesley. 696 páginas. ISBN 0-201-51379-X  A referência emprega parâmetros obsoletos |coautor= (ajuda)
• Deitel, Harvey M. (1984) [1982]. An introduction to operating systems revisited first edition ed. [S.l.]: Addison-Wesley. 673 páginas. ISBN 0-201-14502-2 
• Denning, Peter J. (dezembro de 1976). «Fault tolerant operating systems». ACM Computing Surveys. 8 (4): 359–389. ISSN 0360-0300. doi:10.1145/356678.356680 
• Denning, Peter J. (abril de 1980). «Why not innovations in computer architecture?». ACM SIGARCH Computer Architecture News. 8 (2): 4–7. ISSN 0163-5964. doi:10.1145/859504.859506 
• Hansen, Per Brinch (abril de 1970). «The nucleus of a Multiprogramming System». Communications of the ACM. 13 (4): 238–241. ISSN 0001-0782. doi:10.1145/362258.362278 
• Hansen, Per Brinch. Operating System Principles. Englewood Cliffs: Prentice Hall. 496 páginas. ISBN 0-13-637843-9 
• Hansen, Per Brinch (2001). «The evolution of operating systems» (pdf). Consultado em 24 de outubro de 2006 incluído em livro: Per Brinch Hansen (ed.). «1» (PDF). Classic operating systems: from batch processing to distributed systems. New York,: Springer-Verlag. pp. 1–36. ISBN 0-387-95113-X 
• Hermann Härtig, Michael Hohmuth, Jochen Liedtke, Sebastian Schönberg, Jean Wolter A performance de sistemas baseados no núcleo μ [7] ACM SIGOPS Operating Systems Review, v.31 n.5, p. 66-77, Dec. 1997
• Houdek, M. E., Soltis, F. G., and Hoffman, R. L. 1981. IBM System/38 support for capability-based addressing. In Proceedings of the 8th ACM International Symposium on Computer Architecture. ACM/IEEE, pp. 341–348.
• Intel Corporation (2002) The IA-32 Architecture Software Developer’s Manual, Volume 1: Basic Architecture
• Levin, R.; E. Cohen, W. Corwin, F. Pollack, William Wulf (1975). «Policy/mechanism separation in Hydra». ACM Symposium on Operating Systems Principles / Proceedings of the fifth ACM symposium on Operating systems principles: 132–140  A referência emprega parâmetros obsoletos |coautor= (ajuda)
• Levy, Henry M. (1984). Capability-based computer systems. Maynard, Mass: Digital Press. ISBN 0-932376-22-3 
• Liedtke, Jochen. Sobre a construção do núcleo µ, Proc. 15th ACM Symposium on Operating System Principles (SOSP), December 1995
• Linden, Theodore A. (dezembro de 1976). «Operating System Structures to Support Security and Reliable Software». ACM Computing Surveys. 8 (4): 409–445. ISSN 0360-0300. doi:10.1145/356678.356682  [8]
• Lorin, Harold (1981). Operating systems. Boston, Massachusetts: Addison-Wesley. pp. 161–186. ISBN 0-201-14464-6 
• Schroeder, Michael D.; Jerome H. Saltzer (março de 1972). «A hardware architecture for implementing protection rings». Communications of the ACM. 15 (3): 157–170. ISSN 0001-0782. doi:10.1145/361268.361275  A referência emprega parâmetros obsoletos |coautor= (ajuda)
• Shaw, Alan C. (1974). The logical design of Operating systems. [S.l.]: Prentice-Hall. 304 páginas. ISBN 0-13-540112-7 
• Tanenbaum, Andrew S. (1979). Structured Computer Organization. Englewood Cliffs, New Jersey: Prentice-Hall. ISBN 0-13-148521-0 
• Wulf, W.; E. Cohen, W. Corwin, A. Jones, R. Levin, C. Pierson, F. Pollack (junho de 1974). «HYDRA: o núcleo do um sistema operativo multiprocessado». Communications of the ACM. 17 (6): 337–345. ISSN 0001-0782. doi:10.1145/355616.364017  A referência emprega parâmetros obsoletos |coautor= (ajuda) [9]
• Baiardi, F.; A. Tomasi, M. Vanneschi (1988). Architettura dei Sistemi di Elaborazione, volume 1 (em italiano). [S.l.]: Franco Angeli. ISBN 88-204-2746-X  A referência emprega parâmetros obsoletos |coautor= (ajuda)
• Swift, Michael M; Brian N. Bershad , Henry M. Levy, Improving the reliability of commodity operating systems, [10] ACM Transactions on Computer Systems (TOCS), v.23 n.1, p. 77-110, February 2005

Leituras importantes

[editar | editar código-fonte]

• 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

[editar | editar código-fonte]

• 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