Universidade do Contestado UNC Unidade Universitria de Mafra Otvio Rodolfo Piske

Sistema Operacional Mach

MAFRA

Otvio Rodolfo Piske

Introduo
O sistema operacional Mach surgiu, como um projeto da Universidade de Rochester em 1975 e se chamava RIG (Rochester Intelligent Gateway). O RIG foi escrito para uma mquina de 16 bits da Data General, o Eclipse. O objetivo principal do projeto era demonstrar que sistemas operacionais poderiam ser construdos de uma forma modular, como uma coleo de processos se comunicando com troca de mensagens. Quando um dos engenheiros que participaram do projeto, Richard Rashid, mudou-se para a universidade de Carnegie-Mellon, em 1979, ele continuou com o projeto de desenvolver tais sistemas operacionais, porm em hardware mais avanado. A mquina escolhida foi o PERQ, uma estao de trabalho com tela grfica, mouse e conexo de rede. Esse novo sistema operacional foi chamado de Accent e adicionava proteo, a capacidade de operar transparentemente sobre a rede, memria virtual de 32 bits e outros recursos. Uma verso inicial do sistema ficou pronta em 1981, mas j em 1984, uma mdia de 150 PERQs rodavam Accent. Entretanto o sistema UNIX estava ganhando espao gradativamente. Esse fato levou Rashid a iniciar uma nova verso do seu sistema operacional chamado de Mach. O sistema Mach era compatvel como o UNIX e, portanto, a maioria do software poderia ser aproveitado. Alm disso, o sistema Mach possua alguns recursos a mais que o UNIX, tais como threads e suporte a multiprocessadores. O projeto do Mach foi bastante impulsionado pela agncia de defesa americana, DARPA. A primeira verso do Mach ficou pronta em 1986 e rodava em um computador VAX 11/784 com 4 CPUs. Pouco tempo depois, ele foi portado para IBM PC/RT e Sun 3. Por volta de 1987, o Mach rodava em mquinas Encore e Sequent (ambas multiprocessadas). Logo em seguida, IBM, DEC e HP formaram a Open Software Fundation (OSF), que tinha como onjetivo tomar o controle do UNIX. A AT&T, criadora desse sistema, havia aliado-se com a Sun Microsystems para desenvolver o System V Release 4, e isso despertou o medo nos demais fabricantes. Finalmente, a OSF escolheu o Mach 2.5 como base para o seu sistema operacional, o OSF/1. Apesar de ambos sistemas conterem muitas linhas de cdigo de Berkeley e at mesmo da AT&T, o objetivo da OSF era, ao menos, controlar a direo para a qual o UNIX estava indo. Em 1988, o kernel do Mach 2.5 era grande e monoltico. Assim, nessa mesma poca, a CMU retirou todo cdigo de Berkeley e da AT&T de dentro do kernel e colocou-o no espao do usurio. O que sobrou foi um sistema microkernel.

O sistema Mach
O sistema Mach foi construdo de forma que outros sistema operacionais como UNIX ou DOS pudessem ser emulados em cima. Um dos objetivos tambm era fazer com que ele suportasse multiprocessadores e ainda assim fosse portvel. A emulao de outros sistemas operacional realizada atravs de uma arquitetura de camadas. Assim, o emulador funciona como uma camada fora do kernel e roda independentemente das outras aplicaes. Outro fato que deve ser notado que vrios servidores podem estar

rodando simultaneamente na mesma mquina, o que permite que o usurio rode programas 4.3BSD, System V e MS-DOS ao mesmo tempo.

Assim como outros sistemas microkernel, o sistema Mach apenas prov servios bsicos como gerenciamento de processos e memria, comunicao e servios de I/O. Outros servios que antes residiam no espao do kernel, foram transformados em processos de usurio, tais como o sistema de arquivos e diretrios. So5 os recursos gerenciados pelo microkernel:
o o o o o

processos threads objetos de memria portas mensagens

