Mach (kernel) - Mach (kernel)

Mach
Desenvolvedor (s) Richard Rashid
Avie Tevanian
lançamento inicial 1985 ; 36 anos atrás ( 1985 )
Versão estável
3.0 / 1994 ; 27 anos atrás ( 1994 )
Modelo Microkernel
Local na rede Internet O Projeto Mach

Mach ( / m ɑː k / ) é um kernel desenvolvido na Carnegie Mellon University por Richard Rashid e Avie Tevanian e derivado originalmente do 4.3BSD para dar suporte à pesquisa de sistema operacional , principalmente computação distribuída e paralela . Mach é freqüentemente mencionado como um dos primeiros exemplos de microkernel . No entanto, nem todas as versões do Mach são microkernels. Derivados de Mach são a base do kernel do sistema operacional no GNU Hurd e da Apple 's XNU kernel usado no MacOS , iOS , iPadOS , tvOS e watchOS .

O projeto na Carnegie Mellon foi executado de 1985 a 1994, terminando com Mach 3.0, que é um verdadeiro microkernel . Mach foi desenvolvido como um substituto para o kernel na versão BSD do Unix , então nenhum novo sistema operacional teria que ser projetado em torno dele. Mach e seus derivados existem em vários sistemas operacionais comerciais. Isso inclui todos os que usam o kernel do sistema operacional XNU , que incorpora um Mach anterior não microkernel como um componente principal. O sistema de gerenciamento de memória virtual Mach também foi adotado no 4.4BSD pelos desenvolvedores BSD no CSRG , e aparece em sistemas Unix derivados do BSD modernos, como o FreeBSD .

Mach é o sucessor lógico do kernel Accent da Carnegie Mellon . O desenvolvedor líder do projeto Mach, Richard Rashid , trabalha na Microsoft desde 1991; ele fundou a divisão de Pesquisa da Microsoft . Outro dos desenvolvedores originais do Mach, Avie Tevanian , foi anteriormente chefe de software da NeXT e , em seguida, Diretor de Tecnologia de Software da Apple Inc. até março de 2006.

História

Nome

Enquanto os desenvolvedores, uma vez que durante a fase de nomeação, teve de bicicleta para o almoço através de poças de lama da chuva Pittsburgh, Tevanian brincou a palavra "muck" poderia servir como um backronym para o seu M em última U ser (ou M ultiprocessor U niversal) C omunicação K ernel. O engenheiro de CMU italiano Dario Giuse perguntou mais tarde ao líder do projeto Rick Rashid sobre o título atual do projeto e recebeu "MUCK" como resposta, embora não soletrado, mas apenas pronunciado como IPA:  [mʌk] que ele, de acordo com o alfabeto italiano , escreveu como Mach . Rashid gostou tanto da grafia de Giuse como "Mach" que prevaleceu.

Tubos Unix

Um conceito chave no sistema operacional Unix original era a ideia de um pipe . Um pipe era uma abstração que permitia que os dados fossem movidos como um fluxo não estruturado de bytes de um programa para outro. Usando pipes, os usuários (ou programadores) podem vincular vários programas para completar tarefas, alimentando dados por meio de vários pequenos programas. Isso contrastava com os sistemas operacionais típicos da época, que exigiam um único programa grande que pudesse lidar com toda a tarefa ou, alternativamente, usava arquivos para transmitir dados, o que era caro e demorado.

Pipes foram construídos no sistema de entrada / saída subjacente . Esse sistema, por sua vez, era baseado em um modelo em que se esperava que os motoristas "bloqueassem" periodicamente enquanto aguardavam a conclusão das tarefas. Por exemplo, um driver de impressora pode enviar uma linha de texto para uma impressora de linha e não ter nada a fazer até que a impressora conclua a impressão dessa linha. Nesse caso, o driver indicaria que estava bloqueado e o sistema operacional permitiria que algum outro programa fosse executado até que a impressora indicasse que estava pronta para mais dados. No sistema de tubos, o recurso limitado era a memória e, quando um programa preenchia a memória atribuída ao tubo, ele bloqueava naturalmente. Normalmente, isso faria com que o programa de consumo fosse executado, esvaziando o tubo novamente. Em contraste com um arquivo, onde todo o arquivo deve ser lido ou escrito antes que o próximo programa possa usá-lo, os canais fazem com que a movimentação de dados entre vários programas ocorra de forma fragmentada, sem qualquer intervenção do programador.

