Saltar para o conteúdo

Núcleo (sistema operacional): diferenças entre revisões

Origem: Wikipédia, a enciclopédia livre.
Explorar interativamente o histórico
← Ver a alteração anteriorVer a alteração posterior →
Conteúdo apagado Conteúdo adicionado
VisualTexto wiki
RibotBOT (discussão | contribs)
54 542 edições
Etiqueta: Remoção considerável de conteúdo
Linha 19: Linha 19:
Geralmente um núcleo vai fornecer recursos para [[escalonamento de processos]] de baixo nível,<ref name="Deitel82sched">Para escalonamento de processos de baixo nível veja Deitel 82, ch. 10, pp. 249–268.</ref> [[comunicação entre processos]], [[sincronização]] de processos, [[troca de contexto]], manipulação de [[bloco de controle de processo|blocos de controle de processo]], gerenciamento de [[interrupção de hardware|interrupções]], criação e destruição de processos, e suspensão e continuação de processos (veja [[estados de processos]]).<ref name="Deitel82" /><ref name="Hansen70" />
Geralmente um núcleo vai fornecer recursos para [[escalonamento de processos]] de baixo nível,<ref name="Deitel82sched">Para escalonamento de processos de baixo nível veja Deitel 82, ch. 10, pp. 249–268.</ref> [[comunicação entre processos]], [[sincronização]] de processos, [[troca de contexto]], manipulação de [[bloco de controle de processo|blocos de controle de processo]], gerenciamento de [[interrupção de hardware|interrupções]], criação e destruição de processos, e suspensão e continuação de processos (veja [[estados de processos]]).<ref name="Deitel82" /><ref name="Hansen70" />


ABCDEF
== Finalidades básicas do núcleo ==
O principal propósito do núcleo é gerenciar os recursos do computador e permitir que outros programas rodem e usem destes recursos.<ref name="Wulf74"/> Tipicamente estes recursos consistem de:
* A [[unidade de processamento central]] (CPU, o processador). Esta é a parte mais central de um sistema de computação, responsável por ''rodar'' ou ''executar'' programas nele. O núcleo têm 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)
* A [[memória de acesso aleatório|memória]]. A memória é usada para armazenar ambos 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.
* Qualquer dispositivo de [[entrada/saída]] presente no computador, tais como teclado, rato, 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.<ref name="Wulf74" />