A estrutura bsica no sistema Mach o processo. Cada processo um ambiente onde a execuo acontece e possui um espao de memria a ele associado para guardar dados e cdigo (text) e uma ou mais pilhas. Da mesma forma, um canal de comunicao (ou porta) alocada a um processo. Uma thread uma entidade de execuo e a ela esto associadas um contador de programa e um conjunto de registradores. Alm disso, cada thread associada e um processo, mas um processo pode conter vrias threads. Um processo com uma nica thread no Mach pode ser comparado a um processo comum do UNIX. Assim, um processo no Mach consiste, basicamente, de um espao de endereamento e uma coleo de threads que executam nesse espao. A idia de processos como uma entidade ativa no existe no Mach. A execuo (ou atividade) exclusiva das threads. Assim, processos so usados apenas para alocao de recursos relacionados a um conjunto de threads.

Alm do conjunto de threads e do espao de endereamento, aos processos tambm so associadas algumas portas de comunicao. Algumas portas so especiais e todos os processos as possuem:

process port: usada para fazer a comunicao do kernel com o processo. Os servios do kernel so requisitados por essa porta apenas mandando uma mensagem a ela. Isso reduz o nmero de "system calls" a uma quantidade bastante pequena. bootstrap port: realiza a inicializao do processo quando esse carregado. Atravs dessa porta o processo fica sabendo o nome da porta do sistema, e tambm se comunicar com o seu servidor (no caso de processos UNIX emulados). exception port: usada para reportar excees causadas pelo processo. Excees tpicas so diviso por zero e execuo ilegal de instrues. Programas de depurao tambm usam essa porta para realizar seu trabalho. registered ports: so portas normalmente associadas a processos padro do sistema, tal como o servidor de nomes, por exemplo.

O processo ainda possui a propriedade de estar habilitado a executar ou bloqueado. Essa ltima opo faz com que suas threads fiquem bloqueadas independentemente de seus estados individuais. Pode-se ainda escolher em qual processador uma thread ir executar e ainda qual sua prioridade. No caso de processos emulados, especifica-se em que regio do espao de endereamento encontram-se os tratadores de chamadas de funo. Assim, os processos filhos dos emuladores herdam essas caractersticas e todas suas chamadas de sistema so direcionadas ao emulador e no ao kernel do Mach. Alm disso, cada processo possui registradores estatsticos que contabilizam, por exemplo, a quantidade de memria consumida e o tempo de execuo das threads. Um processo que esteja interessado nessas informaes pode obt-las enviando uma mensagem porta de processo.

Threads
Como mencionado anteriormente, uma thread pertence a um nico processo, entretanto, um processo pode conter vrias threads. Dessa forma, um processo uma entidade passiva at que contenha, ao menos, uma thread. Todas as threads de um processo compartilham seu espao de endereamento e os recursos a esse alocados. Mas elas podem tambm ter recursos privados. Um desses recursos uma porta de comunicao chamada "thread port", que anloga porta de processo, pois serve como ponto de acesso da thread s funes do sistema. Quem gerncia as threads o kernel do Mach, portanto estruturas especiais de controle devem estar contidas dentro do mesmo. Em um sistema com uma nica CPU, a execuo das threads "timeshared", entretanto, em sistemas multiprocessados, vrias threads podem estar executando ao mesmo tempo. Assim, o sistema deve prover mecanismos de sincronizao e excluso mutua necessrios em sistemas com essas caractersticas.

Escalonamento
O sistema de escalonamento do Mach foi bastante influenciado pela sua caracterstica de rodar em sistemas multiprocessados. Assim, pode-se assumir um sistema uniprocessado como um caso especial desse ltimo, onde o numero de CPUs igual a 1. As CPUs em um multiprocessador podem ser associadas a um "conjunto de processadores" por software. Assim, cada CPU pertence a um nico conjunto. Da mesma forma, threads tambm podem ser associadas a grupos de processadores por software. Assim, cada conjunto de processadores possui um conjunto de CPUs e outro de threads necessitando processamento. Logo, o trabalho do escalonador atribuir threads a CPUs de uma maneira eficiente. Essa estrutura tambm d grande poder aos processos, que podem atribuir threads s CPUs de forma a distribuir o trabalho entre todos os processadores. O escalonamento de threads no Mach baseado em prioridades que so valores inteiros e variam de 0 a 31 ou 127, com 0 sendo a mais alta prioridade. Existem trs prioridades associadas a cada thread:

base priority: que a prioridade que a thread pode ajustar por si s dentro de certos limites. lowest priority: que a menor prioridade que a thread pode assumir. current priority: usada (e ajustada pelo escalonador) em funo do tempo de execuo da thread e usada para definir o escalonamento da thread.

Gerenciamento de memria
O sistema de gerenciamento de memria do Mach baseado em pginas e tambm dividido em 3 partes:

pmap: esse mdulo realiza as tarefas de mais baixo nvel do gerenciamento de pginas e se comunica diretamente com o hardware (o MMU). Esse mdulo deve ser rescrito a cada vez que o sistema portado para uma outra mquina. cdigo independente de mquina: a parte do kernel que trata os sinais de pagefault, gerncia o espao de endereamento e troca as pginas. memory manager: um processo que roda no espao do usurio e gerncia a memria de forma a manter as informaes de pginas que esto carregadas e o lugar no disco onde encontram-se as pginas fora da memria.

Essa arquitetura permite que o kernel fique ainda menor e mais simples, visto que muitas funes foram transformadas em processos do usurio. Outra vantagem nesse tipo de sistema que o usurio pode escrever seu prprio gerenciador de memria, uma vez que o protocolo que funciona entre o kernel e o memory manager conhecido. Por outro lado, o kernel teve que adquirir funes para se proteger de gerenciadores de memria maliciosos ou at mesmo mal feitos.

Memria Virtual

Conceitualmente, o sistema Mach permite ao usurio ver uma grande memria linear virtual, gerenciando-a a partir de pginas. Entretanto, os programas podem usar essa memria de forma muito esparsa, aumentando assim a quantidade de informaes que deveriam ser guardadas no kernel para gerenciar todas essas pginas. Para isso, o sistema Mach utiliza o conceito de regies que determinam um endereo base e um tamanho do espao de memria usado. Um conceito bastante interessante nesse tpico o de objeto de memria, que pode ser uma pgina ou um conjunto de pginas, ou ainda um arquivo mapeado. Um objeto de memria deve ser mapeado para uma regio de memria virtual no utilizada. Arquivos mapeados dessa forma podem ser acessados com as instrues normais de leitura e escrita na memria. Quando um processo termina, seus arquivos mapeados aparecem no disco.

Compartilhamento de memria
O compartilhamento de recursos entre threads no sistema Mach automtico e no precisa ser programado. Dessa forma, se uma thread quer acessar o espao de endereamento de outra, basta faz-lo, pois o mesmo que o seu. Entretanto, esse compartilhamento no ocorre entre processos, principalmente quando esses esto localizados em processadores diferentes. Assim, o Mach fornece trs tipos de compartilhamento de memria entre processos pais e filhos:

a regio no pode ser usada pelo processo filho: indica que o processo pai no quer compartilhar aquela regio e qualquer acesso a ela ser tratado como um acesso a uma rea no alocada a regio compartilhada: o compartilhamento acontece normalmente, e qualquer modificao em uma cpia acarreta na atualizao da outra. a regio no filho uma cpia da do pai: a regio copiada e qualquer modificao ser feita somente na cpia local. Essa opo implementada utilizando-se um artifcio de copiar-na-escrita, ou seja, a cpia fsica somente realizada se houver alguma modificao na cpia. Isso economiza preciosos ciclos de CPU no caso de regies que nunca so acessadas.

Gerenciadores de Memria Externos