No entanto, a implementação de tubos como buffers de memória significava que os dados estavam sendo copiados de um programa para outro, uma operação que consumia muito tempo e muitos recursos. Isso tornou o conceito de tubo inadequado para tarefas em que era necessária uma resposta rápida ou baixa latência, como é o caso da maioria dos drivers de dispositivo . Em vez disso, o kernel do sistema operacional e a maioria das funcionalidades principais foram escritos como um único grande programa. Conforme o sistema operacional adicionou novas funcionalidades ( rede de computadores , por exemplo), o tamanho e a complexidade do kernel também aumentaram.

Novos conceitos

Os pipes Unix ofereciam um sistema conceitual que poderia ser usado para construir soluções arbitrariamente complexas a partir de pequenos programas de interação. Por serem menores, esses programas eram fáceis de programar e manter, e tinham interfaces bem definidas que simplificavam a programação e a depuração. Essas qualidades são ainda mais valiosas para drivers de dispositivo, onde o tamanho pequeno e o desempenho sem bugs são extremamente importantes. Havia um forte desejo de modelar o próprio kernel na mesma base de pequenos programas de interação.

Um dos primeiros sistemas a usar um sistema semelhante a um tubo como base para o sistema operacional foi o kernel Aleph desenvolvido na Universidade de Rochester . Isso introduziu o conceito de portas , que eram essencialmente uma implementação de memória compartilhada . Em Aleph, o próprio kernel foi reduzido para fornecer acesso ao hardware, incluindo memória e as portas, enquanto os programas convencionais usando o sistema de portas implementaram todo o comportamento, de drivers de dispositivo a programas de usuário. Esse conceito reduziu bastante o tamanho do kernel e permitiu aos usuários experimentar diferentes drivers simplesmente carregando-os e conectando-os em tempo de execução. Isso facilitou muito os problemas ao desenvolver um novo código de sistema operacional, que de outra forma geralmente exigia que a máquina fosse reiniciada. O conceito geral de um pequeno kernel e drivers externos tornou-se conhecido como microkernel.

Aleph foi implementado em minicomputadores Data General Eclipse e foi fortemente vinculado a eles. Essa máquina estava longe de ser ideal, pois exigia que a memória fosse copiada entre os programas, o que envolvia uma considerável sobrecarga de desempenho. Também era muito caro. No entanto, Aleph provou que o sistema básico era sólido e passou a demonstrar o agrupamento de computadores copiando a memória em uma interface Ethernet antiga .

Nessa época, uma nova geração de processadores centrais (CPUs) estava chegando ao mercado, oferecendo espaços de endereço de 32 bits e (inicialmente opcional) suporte para uma unidade de gerenciamento de memória (MMU). A MMU manipulou as instruções necessárias para implementar um sistema de memória virtual (VM), mantendo o controle de quais páginas de memória estavam em uso por vários programas. Isso ofereceu uma nova solução para o conceito de porta, usando o mecanismo de cópia na gravação usado pela VM . Em vez de copiar dados entre programas, tudo o que precisava ser enviado eram os dados necessários para instruir a MMU a fornecer acesso à mesma memória. Este sistema implementaria o sistema de comunicações entre processos com desempenho dramaticamente superior.

Este conceito foi adotado na Carnegie-Mellon, que adaptou Aleph para a estação de trabalho PERQ e o implementou usando cópia na gravação. A porta foi bem-sucedida, mas o kernel do Accent resultante tinha uso prático limitado porque não rodava o software existente. Além disso, Accent estava tão fortemente ligado ao PERQ quanto Aleph estava ao Eclipse.

Mach

A principal mudança entre esses kernels experimentais e o Mach foi a decisão de fazer uma versão do kernel 4.2BSD existente reimplementado nos conceitos de passagem de mensagens do Accent. Tal kernel seria binário compatível com o software BSD existente, tornando o sistema imediatamente útil para o uso diário, embora ainda seja uma plataforma experimental útil. Além disso, o novo kernel seria projetado desde o início para suportar múltiplas arquiteturas de processador, até mesmo permitindo a construção de clusters heterogêneos. Para ativar o sistema o mais rápido possível, o sistema seria implementado começando com o código BSD existente e reimplementando-o bit a bit como programas baseados em comunicação entre processos (baseados em IPC). Assim, Mach começaria como um sistema monolítico semelhante aos sistemas UNIX existentes e evoluiria mais em direção ao conceito de microkernel ao longo do tempo.