Núcleos geralmente não oferecem métodos para [[sincronização]] e [[comunicação entre processos]] (IPC {{en}}).

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 que porções da memória o aplicativo pode acessar.<ref name="Levy84">Levy 1984, p.5</ref> (Para esta introdução, processo, aplicativo e programa são usados como sinônimos.)<!-- uma definição introdutória clara de processo está faltando --> O [[gerenciamento de processos]] do núcleo deve levar em conta o equipamento de hardware embarcado para [[proteção de memória]].<ref>Needham, R.M., Wilkes, M. V. ''[http://comjnl.oxfordjournals.org/cgi/content/abstract/17/2/117 Domínio de proteção e gerenciamento de processos]'', Computer Journal, vol. 17, no. 2 de maio de 1974, pp 117-120.</ref>

Para rodar um aplicativo, um núcleo geralmente cria um [[espaço de endereçamento]] para o aplicativo, carrega o arquivo contendo de instruções do programa na memória (talvez via [[paginação por demanda]]), cria uma [[Pilha de chamada|pilha]] para o programa e ramos para uma dada localização dentro do programa, iniciando, portanto a sua execução.<ref name="OS-Concepts">Silberschatz 1990</ref>

Núcleos [[multitarefa]] são capazes de dar ao usuário a ilusão de que um número de processos que esta rodando simultaneamente no sistema é maior do que o número de processos que aquele sistema é fisicamente capaz de rodar simultaneamente. Usualmente, o número de processos que um sistema pode rodar simultaneamente é igual o 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 [[preemptividade|preemptivo]], o núcleo dará a todos programas uma parcela do tempo e vai alternar de processo a processo tão rapidamente que dará ao usuário a impressão de como se os processos estivessem sendo executados simultaneamente. O núcleo utiliza [[algoritmo de escalonamento|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 {{en}}) e as principais implementações são [[memória compartilhada]], [[troca de mensagem|troca de mensagens]] e [[chamada de procedimento remoto|chamadas de procedimento remoto]] (veja [[computação concorrente]]).

Outros sistemas (particularmente em computadores menores, menos potentes) podem fornecer [[multitarefa#Multitarefa de cooperação|multitarefa de cooperação]], em que cada processo é permitido rodar sem ininterruptamente até que ele faça uma requisição especial que avisa ao núcleo que ele pode alternar para outro processo. Tais requisições são conhecidos como "indulgências" (yielding{{en}}, e tipicamente ocorrem em resposta a um pedido para comunicação entre processos, ou para esperar até o acontecimento de um evento. Versões mais antigas de ambos [[Microsoft Windows]] e [[Mac OS]] utilizaram o conceito de multitarefa cooperativa, mas alternaram para esquemas preemptivos conforme a potência dos computadores alvo de seu mercado aumentava{{Carece de fontes}}.

O sistema operativo pode também suportar o [[multiprocessamento]] ([[multiprocessamento simétrico]] (SMP {{en}}), 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-giro]]s) 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 a memória do sistema e deve permitir que processos acessem a memória com segurança conforme a sua necessidade. Frequentemente o primeiro passo para isso é o [[endereçamento virtual]], geralmente alcançado através da [[paginação]] e/ou [[Segmentação de memória|segmentação]]. Endereçamento virtual permite ao núcleo fazer com que um dado endereço físico pareça ser outro endereço, o endereço virtual. Espaços de endereço virtual podem ser diferentes para diferentes processos; a memória que um processos acessa em um endereço (virtual) particular pode ser diferente da que um outro processo acessa pelo mesmo endereço. Isto permite a todos programas funcionar como se ele fosse o único em execução, além do núcleo, e por isso evita que aplicativos travem uns aos outros.<ref name="OS-Concepts"/>

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{{en}}). 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 o núcleo 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 sedo reservada para o núcleo ([[espaço de núcleo]]) e o outro para os aplicativos ([[espaço de usuário]]). Os aplicativos não tem permissão do processador para acessar a memória do núcleo, portanto prevenindo 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 algumas núcleos de pesquisa (ex. [[Singularity]]) usarem outros métodos.

=== Gerenciamento de dispositivos ===
Para realizar funções úteis, processos precisam acessar [[periférico]]s conectados ao computador, que são controlados pelo núcleo através do [[driver de dispositivo|driver do dispositivo]]. Por exemplo, para mostrar ao usuário algo utilizando a tela, um aplicativo teria que fazer um requisição ao núcleo que encaminharia a requisição para o seu driver de tela, que é responsável por realmente tracejar os carácteres/pixeis.<ref name="OS-Concepts"/>

Um núcleo deve manter uma lista de dispositivos disponíveis. Esta lista pode ser conhecida de antemão (ex. em um sistema embarcado onde o núcleo será reescrito se o hardware disponível mudar), configurado pelo usuário (típico em computadores pessoais antigos e em sistemas projetados para uso pessoal) ou detectado pelo sistema durante a execução (normalmente chamado [[Ligar e Usar]]).

Em um sistema "Ligar e Usar", um dispositivo realizar primeiro uma sondagem em nos diferentes [[barramento]]s de hardware, como [[Interconector de Componentes Periféricos]] (PCI{{en}}) ou [[Universal Serial Bus|Barramento Serial Universal]] (USB{{en}}), para detectar os dispositivos instalados, depois busca os drivers apropriados.

Como o gerenciamento de dispositivos é um tópico muito especifico do SO, estes drivers são manipulados de modos diferentes por cada tipo de desenho de núcleo, mas em todos os casos, o núcleo tem que fornecer a [[entrada/saída]] para permitir que os drivers acessem fisicamente seus dispositivos através alguma porta ou localização da memória. Decisões muito importantes precisam ser feitas ao projetar o sistema de gerenciamento de dispositivos, já que em alguns projetos de acesso podem envolver [[troca de contexto|trocas de contexto]] , tornando a operação custosa para o processador e causando um gasto excessivo de recursos.{{Carece de fontes|data=Janeiro de 2010}}

=== Chamadas do Sistema ===
<!-- Esta parece uma seção de "perspectiva rasa", uma definição mais genérica ajudaria bastante -->
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.<ref>{{cite book |last= Tanenbaum|first=Andrew S.|authorlink=Andrew S. Tanenbaum |title=Modern Operating Systems |edition=3rd Edition |series= |date= |year=2008 |publisher=Prentice Hall |isbn=0-13-600663-9 |pages=50–51 |quote=. . . 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 . . . }}</ref>

O método de invocar as funções do núcleo varia de núcleo para núcleo. Se o isolamento de memória está sendo usado, é impossível para um processo de usuário chamar o núcleo diretamente, por 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 do 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 do Núcleo ==
== Decisões de desenho do Núcleo ==

Revisão das 19h57min de 8 de fevereiro de 2012

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

Em computação, o núcleo ou cerne (em inglês: kernel) é o componente central do sistema operativo da maioria dos computadores; ele serve de ponte entre aplicativos e o processamento real de dados feito a nível de hardware. As responsabilidades do núcleo incluem gerenciar os recursos do sistema (a comunicação entre componentes de hardware e software).[1] 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.

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 tentarão alcançar seus objetivos executando todos 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.[2] Uma gama de possibilidades existem entre estes extremos.

Visão geral

Uma visão típica de uma arquitetura de computadores como séries de camadas de abstração: hardware, firmware, montador, núcleo, sistema operativo e aplicativos (veja também Organização Estruturada de Computadores, por Andrew S. Tanenbaum.).

Na definição do 'núcleo', 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."[3]

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,[4] 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. Para evitar ter um núcleo, teria-se 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][5][6][7] (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.[8] 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.[9] 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 (ex. uma função em modo de usuário pode depender de memória estando sujeita a paginação por demanda, mas como o próprio núcleo fornece esta facilidade, ele não pode utilizá-la, pois ele pode não permanecer na memória para fornecer esta facilidade) e a falta de reentrância, logo o seu desenvolvimento torna-se ainda mais difícil para engenheiros de software.

Geralmente um núcleo vai fornecer recursos para escalonamento de processos de baixo nível,[10] 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).[5][7]

