Como funciona:
O UZIX usa a memória mapeada do MSX2 para obter multiprocessamento. No PC,
o UZIX usa a memória adicional do computador para troca de contexto. Em
ambos os casos, o UZIX usa 64kB de espaço de endereçamento virtual (o
espaço completo do Z80 ou um segmento cheio no PC).
O UZIX propriamente dito ocupa os 32kB superiores do espaço de
endereçamento, e o processo em execução corrente os 32kB inferiores.
Ele necessita de algum suporte adicional de hardware. Primeiro, o UZIX
usa o temporizador do sistema para prover uma interrupção periódica.
Também, a implementação corrente usa um relógio de tempo real adicional
para obter a data e hora para arquivos, etc. O driver de TTY corrente
assume um teclado com buffer por polling, o qual existe na maioria dos
sistemas.
Como o UZIX é diferente do UNIX real:
Implementa quase todas as funcionalidades da 7ª Edição. Todas as operações
de E/S de arquivos, diretórios, sistema de arquivos montável, usuários e
grupos, pipes e dispositivos de E/S aplicáveis são suportados. O controle
de processos (fork(), execve(), signal(), kill(), pause(), alarm() e
wait()) é totalmente suportado. O número de processos é limitado apenas
pelo espaço de troca disponível, num máximo de 31 processos (num total de
1024kB de memória). Como mencionado, o UZIX implementa o UNIX bem o
suficiente para executar a Bourne Shell em toda a sua funcionalidade. As
únicas modificações feitas no código-fonte da shell foram para satisfazer
as limitações do compilador C.
Aqui está uma (possivelmente incompleta) lista de funcionalidades
faltantes e limitações:
- As chamadas de sistema relacionadas a debug e profile não existem.
- O driver TTY é dependente do terminal padrão do computador. Ele suporta apenas uma porta.
- Os números dos inodes são 16 bits. Logo, os sistemas de arquivos têm 32Mb ou menos.
- A hora e data dos arquivos não está no formato padrão. Ao invés disso, elas se parecem com aquelas usadas pelo MS-DOS.
- A chamada execve() do BSD 4.2 foi implementada. Outra variantes do exec() são suportadas pela biblioteca.
- Os semáforos e mecanismos de trancamento necessários para implementar E/S de disco reentrante não estão aqui. Isso tornaria difícil implementar E/S de disco controlada por interrupção sem espera.
Notas para desenvolvedores:
O UZIX para MSX pode ser compilado com qualquer compilador C
ANSI-compatível. O único verdadeiro para MSX é o Hitech-C (versão para CP/M)
e o Hitech-C MS-DOS (cross-compiler). O UZIX para MSX foi escrito usando o
Hitech-C. Você encontrará muitas construções e funções não suportadas (e
também limitações) por outros compiladores C para MSX se você tentar
compilar o UZIX com eles. É claro que o UZIX pode ser compilado usando
outro compilador, mas isto requereria muitas mudanças no código-fonte.
Inicialmente o UZIX para MSX não podia ser compilado para ser executado em
um MSX1, já que ele usa memória mapeada para multitarefa, relógio de tempo
real para data e hora e tela em modo de 80 colunas. É claro, é possível
fazer uma versão "leve" do UZIX para MSX1, com um relógio de tempo real
falso (emulado por software pelo kernel), usando a tela em 40 colunas e
outro dispositivo de memória (como a MegaRAM) para multitarefa, mas este
não é o objetivo do projeto.
Mas, apenas por diversão (e como curiosidade), existe uma versão do UZIX
para MSX1. Ele emula o relógio de tempo real e usa a MegaRAM brasileira
para obter multitarefa. A performance geral do sistema é mais baixa que
usando a memória mapeada, já que devido às restrições de chaveamento da
MegaRAM (devido ao design do UZIX, as páginas da MegaRAM só podem ser
chaveadas na página 1 da memória) algumas cópias de blocos de memória se
fazem necessárias para a troca de contexto. Além disso, o usuário deve
fornecer a data e hora atual quando o sistema é carregado. A tela em 40
colunas não representa uma restrição séria, mas algumas aplicações (como
top, ps ou banner) exibirão textos mal formatados na tela.
Esta versão do UZIX para MSX pode lidar com um máximo de 31 processos
(limitado pelo tamanho da RAM disponível). Ele poderia manipular até 127
processos (4Mb de RAM), mas não faz sentido apenas um usuário executar
tantos processos ao mesmo tempo. Este é o motivo do limite de 31 processos
concorrentes.
Mais informações em:
http://uzix.sourceforge.net