Mach começou em grande parte como um esforço para produzir um Accent altamente portátil, baseado em UNIX e claramente definido. O resultado é uma pequena lista de conceitos genéricos:

  • uma " tarefa " é um objeto que consiste em um conjunto de recursos do sistema que permitem que "threads" sejam executados
  • um " thread " é uma unidade única de execução, existe dentro de um contexto de uma tarefa e compartilha os recursos da tarefa
  • uma " porta " é uma fila de mensagens protegida para comunicação entre tarefas; tarefas próprias enviar direitos (permissões) e receber direitos para cada porta.
  • " mensagens " são coleções de objetos de dados digitados, eles só podem ser enviados para portas - não especificamente para tarefas ou threads

O Mach foi desenvolvido nos conceitos IPC do Accent, mas tornou o sistema muito mais parecido com o UNIX por natureza, podendo até mesmo rodar programas UNIX com pouca ou nenhuma modificação. Para fazer isso, Mach introduziu o conceito de porta , representando cada ponto de extremidade de um IPC bidirecional. As portas tinham segurança e direitos como arquivos no UNIX, permitindo que um modelo de proteção muito parecido com o UNIX fosse aplicado a eles. Além disso, o Mach permitia que qualquer programa controlasse privilégios que normalmente seriam concedidos apenas ao sistema operacional, a fim de permitir que os programas de espaço do usuário controlassem coisas como interação com o hardware.

No Mach, e como no UNIX, o sistema operacional novamente se torna principalmente uma coleção de utilitários. Assim como no UNIX, o Mach mantém o conceito de driver para lidar com o hardware. Portanto, todos os drivers para o hardware atual devem ser incluídos no microkernel. Outras arquiteturas baseadas em Hardware Abstraction Layer ou exokernels podem mover os drivers para fora do microkernel.

A principal diferença com o UNIX é que em vez de utilitários manipulando arquivos, eles podem lidar com qualquer "tarefa". Mais código do sistema operacional foi movido do kernel para o espaço do usuário, resultando em um kernel muito menor e no surgimento do termo microkernel . Ao contrário dos sistemas tradicionais, no Mach um processo, ou "tarefa", pode consistir em uma série de threads. Embora isso seja comum em sistemas modernos, Mach foi o primeiro sistema a definir tarefas e threads dessa maneira. O trabalho do kernel foi reduzido de essencialmente ser o sistema operacional para manter os "utilitários" e programar seu acesso ao hardware.

A existência de portas e o uso de IPC é talvez a diferença mais fundamental entre o Mach e os kernels tradicionais. No UNIX, chamar o kernel consiste em uma operação conhecida como chamada de sistema ou trap . O programa usa uma biblioteca para colocar dados em um local bem conhecido na memória e então causa uma falha , um tipo de erro. Quando o sistema é iniciado pela primeira vez, o kernel é configurado para ser o "manipulador" de todas as falhas, portanto, quando o programa causa uma falha, o kernel assume, examina as informações passadas a ele e, em seguida, executa as instruções.

Em Mach, o sistema IPC foi usado para essa função. Para chamar a funcionalidade do sistema, um programa pede ao kernel acesso a uma porta e, em seguida, usa o sistema IPC para enviar mensagens a essa porta. Embora as mensagens fossem disparadas por chamadas de sistema como seriam em outros kernels, no Mach isso era praticamente tudo o que o kernel fazia - lidar com a solicitação real dependeria de algum outro programa.

O suporte a threads e simultaneidade foi beneficiado pela passagem de mensagens com mecanismos IPC, uma vez que as tarefas agora consistiam em múltiplas threads de código que Mach podia congelar e descongelar durante o manuseio de mensagens. Isso permitiu que o sistema fosse distribuído por vários processadores, usando memória compartilhada diretamente como na maioria das mensagens Mach ou adicionando código para copiar a mensagem para outro processador, se necessário. Em um kernel tradicional, isso é difícil de implementar; o sistema deve ter certeza de que programas diferentes não tentam gravar na mesma memória de processadores diferentes. No entanto, as portas Mach, seu processo de acesso à memória, tornam-no bem definido e fácil de implementar, e se tornaram um cidadão de primeira classe nesse sistema.