No Mach, possvel criar gerenciadores de memria customizados e que funcionam no lugar do gerenciador de memria padro do sistema. Esse sistema d maior flexibilidade ao Mach. Cada objeto de memria possui um gerenciador prprio. Assim, possvel implementar polticas diferentes para cada tipo de objeto diferenciando, por exemplo, o lugar onde as pginas de memria sero armazenadas e as regras de o que ser feito com o objeto aps ter sido usado.

Para isso, o gerenciador de memria necessita de 3 portas:

object port: criada pelo gerenciador de memria e usada pelo kernel para informar ao gerenciador eventos como page fault e outros. control port: criada pelo kernel para que o processo possa responder ao kernel em funo desses eventos. name port: usada como um tipo de nome que identifica o objeto.

Quando o gerenciador de memria mapeia um objeto, ele envia uma mensagem ao kernel contendo algumas as informaes do objeto. Em seguida, o kernel responde com a criao das outras duas portas (control e name ports) e notifica essa ao ao processo. Esse ltimo responde com uma mensagem de resposta contendo os demais atributos do objeto. Inicialmente, todas as pginas de um objeto mapeado esto marcadas como unreadable/unwritable para forar um evento no primeiro acesso.

Memria Compartilhada Distribuda

O sistema de gerenciamento de memria do Mach permite perfeitamente que se implemente um esquema de memria compartilhada distribuda sem que o kernel precise ser alterado. A idia ter um espao de endereamento global e linear que compartilhado por vrias mquinas diferentes. Quando uma thread faz um acesso a uma pgina que no est carregada, gerado um page fault. Quem trata esse page fault o gerenciador de memria, que deve prover a pgina ao kernel. Entretanto, no h restries quanto maneira como essa tarefa realizada. Como o Mach possui diferentes gerenciadores de memria para diferentes tipos de objetos, natural que se crie um novo tipo para atender a essa classe de aplicaes. Podese ainda criar gerenciadores de memria com caractersticas diferentes. Por exemplo, um garante sempre a consistncia dos dados, e outro garante somente que os dados so os mais recentes dentro de um intervalo de alguns segundos. Claramente o primeiro bastante mais complicado de se implementar, mas alguns algoritmos podem no necessitar de tanta qualidade de servio. Dessa forma, pode-se economizar processamento utilizando-se uma poltica mais flexvel. Pode-se ainda ter um processo gerenciador nico de memria em todo cluster, pois o sistema de mensagens do Mach transparente em relao rede. Isso facilita bastante o trabalho no caso de se ter um gerenciador de memria central.

Comunicao no Mach
O objetivo do sistema de comunicao do Mach suportar um variedade bastante grande de estilos de comunicao de uma maneira precisa e confivel. O Mach suporta mensagens assncronas, RPC, "byte streams" e outras formas de comunicao. O sistema de comunicao entre processos ainda baseado no RIG e Accent. Apesar disso, ele foi otimizado para o caso local e no o remoto. A base do sistema de comunicao do Mach uma estrutura de dados do kernel chamada porta. Quando uma thread de um processo quer se comunicar com outra de outro processo, ela envia uma mensagem para sua porta e, para receber a mensagem, a outra

retira-a da porta. Esse mecanismo suporta apenas portas unidirecionais, como pipes do UNIX. O sistema de portas seguro e confivel, pois, se uma thread envia uma mensagem por uma porta, o kernel garante que essa chegar ao seu destino. Entretanto, o sistema no garante nada em relao ao sequenciamento dessas mensagens. Quando uma thread cria uma porta, ela recebe um inteiro que identifica aquela porta. Esse nmero usado em acessos subsequentes quela porta e atribudo ao processo (pelo kernel) e no thread. Portas podem ser agrupadas em conjuntos de portas (at mesmo a mais de um). Isso facilita o trabalho de enviar uma mensagem a vrias portas ou para ler das mesmas.

Enviando e Recebendo Mensagens

