Infelizmente estou absolutamente sem tempo, mas na medida
do poss�vel gostaria de comentar alguns trechos de algumas mensagens:
Em Sat, Jul 07, 2001 at 02:08:51PM -0300, Edgard Lemos escreveu:
> > Quando o Thiago diz ser imposs�vel "micro-kernar" o Linux, � nisto que ele se
> > baseia. E eu quase concordo com ele (apenas prefiro o termo "improv�vel").
>
> Nada � imposs�vel. Quanto tempo passamos pensando e discutindo sobre esta
> thread?
Eu acho que esse pensamento depende muito do "n�vel" em que se
possa "microkernar". Bem, os drivers do Linux, s� pra citar um exemplo,
s�o criados com certa interface com outras partes do kernel em mente.
Estas interfaces s�o diferentes em um microkernel. Qu�o diferentes?
Isso depende do microkernel... Chorus, Amoeba, Mach, cada um tem a sua.
Por exemplo, sei que um desses (n�o lembro qual) tem o microkernel t�o
simples e minimalista que at� o agendador (scheduler para os angl�filos)
roda como um servi�o do microkernel. Deve ser dif�cil fazer isto! :P
Dependendo do microkernel, e com menos peso at� de caracter�sticas
particulares do driver em vers�o, pode ser mais ou menos f�cil de faz�-lo
(seria de acordo com a semelhan�a destas interfaces. Por exemplo, a interface
de um dispositivo de bloco: o que o driver teria que disponibilizar, um
jeito de fazer acesso aleat�rio dados par�metros/objetos/componentes que
digam como faz�-lo?).
No pior caso, que � ele ser brutalmente diferente do Linux de modo
que nenhuma interface seja aproveitada, a leitura do driver do kernel pelo
menos possibilita o entendimento de como o dispositivo funciona. Para
muitos casos, este c�digo, mesmo sob uma interface diferente, � at� mais
�til do que uma especifica��o bem detalhada. E s� a� j� temos uma imensa
diferen�a: aquele c�digo foi testado, usado, e muito provavelmente
oferece com acuidade a descri��o do comportamento do dispositivo. E voc�
evita testes, tentativa e erro, e entendimento do funcionamento, passos
que j� foram feitos para escrever aquele driver espec�fico.
S� isso j� d� uma consider�vel economia de tempo. A interface de
kernel do Unix/Linux � simplificada, e os blocos de constru��es dos drivers
s�o organizados de tal modo que eles s�o simples de serem compreendidos
(geralmente - "simples" � uma defini��o vaga, se algu�m quiser discordar
sinta-se � vontade).
Assim, acredito eu, usar o Linux como meio para construir os
drivers do Hurd, por exemplo, para mim � uma alternativa muito prov�vel.
Embora eu n�o tenha a m�nima id�ia de por qu� ningu�m fala muito sobre
Hurd hoje em dia.
OBS.: Eu disse "drivers" para entendimento geral. Flames para
/dev/kmem, por favor. N�o me culpe se travar... A prop�sito, acho que
esse pensamento pode ser estendido a outras partes do kernel.
Coment�rios?
[]s,
--
Patola (Cl�udio Sampaio) - Solvo IT
IBM Certified Advanced Technical Expert
SAIR GNU/Linux Certified Systems Administrator
PGP/GPG Public Key Available Upon Request
Anti-Microsoft activist for mainly moral but also technical reasons
Try http://www.automatos.com - The Automatic MSP
Unix sex: unzip; strip; touch; finger; mount; fsck; more; yes; umount; sleep
--
/"\
\ / ASCII RIBBON CAMPAIGN - NO HTML EMAIL!
X PLEASE QUOTE ONLY RELEVANT PARTS OF THIS MESSAGE.
/ \ DON'T QUOTE THIS SIGNATURE! / N�O CITE ESTA ASSINATURA!
Assinantes em 08/07/2001: 2262
Mensagens recebidas desde 07/01/1999: 122007
Historico e [des]cadastramento: http://linux-br.conectiva.com.br
Assuntos administrativos e problemas com a lista:
mailto:[EMAIL PROTECTED]
