[Liquidfire-devel]Re: GNU/Liquid

[Lucas M. <lu...@mi...>]

eu preciso rever os pinos das memorias SIMM de 72". pro lance do boot, seria
mesmo interessante nao limitar as coisas em um setor, com o Intel. podemos
puxar 2 paginas (8KB) de uma vez, que jah teria o codigo do trap #0 para acesso
ao HD (KERNEL VFS basico - flexibilizando a opcao do sistema de arquivos do
microkernel.. o FS nao estaria no KERNEL, mas num modulo separado e o KERNEL
usaria o trap #0) e carregando o KERNEL para o topo do core. outro lance
bastante interessante seriam os daemons multiplos, para hardware carente de IRQ;
basicamente aquela nossa velha ideia de polling no IO, tipo um select. :)
contei a Lorrene sobre a possibilidade de uma multitarefa cooperativa por meio
das funcoes write/read e descrevi a comunicacao interprocesso, as ideias sobre
queueing e MM, se nao me engano. (nao me lembro se contei do MM para ela ou outra
pessoa - Lorrene, se nao te descrevi, manda um mail que descrevo. eh bem
interessante).
a pilha de rede, como realmente te falei, tambem estara em um daemon 'NET', que
tera acesso aos teletipos (a ethernet vai ser uma especie de TTY tambem) por
meio de uma funcao FILE *fdevopen(char *device,char *mode) da libc, que usara
uma system call DEVOPEN do KERNEL. como abaixo:

	FILE *eth=fdevopen("eth0","r+");
	if(!eth) {
		fprintf("Could NOT open the ethernet. Networkg disabled\n");
		return -1;
	}
	for(;;) {
		/* trata a rede como RAW SOCKET, acrescido das
		 * facilidades das funcoes para tratamento de
		 * arquivos.
		 */
	}

deu pra perceber que o ha um modulo no KERNEL que precisa registrar o dispositivo
"eth0" e disponibilizar funcoes de write, read, lseek e close. ha 2
possibildiades para a ethernet: uma eh fazer 'NET' escrever direto no dispositivo
a outra eh que teriamos um outro daemon para gerenciar o fluxo de todas as
ethernets disponiveis. pode ser uma boa ideia, jah que os discos ATA IDE tambem
possuem um daemon 'IDE' alem do 'FS'. de qualquer maneira, mesmo tendo 20
daemons para os drivers, somente 2 ou 3 estarao concorrendo pela CPU;
os demais dormirao aguardando evento nos descritores.
tambem te contei isso. soh repassando. :)
o Stallman perguntou se da pra correr o HURD em cima do Liquid hehehe. mais tarde
mando mail pra ele explicando que o Liquid nao eh um Mach e que teremos todos
os daemons necessarios, fucionando de maneira proprietaria.
a proposito, a lista 'Liquidfire-devel' esta fucionando novamente na
sourceforge; vamos utiliza-la! melhor que ter que ficar adicionando endereco
por endereco das pessoas aqui nos mails.
eu tomei a liberdade de inscrever o ma...@mi... lah. :)

# 
# o lance do 68306 seria algo bem simples, uma PCB bem basica, com
# a eprom de inicializacao e  uma porrada de conectores. para as duas
# seriais, precisa de circuitos de conversao de tensao, mas q sao bem
# basicos, bem pq em eh serial hi-speed. os sinais roteiam direto no
# conector  da  dram de 72 vias e nem tem muito segredo,  exceto por
# algumas  questoes relacionadas a auto-config da dram, q podemos usar
# alguns bits das portas paralelas q  o 68306 tem onchip para fazer
# isso e selecionar automaticamente o size do pente de memoria.
# 
# ateh aih eu garanto q funciona legal, mas soh temos um 68306 com duas
# seriais, eprom de boot e dram. precisariamos de uns latches e algum
# suporte de software para tentar uma IDE, q eu acho q nao h tao
# problematica. por fim, eu acho q poderiamos colocar um conector de
# expansao proprietario, talvez um VME16, q reflete os sinais de um 68k
# padrao. pq isso ? simplesmente permite plugar outra placa, essa eh
# a q eu acho q pode dar pepinos de timming e precisaria de mais debug,
# nessa placa colocariamos ou IO 68k nativo ou um par de conectores ISA,
# os quais tem q  ser bufferizados com bastante latches e tb precisam de
# logica extra para gerar sinais especiais ridiculos, por exemplo,
# decodificar mapas de memoria, io,  etc referentes ao bus ISA do PC, q
# ainda de quebra requer uns waitstates para sincronizar seus 8MHz
# padrao com os 16MHz do 68306.
# 
# na pratica, uma placa flexivel e sem muito o q dar problema: tentamos
# mover o problema para um  conector de expansao q realmente vai dar
# problema ateh o hardware realmente se sincronizar hehehe
# 
# mas acho q o 68306 com eprom, seriais e IDE jah permite desenvolver
# integralmente o sistema operacional! soh temos q achar uma forma de
# contrabandear uns 68306 para o brasil hehehe