O sistema IPC inicialmente tinha problemas de desempenho, então algumas estratégias foram desenvolvidas para minimizar o impacto. Como seu predecessor, o Accent , o Mach usava um único mecanismo de memória compartilhada para passar fisicamente a mensagem de um programa para outro. Copiar fisicamente a mensagem seria muito lento, então Mach depende da unidade de gerenciamento de memória (MMU) da máquina para mapear rapidamente os dados de um programa para outro. Somente se os dados forem gravados, eles terão que ser copiados fisicamente, um processo denominado " cópia na gravação ".

As mensagens também foram verificadas quanto à validade pelo kernel, para evitar que dados ruins travassem um dos muitos programas que compõem o sistema. As portas foram modeladas deliberadamente nos conceitos do sistema de arquivos UNIX. Isso permitiu ao usuário encontrar portas usando os conceitos de navegação do sistema de arquivos existentes, bem como atribuir direitos e permissões como fariam no sistema de arquivos.

O desenvolvimento sob tal sistema seria mais fácil. Não apenas o código em trabalho existiria em um programa tradicional que poderia ser construído usando as ferramentas existentes, mas também poderia ser iniciado, depurado e eliminado usando as mesmas ferramentas. Com um monokernel, um bug em um novo código derrubaria a máquina inteira e exigiria uma reinicialização, enquanto no Mach isso exigiria apenas que o programa fosse reiniciado. Além disso, o usuário pode adaptar o sistema para incluir ou excluir quaisquer recursos de que necessite. Como o sistema operacional era simplesmente uma coleção de programas, eles podiam adicionar ou remover partes simplesmente executando ou eliminando-as como fariam com qualquer outro programa.

Finalmente, no Mach, todos esses recursos foram deliberadamente projetados para serem extremamente neutros em relação à plataforma. Para citar um texto em Mach:

Ao contrário do UNIX, que foi desenvolvido sem levar em conta o multiprocessamento, Mach incorpora suporte a multiprocessamento por completo. Seu suporte a multiprocessamento também é extremamente flexível, variando de sistemas de memória compartilhada a sistemas sem memória compartilhada entre processadores. Mach é projetado para funcionar em sistemas de computador que variam de um a milhares de processadores. Além disso, o Mach é facilmente portado para muitas arquiteturas de computador variadas. Um dos principais objetivos do Mach é ser um sistema distribuído capaz de funcionar em hardware heterogêneo. ( Apêndice B , Conceitos do sistema operacional )

No entanto, existem várias desvantagens. Um relativamente comum é que não está claro como encontrar portas. No UNIX, esse problema foi resolvido com o tempo, à medida que os programadores concordavam em uma série de locais "bem conhecidos" no sistema de arquivos para servir a várias funções. Embora essa mesma abordagem funcionasse também para as portas do Mach, no Mach o sistema operacional era considerado muito mais fluido, com as portas aparecendo e desaparecendo o tempo todo. Sem algum mecanismo para localizar portas e os serviços que eles representam, muito dessa flexibilidade seria perdida.

Desenvolvimento

Mach foi inicialmente hospedado como código adicional escrito diretamente no kernel 4.2BSD existente, permitindo que a equipe trabalhasse no sistema muito antes de sua conclusão. O trabalho começou com o sistema de porta / IPC Accent já funcional e passou para as outras partes principais do sistema operacional, tarefas e threads e memória virtual. Conforme as partes foram concluídas, várias partes do sistema BSD foram reescritas para chamar o Mach, e uma mudança para o 4.3BSD também foi feita durante este processo.

Em 1986, o sistema estava completo a ponto de ser capaz de funcionar sozinho no DEC VAX . Embora fazendo pouco de valor prático, o objetivo de fazer um microkernel foi realizado. Isso foi seguido por versões no IBM RT PC e para estações de trabalho baseadas em Sun Microsystems 68030 , provando a portabilidade do sistema. Em 1987, a lista incluía as máquinas Encore Multimax e Sequent Balance , testando a capacidade do Mach de funcionar em sistemas multiprocessadores. Um lançamento público 1 foi feito naquele ano, e o lançamento 2 veio no ano seguinte.