ABCDEF

Decisões de desenho do Núcleo

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 de 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 oferecidos 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[11][12]); quer eles sejam suportados pelo hardware ou baseados em linguagem; quer eles sejam mais um mecanismo aberto ou ma 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.[13] 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[14] 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),[15] e endereçamento baseado em capacidades.[16]

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.[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,[11][12] 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 processos 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).[17] 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,[18] 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 hardware para domínios hierárquicos de proteção[19] 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.[18] 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.[20][21] 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.[22] No entanto, falta de suporte no hardware pode não ser problema, para sistemas que escolhem usar uma proteção baseada em linguagem.[23]

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.[18][24][25][26][27]

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.[24] 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.[24]

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

Desvantagens incluem:

  • Demora maior para a inicialização efetiva do aplicativo. Aplicativos deve ser verificadas sempre que elas são iniciadas para garantir que eles foram compiladas utilizando um compilador "corret", ou podem necessitar de recompilação de ambos código fonte ou bytecode.
  • Sistema s 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.[29] 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.[7]

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[30][31]). 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.[7]

Abordagens de desenvolvimento de todo o núcleo

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.[32][33] 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, uma 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 do 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,[33] 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][7] 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][7] 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.[34][35][36] 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;[37] na verdade, todo módulo que necessite de proteção é portanto preferivelmente incluído no núcleo.[37] 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.[2] 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 utilizado para 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"[38] 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.
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 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.[7] Ele também torna possível alternar dinamicamente entre sistemas operativos e manter mais de um deles ativos simultaneamente.[7]

Núcleos monolíticos x micronúcleos

Conforme o núcleo do computador crescem, um número de problemas se tornam evidentes. 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.[39] 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.[40] Há méritos em ambos argumentos presentes no debate Tanenbaum–Torvalds.

Performances

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

A performance de micronúcleos construídos nos anos 1980 e começos dos 1990 era terrível.[3][42] Estudos empíricos que mediram a performance destes micronúcleos não analisaram os motivos para tal ineficiência .[3] 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,[3] devido a maior frequência de comunicação entre processos[3] e a maioria frequência de trocas de contexto.[3]