As mensagens no Mach possuem uma estrutura bem definida (cabealho e corpo) e existe uma nica chamada de sistema para enviar e receber mensagens. Essa chamada de sistema mascarada pela funo mach_msg. Essa funo recebe sete parmetros e usada tanto para o recebimento quanto para o envio de mensagens. Se for realizada uma leitura em uma porta que no possui mensagens, a thread bloqueada at que alguma outra mande uma mensagem para aquela porta. Basicamente, o que o cabealho da mensagem contm a porta de destino e resposta, o tipo da mensagem, tamanho e indicaes de permisses (de resposta e do destinatrio). No corpo da mensagem, pode-se especificar uma estrutura de dados bastante simples, onde um campo (especificando tipo de dado) seguido pelo seu valor. Da mesma forma, pode-se enviar uma grande quantidade de memria sem que seja feita uma cpia de uma thread para outra; existe uma estrutura especial que permite mapear uma regio do espao de endereamento no espao de outra thread (somente em threads que habitam a mesma mquina). Essa regio fica marcada para ser copiada somente se houver uma escrita. Para fazer esse tipo de comunicao atravs da rede, existe um processo chamado "network message server". Esse processo roda em cada nodo da rede e faz o mapeamento das portas locais de um nodo nas de outro. Alm disso, o NMS realiza tambm as seguintes tarefas: transformar tipos de dados de uma representao para outra, gerenciar portas de uma maneira segura, fazer notificaes remotas, prover um servio de procura remota e gerenciar autenticao de outras mquinas.

Depois
O projeto Mach 3 foi encerrado, mas a OSF continuou seu trabalho em cima de duas verses do mesmo: Mach 3 e MK++. Por volta de 1995, a universidade de Utah comeou um projeto chamado Mach 4 que tinha como objetivo investigar algumas idias novas em cima do sistema, consertar alguns problemas e prover a base necessria para um projeto maior chamado Flux. Entretanto,

pretendia-se no fazer tantas modificaes a ponto de torn-lo incompatvel com as verses anteriores. Isso no foi possvel, pois muitas modificaes foram realizadas a fim de atender os objetivos do projeto Flux. Algumas verses do Mach 4 foram lanadas e distribudas na rede. O processo de modificao do kernel subdividiu-se em duas frentes chamadas de "head

branch" e "UK02 branch". A primeira era responsvel pela pesquisa em si e a maior parte do desenvolvimento do Mach 4 aconteceu ali. Algumas modificaes importantes foram realizadas por esse grupo:
o o

Migrating threads: um modelo para execuo de RPC mais rapidamente. Kernel activations: algumas funes do kernel foram movidas para a rea de usurios.