Durante todo esse tempo, a promessa de um "verdadeiro" microkernel ainda não estava sendo cumprida. Essas primeiras versões do Mach incluíam a maior parte do 4.3BSD no kernel, um sistema conhecido como POE Server, resultando em um kernel que era na verdade maior do que o UNIX em que se baseava. A ideia, no entanto, era mover a camada UNIX do kernel para o espaço do usuário, onde poderia ser mais facilmente trabalhada e até substituída imediatamente. Infelizmente, o desempenho provou ser um grande problema e várias alterações arquitetônicas foram feitas para resolver esse problema. Problemas difíceis de licenciamento do UNIX também afetavam os pesquisadores, então esse esforço inicial para fornecer um ambiente de sistema semelhante ao UNIX não licenciado continuou a encontrar uso, bem no desenvolvimento posterior do Mach.

O Mach 3 resultante foi lançado em 1990 e gerou grande interesse. Uma pequena equipe construiu o Mach e o portou para várias plataformas, incluindo sistemas multiprocessadores complexos que estavam causando sérios problemas para os kernels de estilo antigo. Isso gerou um interesse considerável no mercado comercial, onde várias empresas estavam pensando em trocar de plataforma de hardware. Se o sistema existente pudesse ser portado para rodar em Mach, seria fácil mudar a plataforma por baixo.

O Mach recebeu um grande impulso em visibilidade quando a Open Software Foundation (OSF) anunciou que hospedaria futuras versões do OSF / 1 no Mach 2.5, e estava investigando o Mach 3 também. Mach 2.5 também foi selecionado para o sistema NeXTSTEP e vários fornecedores comerciais de multiprocessadores. Mach 3 levou a uma série de esforços para Port outras partes de sistemas operacionais para o microkernel, incluindo IBM 's Workplace OS e vários esforços por parte da Apple para construir uma versão multi-plataforma do Mac OS clássico .

Problemas de desempenho

Mach foi originalmente planejado para ser um substituto para o UNIX monolítico clássico e, por essa razão, continha muitas idéias semelhantes ao UNIX. Por exemplo, Mach usou um sistema de permissão e segurança padronizado no sistema de arquivos do UNIX. Uma vez que o kernel era privilegiado (rodando no espaço do kernel ) sobre outros servidores de SO e software, era possível que programas mal-funcionados ou mal-intencionados enviassem comandos que causariam danos ao sistema, e por esta razão o kernel verificou a validade de cada mensagem . Além disso, a maior parte da funcionalidade do sistema operacional deveria estar localizada em programas de espaço do usuário, então isso significava que precisava haver alguma maneira de o kernel conceder a esses programas privilégios adicionais, para operar no hardware, por exemplo.

Algumas das características mais esotéricas de Mach também foram baseadas neste mesmo mecanismo IPC. Por exemplo, Mach era capaz de oferecer suporte a máquinas multiprocessadas com facilidade. Em um kernel tradicional, um trabalho extensivo precisa ser realizado para torná-lo reentrante ou interrompível , já que programas em execução em processadores diferentes podem chamar o kernel ao mesmo tempo. No Mach, os bits do sistema operacional são isolados em servidores, que podem ser executados, como qualquer outro programa, em qualquer processador. Embora em teoria o kernel Mach também deva ser reentrante, na prática isso não é um problema porque seus tempos de resposta são tão rápidos que pode simplesmente esperar e atender às solicitações. Mach também incluiu um servidor que podia encaminhar mensagens não apenas entre programas, mas até mesmo pela rede, que foi uma área de intenso desenvolvimento no final dos anos 1980 e início dos 1990.

Infelizmente, o uso de IPC para quase todas as tarefas acabou tendo um sério impacto no desempenho. Benchmarks em hardware de 1997 mostraram que as implementações de servidor único UNIX baseado em Mach 3.0 eram cerca de 50% mais lentas do que o UNIX nativo.

O estudo da natureza exata dos problemas de desempenho revelou uma série de fatos interessantes. Uma era que o próprio IPC não era o problema: havia alguma sobrecarga associada ao mapeamento de memória necessário para suportá-lo, mas isso adicionava apenas uma pequena quantidade de tempo para fazer uma chamada. O resto, 80% do tempo gasto, foi devido a tarefas adicionais que o kernel estava executando nas mensagens. A principal delas foi a verificação de direitos de porta e validade da mensagem. Em benchmarks em um 486 DX-50, uma chamada de sistema UNIX padrão levou uma média de 21 μs para ser concluída, enquanto a operação equivalente com Mach IPC teve uma média de 114 μs. Apenas 18 µs disso estavam relacionados ao hardware; o resto era o kernel Mach executando várias rotinas na mensagem. Dada uma syscall que não faz nada, uma viagem de ida e volta completa no BSD exigiria cerca de 40μs, enquanto em um sistema Mach no espaço do usuário levaria pouco menos de 500μs.

