* Diego A. Dompe Gamboa ([EMAIL PROTECTED]) said: > Aun asi, personalmente estoy del lado de los microkernels, dado que siempre > he sido partidario de "divide y venceras", aunque debo reconocer que > particularmente el kernel Linux ha implementado esta filosofia muy bien a su > manera.
No me malinterpreten, no es que est� necesariamente en contra de los microkernels, pero la verdad, no le veo las grand�simas ventajas. - portabilidad: cierto, la parte central ser� m�s peque�a/simple y se podr� portar m�s facilmente, pero las partes externas igual hay que portarlas. El argumento de que la interna es m�s dif�cil de portar no es tan valido. Los kernels no se programan en ensamblador, solo la inicializaci�n, por lo que siempre va a ser cuesti�n de tener un compilador que sirva y vamonos. - extensibilidad: eso se llaman m�dulos, el hecho de si la llamada es a un area del kernel o externa no afecta en funcionalidad. - interfaces estandar: pues la verdad no veo por que servicios del kernel tienen por que seguir las interfaces de los procesos de usuario. No sermoneo a favor del desorden, pero creo que se puede optimizar las cosas mejor dandole a los servicios del kernel llamadas/interfaces que los usuarios no necesitan. - estabilidad: punto a favor, pero gran valor. Puede ser que un microkernel sea m�s estable en ciertas cosas, es peque�o y simple. Sin embargo, el resto de los servicios igual pueden fallar. De que me sirve que el scheduler siga funcionando si mam� el filesystem o el driver de red? El monolithic kernel, mientras sea programado ordenadamente tiene las mismas ventajas. La �nica ventaja en esta area es que si el que mama es el driver de red, no es posible que mame el file-system, pero ese tipo de chequeos tambi�n se podr�an hacer en un monolithic kernel si fuera el caso. - OO: la verdad, no me parece que se fuerce al kernel a ser orientado a objetos. Si se quiere obligar a la interfaz de usuario a serlo, pues me da igual, pero el kernel en si deber�a poder organizarse como mejor se pueda. - Desempe�o: ... uups, aqu� se cayo el microkernel. Todas esas llamadas de adentro para afuera del kernel que son necesarias ahora si que molestan. bien es cierto que hay muchas optimizaciones, y que pasar p�ginas de memoria de un proceso a otro no derberia ser tan caro, pero siempre es un gasto que no deber�amos tener. > > Como va a ser tan todopoderoso como gcc? Lo importante de Mach es la > > simpleza, la separaci�n de funciones. > exactamente!, en eso es tan poderoso como gcc: en la simpleza y la separaci�n > de funciones. Esa modularidad y flexibilidad de dise�o es lo que permite que > un software sea "poderoso" (perdon por usar una palabra no cuantitativa :S). > GCC es altamente versatil por haber tenido un excelente esquema de dise�o. Siempre pens� que gcc era bastante complejo. Yo la escala la veo as�: Orden y proteccion forzada <========================> Desempe�o Microkernel Monolithic kernel Y la verdad, eso de tener forzado cierto orden y protecci�n no siempre me gusta. Me parece un poco como excusa para no hacer las cosas bien por dise�o. Una cosa es prohibir que se haga llamado a una funci�n, otra es asegurarse que no se haga. La primera sirve si estamos trabajando con c�digo ageno a nosotros, que no sabemos como funciona pero se vuelve una carga si sabemos lo que estamos haciendo y controlamos el c�digo. Despu�s de todo, tiene que haber alguna raz�n que no sea filos�fica por la cual no nos gustan los m�dulos de Linux que son cerrados no? Con el microkernel puedo cargar el filesystem de compa�ia X sabiendo que mi microkernel va a proteger el resto de los servicios. En Linux si cargo el m�dulo binario de NVidia es problema mio si las varas empiezan a fallar. Que curioso como las pol�ticas y modos de pensar se meten hasta en los rincones m�s t�cnicos. Nacho -- "In Googlis non est, ergo non est." - Anonymous Coward Homepage: http://www.cse.ucsc.edu/~isolis/ | EEE8 08C9 FBAE B471 9691 GPG Public Key: http://www.igso.net/isolis.gpg | CE7A 1CC8 D3DE B31E 10AB
pgp00000.pgp
Description: PGP signature