O caminho chamado de "UK02 branch" era responsvel pelas modificaes relativas a consertos de problemas existentes na verso anterior ou aumento de suas capacidades, como por exemplo suporte a novos sistemas de arquivos (MINIX e ext2), criao de um novo ambiente de desenvolvimento, novo sistema de boot, criao de arquivos "include" e modificao no estilo de codificao utilizada. Por um tempo, o esforo de modificao do kernel do Mach foi a principal atividade dentro do projeto Flux, gerando uma grande quantidade de artigos que podem ser encontrados na rede (http://www.cs.utah.edu/projects/flexmach/papers.html#MACH). Outros projetos estavam bastante relacionados com o Mach 4, como por exemplo o Lites, que objetivava criar uma verso pblica do servidor BSD4.4Lite, mas ainda assim utilizvel. Muitas importaes foram realizadas com esse cdigo que rodava em i386, PA-RISC, pc532, R3000 e Alpha. Na sua verso i386, o Lites suportava compatibilidade binria com o Linux, NetBSD e FreeBSD. Esse projeto tambm foi encerrado.

Com o fim do projeto Mach 4, gerando a base de conhecimento para o projeto Flux, foi criado em 1996 um sistema operacional chamado Fluke [2], que mantm algumas caractersticas importantes do Mach, como o microkernel e o sistema de IPC, mas no aproveita grande parte de seu cdigo, devido a grande complexidade do mesmo. O sistema Fluke prope um novo paradigma de sistema operacional onde os processos so criados a partir de outros processos, mas esses filhos no executam seu cdigo independentemente do seu pai. Na verdade, o processo pai cria um ambiente virtual onde o filho executar e, dessa forma, algumas funes que deveriam ser atendidas pelo sistema operacional agora podem ser realizadas pelo processo pai. Esse modelo melhor compreendido num esquema de camadas onde os processos filhos ficam no topo e o sistema operacional embaixo da pilha. Esse esquema apresentado na figura 2. Outro projeto importante resultante do fim do Mach 4 o Flux OSKit [3], um kit de desenvolvimento e prototipao rpida de sistemas operacionais onde j esto implementadas vrias funes bsicas de um sistema e que possuem pouco interesse em termos de pesquisa. Mdulos bsicos como o carregador do sistema, o escalonador, o gerenciador de memria e uma infinidade de drivers para os mais diversos perifricos j esto disponveis ao projetista do sistema operacional. Com esse kit, possvel desenvolver um novo sistema operacional em poucas horas, segundo o artigo que apresenta o projeto. O sistema operacional Fluke utiliza toda a capacidade do OSKit, mas alm do Fluke, muitas outras aplicaes foram desenvolvidas utilizando esse pacote e muitas at mesmo na indstria. Isso possibilitou que o Kit no ficasse restrito apenas ao projeto do Fluke, mas atendesse a outras implementaes com objetivos diferentes como um sistema baseado na linguagem ML chamado de ML/OS, outro baseado na linguagem SR chamado de SR/OS e um projeto que cria uma mquina virtual Java e um network computer baseado nesse sistema. A linguagem Java despertou muito interesse no grupo de pesquisa Flux, provavelmente devido s suas similaridades com o trabalho desenvolvido l (mquina virtual, linguagem no convencional e sistemas operacionais). Com isso, muitos trabalhos interessantes foram gerados com essa linguagem, onde destacam-se um sistema operacional Java (similar ao JavaOS, mas utilizando resultados e idias das pesquisas realizadas pelo grupo) e um sistema de rede ativa, onde os pacotes de rede carregam cdigo Java que executado pelo roteador.

O Grupo de Pesquisa FLUX

O grupo de pesquisa Flux (http://www.cs.utah.edu/projects/flexmach/) trabalha com sistemas de software e seus interesses (e trabalhos) incluem muitas reas como sistemas operacionais locais e distribudos, segurana de informaes e recursos, programao, linguagens no tradicionais, compiladores, redes, sistemas baseados em componentes, engenharia de software e mtodos formais. Atualmente, os principais projetos desenvolvidos pelo grupo so:
o

Sistema operacional de alta segurana Fluke/Flask

o o o

Linguagem de definio de interface Flick (e compilador) OSKit Sistemas baseados em Java: sistemas operacionais, gerenciamento de recursos, redes ativas. Esse tpico inclui um projeto para prover noo de processo dentro da mquina virtual Java

Existe muito software produzido por esse grupo e disponvel em sua pgina. Entre eles, destacam-se o sistema de redes ativas (ANTS), o compilador IDL Flick e o Quarks, que um sistema portvel e eficiente de memria compartilhada distribuda. Alm disso, encontram-se disponveis nessa pgina o OSKit e o kernel do Fluke. Como mencionado anteriormente, alguns projetos que foram encerrados pelo grupo tambm disponibilizam seus resultados, que so o Mach 4 e o Lites. As pesquisas realizadas por esse grupo na rea de sistemas operacionais e segurana no existem por acaso. Entre os rgo financiadores dos projetos encontram-se DARPA, NSF, Hewlett-Packard, Novell e IBM. A maioria das publicaes do grupo encontram-se na rede no formato PostScript.

O Sistema Operacional Fluke

O Fluke [2] um sistema de arquitetura virtualizvel baseado em software que permite a criao de mquinas virtuais recursivas, ou seja, mquinas virtuais rodando sobre mquinas virtuais, implementado eficientemente sobre um sistema microkernel e rodando sobre hardware genrico. Sistemas do tipo microkernel tentam distribuir as diversas funes do sistema operacional horizontalmente, colocando-as no espao do usurio na forma de servidores (como o Lites, por exemplo). J sistemas baseados em mquians virtuais recursivas tradicionais agem de outra forma, decompondo o sistema operacional de forma vertical, j que implementam as funes do sistema operacional na forma de pilha de "virtual machine monitors", cada qual exporta uma interface de mquina virtual compatvel com a interface sobre a qual est executando. Assim, o sistema operacional Fluke combina os dois paradigmas, o microkernel e o de mquinas virtuais, implementando uma arquitetura virtualizvel que no pretende emular um hardware perfeitamente, mas sim desenvolvido em software e sobre um sistema operacional microkernel. O microkernel executa diretamente sobre a mquina e a arquitetura virtualizvel implementada em software na forma de "nested process". Os monitores de mquinas virtuais, chamados de nesters, podem eficientemente criar mquinas virtuais adicionais (outros nesters), sobre as quais outros nesters ou aplicaes podem ser executadas. Essa arquitetura forma um espcie de pilha de nesters, onde no topo executada a aplicao. Em mquinas virtuais tradicionais (baseadas em hardware), cada mquina virtual exporta uma interface idntica mquina sobre a qual est rodando, provendo assim proteo e independncia entre as vrias mquinas virtuais. J em uma arquitetura como a do

sistema Fluke (que implementada sobre um microkernel), a interface exportada pelas mquinas virtuais (ou nesters) pode ser completamente diferente uma da outra. Dessa forma, pode-se usar recursos tradicionais do sistema operacional, como o gerenciador de pginas, apenas quando necessrio. Ao contrrio de um sistema normal, onde, mesmo desabilitando seu uso, o recurso continua na memria, consumindo recursos sem ser utilizado. Essa independncia alcanada com a implementao de um nester responsvel pelo gerenciamento de pgina. Assim, ele somente usado quando necessrio, ou seja, somente ser colocado na pilha se for necessrio. Dessa forma, o sistema pode ser composto de acordo com a necessidade da aplicao que executar no topo. Isso garante uma grande flexibilidade sem que haja perda considervel de desempenho. Arquiteturas tradicionais de mquinas virtuais adicionam um overhead de 20% a 100% por camada acrescentada, enquanto a arquitetura implementada no Fluke apresentou ndices de 0% a 35% por camada.

Concluses
O sistema operacional Mach, apesar de ainda despertar bastante interesse, foi encerrado na verso 4. Entretanto, seus conceitos e idias inovadoras deram origem a novos projetos e possibilitaram a criao de outros sistemas. A combinao das idias do Mach com outros trabalhos na rea de sistemas operacionais impulsiona a pesquisa no sentido de encontrar formas alternativas de implementao de sistemas, visando flexibilidade sem perda de performance. Ainda assim mantendo a transparncia dessas mudanas ao usurio. O grupo de pesquisa Flux, de Utah, conta com apoio de importante rgo do governo americano e de empresas, o que garante a continuidade dos projetos por eles desenvolvidos.

Mais sobre o Sistema

[1] Tanembaum; Distributed Operating Systems, ... [2] Bryan Ford, Mike Hibler, Jay Lepreau, Patrick Tullmann, Godmar Back, Stephen; Clawson Microkernels Meet Recursive Virtual Machines. Appears in Proc. OSDI'96, October,1996. [3] Bryan Ford, Godmar Back, Greg Benson (U.C. Davis), Jay Lepreau, Albert Lin (MIT), Olin Shivers (MIT). The Flux OSKit: A Substrate for OS and Language Research. Appears in Proceedings of the 16th ACM Symposium on Operating Systems principles, Saint-Malo, France, October 1997