Quando o Mach estava sendo usado seriamente pela primeira vez nas versões 2.x, o desempenho era mais lento do que os sistemas operacionais monolíticos tradicionais, talvez até 25%. Esse custo não foi considerado particularmente preocupante, pois o sistema também oferecia suporte a multiprocessador e fácil portabilidade. Muitos achavam que esse era um custo de pagamento esperado e aceitável. Quando Mach 3 tentou mover a maior parte do sistema operacional para o espaço do usuário, a sobrecarga tornou-se ainda maior: os benchmarks entre Mach e Ultrix em um MIPS R3000 mostraram um impacto de desempenho de até 67% em algumas cargas de trabalho.

Por exemplo, obter a hora do sistema envolve uma chamada IPC para o servidor de espaço do usuário que mantém o relógio do sistema . O chamador primeiro intercepta o kernel, causando uma troca de contexto e mapeamento de memória. O kernel então verifica se o chamador possui direitos de acesso necessários e se a mensagem é válida. Se for, há outra troca de contexto e mapeamento de memória para completar a chamada no servidor de espaço do usuário. O processo deve então ser repetido para retornar os resultados, somando um total de quatro alternâncias de contexto e mapeamentos de memória, mais duas verificações de mensagem. Essa sobrecarga rapidamente se soma a serviços mais complexos, onde frequentemente há caminhos de código passando por muitos servidores.

Essa não foi a única fonte de problemas de desempenho. Outro se concentrava nos problemas de tentar manipular a memória adequadamente quando a memória física ficava baixa e a paginação precisava ocorrer. Nos sistemas operacionais monolíticos tradicionais, os autores tinham experiência direta com quais partes do kernel chamavam quais outras, permitindo que eles ajustassem seu pager para evitar a paginação do código que estava para ser usado. No Mach isso não era possível porque o kernel não tinha ideia real do que o sistema operacional consistia. Em vez disso, eles tiveram que usar uma solução única para todos que aumentava os problemas de desempenho. Mach 3 tentou resolver esse problema fornecendo um pager simples, contando com pagers do espaço do usuário para uma melhor especialização. Mas isso acabou tendo pouco efeito. Na prática, quaisquer benefícios que ela tivesse foram eliminados pelo caro IPC necessário para chamá-la.

Outros problemas de desempenho estavam relacionados ao suporte do Mach para sistemas multiprocessadores . De meados da década de 1980 ao início da década de 1990, o desempenho das CPUs commodity cresceu a uma taxa de cerca de 60% ao ano, mas a velocidade de acesso à memória cresceu apenas 7% ao ano. Isso significava que o custo de acesso à memória cresceu tremendamente durante esse período e, como o Mach se baseava no mapeamento de memória entre programas, qualquer "falha de cache" tornava as chamadas IPC lentas.

Soluções potenciais

A sobrecarga do IPC é um grande problema para os sistemas Mach 3. No entanto, o conceito de um sistema operacional com vários servidores ainda é promissor, embora ainda exija algumas pesquisas. Os desenvolvedores devem ter cuidado para isolar o código em módulos que não chamam de servidor para servidor. Por exemplo, a maior parte do código de rede seria colocado em um único servidor, minimizando assim o IPC para tarefas normais de rede.

A maioria dos desenvolvedores, em vez disso, manteve o conceito POE original de um único grande servidor fornecendo a funcionalidade do sistema operacional. Para facilitar o desenvolvimento, eles permitiram que o servidor do sistema operacional rodasse no espaço do usuário ou no espaço do kernel. Isso permitiu que eles se desenvolvessem no espaço do usuário e tivessem todas as vantagens da ideia original do Mach e, em seguida, movessem o servidor depurado para o espaço do kernel para obter melhor desempenho. Vários sistemas operacionais foram construídos usando esse método, conhecido como co-location , entre eles Lites , MkLinux , OSF / 1 e NeXTSTEP / OPENSTEP / macOS. O microkernel Chorus tornou isso um recurso do sistema básico, permitindo que os servidores fossem elevados ao espaço do kernel usando mecanismos embutidos.