De fato, como foi conjeturado em 1995, os motivos para a terrível performance dos micronúcleos pode 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.[3] 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.[3]

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

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

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.

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.[44]

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 in 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 operativo que usa o exonúcleo para simular as astrações de um sistema operativo conhecido, ou ele pode desenvolver abstrações específicas para aquele aplicativo para ume performance superior.[45]

História do desenvolvimento do núcleo

Núcleos dos primeiros sistemas operativos

Ver artigo principal: História dos sitemas 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 "metal descoberto", desde que os autores destes programas estiverem dispostos a trabalhar sem nenuma abstração de hardware ou suporte a sistema operativo. Os primeiros computadores operaram deste 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 "metal descoberto" ainda é usada hoje em alguns consoles de vídeo-jogo e sistemas embarcados, mas no geral, computadores novos usam sistemas operativos e núcleos modernos.

Em 1969 o RC 4000 Multiprogramming System introduziu a filosofia de desenvolvimento de sistemas de pequeno nucleus "na qual sistemas operativos para diferentes propósitos poderiam ser criados de maneira metódica",[46] 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 onde operadores de computador estavam buscando novos modos de conseguir com que as pessoas usarem o tempo livre em seus computadores. Uma das maiores evoluções durantes esta era foi o tempo compartilhado, onde um número de usuários conseguiria pequenas parcelas do tempo do computador, em uma taxa que pareceria que eles estavam cada um conectado a sua própria máquina, embora mais lenta.[47]

O desenvolvimento dos sistemas de tempo compartilhado levou a inúmeros problemas. Um deles foi que usuários, particularmente em universidades, onde 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.[48] 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.[49] Por exemplo, impressoras eram representadas como um "ficheiro" em uma localização conhecida — quando dados eram copiados para o arquivo, ela imprimia-os. 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 permitir 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 deste modo 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; primeira, a enorme coleção de programas de utilidades que guiam a maioria das operações.[49] 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[8] 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 baites não era mais universalmente aplicável como antes. Embora um terminal pudesse ser tratado como um ficheiro ou fluxo de baites, de que se exibia ou lia, o mesmo não parecia ser verdade para a interface gráfica. Rede se tornou outro problema. Mesmo se a comunicação de rede pudesse ser comparada ao acesso de ficheiros, a arquitetura de baixo nícel 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.[50]

Derivados modernos do Unix são geralmente baseados um 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 passa-tempo 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.[51]

Mac OS

Ver artigo principal: History of Mac OS

A Apple lançou Mac OS pela primeira vez em 1984, empacotado com o seu computador pessoal Macintosh Apple. Pelos primeiros lançamento, 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 tempo, o sistema operativo 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 Mac OS X é 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.[52]

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

Microsoft Windows

Ver artigo principal: História do 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.[54] A arquitetura do núcleo do windows nt é considerada híbrida pois o pŕoprio 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.[55] 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 Arcabouço de driver de espaço de usuário no windows vista, e escalonamento de linha de execução no espaço de usuário no Windows 7,[56] deslocou mais recursos do núcleo 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. Um 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.[43] Implementações mais novas como Fiasco e Pistachio são capazes de executar o Linux junto com outros processo L4 em espaços de endereçamento separados.[57][58]

QNX é um Sistema Operativo de tempo-real com um projeto de micronúcleo minimalista que vem sendo desenvolvido deste 1982, sendo mais bem-sucedido do que o Mach em alcançar os objetivos do paradigma do micronúcleo.[59] Ele é usado principalmente em sistemas embarcados e ẽm 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

Busca Wikiversidade A Wikiversidade possui materiais sobre Operating Systems/Kernel Models at:

Referências

  1. ↑ a b c d e f g h i Wulf 74 pp.337-345
  2. ↑ a b Roch 2004
  3. ↑ a b c d e f g h Liedtke 95
  4. ↑ Tanenbaum 79, chapter 1
  5. ↑ a b Deitel 82, p.65-66 cap. 3.9
  6. ↑ Lorin 81 pp.161-186, Schroeder 77, Shaw 75 pp.245-267
  7. ↑ a b c d e f g h Brinch Hansen 70 pp.238-241
  8. ↑ 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.
  9. ↑ «Desenvolvimento do SO Bona Fide - Tutorial do Bran para Desenvolvimento de Núcleo, por Brandon Friesen» 
  10. ↑ Para escalonamento de processos de baixo nível veja Deitel 82, ch. 10, pp. 249–268.
  11. ↑ a b Denning 1976
  12. ↑ a b Swift 2005, p.29 quote: "isolação, controle de recursos, verificação de decisão (checagem), e recuperação de erros."
  13. ↑ 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.
  14. ↑ Swift 2005 p.26
  15. ↑ Intel Corporation 2002
  16. ↑ Houdek et al. 1981
  17. ↑ 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"
  18. ↑ a b c Linden 76
  19. ↑ Schroeder 72
  20. ↑ Stephane Eranian & David Mosberger, Memória Virtual no núcleo Linux IA-64, Prentice Hall PTR, 2002
  21. ↑ Silberschatz & Galvin, Conceitos de Ssistema Operativo, 4th ed, pp445 & 446
  22. ↑ Hoch, Charles; J. C. Browne (Universidade do Texas, Austin) (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 
  23. ↑ a b «Uma Abordagem a Segurança Baseada em Linguagem, Schneider F., Morrissett G. (Universidade Cornell) e Harper R. (Universidade Carnegie Mellon)» (PDF) 
  24. ↑ 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. Em procedimentos da 21ª Conferência Nacional de Segurança de Sistemas de Informação, páginas 303–314, Out. de 1998. [1].
  25. ↑ 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.
  26. ↑ J. Anderson, Estudo de Planejamento de Segurança de Computadores, Air Force Elect. Systems Div., ESD-TR-73-51, Outubro de 1972.
  27. ↑ * 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 
  28. ↑ 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 
  29. ↑ Dijkstra, E. W. Processos Sequenciais Cooperadores. Math. Dep., Technological U., Eindhoven, Set. 1965.
  30. ↑ «SHARER, um sistema de compartilhamento de tempo para o CDC 6600». Consultado em 7 de janeiro de 2007 
  31. ↑ «Supervisores Dinâmicos - seu projeto e construção». Consultado em 7 de janeiro de 2007 
  32. ↑ Baiardi 1988
  33. ↑ a b Levin 75
  34. ↑ Denning 1980
  35. ↑ 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]
  36. ↑ 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."
  37. ↑ 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."
  38. ↑ «Códigos Abertos : Vozes da Revolução do Código Aberto» 
  39. ↑ Endereçamento virtual é comumente mais obtido através da unidade de gerenciamento de memória incorporado.
  40. ↑ Registros do debate entre Torvalds e Tanenbaum podem ser encontrados em dina.dk, groups.google.com, oreilly.com e Sítio do Andrew Tanenbaum
  41. ↑ 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.
  42. ↑ Härtig 97
  43. ↑ a b «A família de núcleos L4 - Visão geral» 
  44. ↑ «Arquitetura de nanonúcleo do KeyKOS» 
  45. ↑ «Ssistema Operativo de Exonúcleo do MIT» 
  46. ↑ Hansen 2001 (os), pp.17-18
  47. ↑ «Versão BSTJ do C.ACM Jornal Unix» 
  48. ↑ «Introdução e Visão Geral do Sistema Multics, por F. J. Corbató e V. A. Vissotsky.» 
  49. ↑ a b «O Sistema UNIX — A Única Especificação do Unix» 
  50. ↑ «Linux 2.6: Ele Vale Mais!, por David A. Wheeler, 12 de outubro de 2004» 
  51. ↑ 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.
  52. ↑ «XNU: O núcleo» 
  53. ↑ Sheldon Leemon. «O que torna isso tão ótimo! (Amiga Commodore)». Creative Computing. Consultado em 5 de fevereiro de 2006 
  54. ↑ «LinuxWorld IDC: Consolidação de Windows acontece» 
  55. ↑ «Histórico do Windows: Histórico de Produtos de Mesa de Trabalho» 
  56. ↑ 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 
  57. ↑ «O micronúcleo Fiasco - Visão geral» 
  58. ↑ «L4Ka - A família L4 de micronúcleos e amigos» 
  59. ↑ «Visão Geral do Ssistema Operativo de Tempo-real» 

Referências

Leituras importantes

Ligações externas

Obtida de "https://pt.wikipedia.org/w/index.php?title=Núcleo_(sistema_operacional)&oldid=28776196"