Mach 4 tentou resolver esses problemas, desta vez com um conjunto mais radical de atualizações. Em particular, descobriu-se que o código do programa normalmente não era gravável, portanto, ocorrências potenciais devido à cópia na gravação eram raras. Portanto, fazia sentido não mapear a memória entre os programas para o IPC, mas, em vez disso, migrar o código do programa que está sendo usado para o espaço local do programa. Isso levou ao conceito de "shuttles" e parecia que o desempenho havia melhorado, mas os desenvolvedores continuaram com o sistema em um estado semi-utilizável. O Mach 4 também introduziu primitivos de co-localização integrados, tornando-o parte do próprio kernel.

Em meados da década de 1990, o trabalho com sistemas de microkernel estava em grande parte estagnado, embora o mercado geralmente acreditasse que todos os sistemas operacionais modernos seriam baseados em microkernel na década de 1990. Os principais usos remanescentes do kernel Mach são o macOS da Apple e seu irmão iOS, que rodam sobre um híbrido Open Software Foundation Mach Kernel (OSFMK 7.3), denominado " XNU ", também usado no OSF / 1 . No XNU, os sistemas de arquivos, pilhas de rede e funções de gerenciamento de processo e memória são implementados no kernel; e sistema de arquivos, rede e algumas funções de gerenciamento de processo e memória são invocadas do modo de usuário por meio de chamadas de sistema comuns , em vez de passagem de mensagens; As mensagens Mach do XNU são usadas para comunicação entre processos de modo de usuário e para algumas solicitações de código de modo de usuário para o kernel e do kernel para servidores de modo de usuário.

Microkernels de segunda geração

Uma análise posterior demonstrou que o problema de desempenho do IPC não era tão óbvio quanto parecia. Lembre-se de que um único lado de uma syscall demorava 20 μs no BSD e 114 μs no Mach rodando no mesmo sistema. Dos 114, 11 foram devido à troca de contexto, idêntico ao BSD. Outros 18 foram usados ​​pela MMU para mapear a mensagem entre o espaço do usuário e o espaço do kernel. Isso soma apenas 29 μs, mais longo do que um syscall tradicional, mas não muito.

O resto, a maior parte do problema real, era devido ao kernel realizando tarefas como verificar a mensagem para direitos de acesso à porta. Embora possa parecer uma preocupação de segurança importante, na verdade, só faz sentido em um sistema semelhante ao UNIX. Por exemplo, um sistema operacional de usuário único executando um telefone celular ou robô pode não precisar de nenhum desses recursos, e este é exatamente o tipo de sistema em que o sistema operacional de escolha e escolha de Mach seria mais valioso. Da mesma forma, Mach causou problemas quando a memória foi movida pelo sistema operacional, outra tarefa que realmente só faz sentido se o sistema tiver mais de um espaço de endereço. O DOS e os primeiros Mac OS têm um único grande espaço de endereço compartilhado por todos os programas, portanto, nesses sistemas, o mapeamento não trazia nenhum benefício.

Essas realizações levaram a uma série de microkernels de segunda geração , o que reduziu ainda mais a complexidade do sistema e colocou quase todas as funcionalidades no espaço do usuário. Por exemplo, o kernel L4 (versão 2) inclui apenas sete chamadas de sistema e usa 12k de memória, enquanto Mach 3 inclui cerca de 140 funções e usa cerca de 330k de memória. As chamadas IPC sob L4 em um 486DX-50 levam apenas 5μs, mais rápido do que uma syscall UNIX no mesmo sistema e mais de 20 vezes mais rápido que Mach. É claro que isso ignora o fato de que L4 não está lidando com permissões ou segurança; mas, ao deixar isso para os programas de espaço do usuário, eles podem selecionar tanto ou tão pouca sobrecarga quanto necessário.

Os ganhos potenciais de desempenho do L4 são atenuados pelo fato de que os aplicativos de espaço do usuário frequentemente terão que fornecer muitas das funções anteriormente suportadas pelo kernel. Para testar o desempenho de ponta a ponta, o MkLinux no modo co-localizado foi comparado com uma porta L4 rodando no espaço do usuário. L4 adicionou cerca de 5% –10% de overhead, em comparação com os 29% de Mach.

Software baseado em Mach

A seguir está uma lista de kernels de sistema operacional derivados de Mach e sistemas operacionais com kernels derivados de Mach:

Veja também

Referências

links externos