[uylug-varios] Kernel: Monolítico vs. Híbrido (era Re: linus torvalds finalista del premio mellennium de tecnología 2012 !!!)

[Eduardo Trápani]

> El ejemplo lo entendí, y mi reticencia a considerarlo como
> determinante es justamente que es una parte de una parte. Ext3, Ext4,
> xfs, jfs, todavía están dentro del kernel. Y según tengo entendido,
> por ejemplo, no formateas una partición con ssshfs, es una capa de
> abstracción más. No digo que no esté bueno ni sea superpoderoso.

Pero si usás zfs sí.  Va más allá de una mera abstracción.  Pero estamos
de acuerdo en que el peso relativo de "una parte de una parte" puede no
ser suficiente para cambiar de categoría.

¿Sabés a qué me hace acordar esto?  A la discusión de si Java era un
lenguaje orientado a objetos *puro*.  Para los que manejan Smalltalk o
Ruby puede existir la necesidad de poner una línea que los separe de Java.

Claro, si me preguntás, el que Java tenga un tipo entero o byte que no
sea un objeto (una de las "impurezas") no es para mí algo tan horrible
como para alejarlo mucho de los otros.  Y lo mismo puede valer para un
kernel monolítico, considerando fuse, dri/drm o pty.  Son impurezas, y
altamente prácticas.

En un mundo de unos y ceros yo te diría que cualquier desviación te saca
el sello de pureza y pide un nuevo nombre (por ejemplo "kernel
híbrido").  Pero eso es académico.  Después viene la vida real,
práctica, que por suerte no es uno o cero y ahí es tolerable mantener el
nombre viejo aunque no se ajuste totalmente.

Lo interesante, para mí, es saber que no se ajusta y por qué.  Aunque el
desajuste pueda ser catalogado de mínimo.  Y reconozco que esa inquietud
va más por el lado académico que por el práctico.

> Me tuviste pensando en esto todo el camino desde la facultad a casa ;-)

:)

> Te pregunto lo siguiente, ¿puedo compilar el kernel sin FUSE, soporte
> a tun/tap y todo lo demás que mencionás? Y no quiero entrar en si es
> mejor o peor. Simplemente entender si un kernel sin todas esas cosas
> que lo harían híbrido sigue funcionando igual.

Una de las cosas que mencionaba era PTY.  Bueno, en el kernel que tengo
a mano (un 2.6.32) *no* puedo deshabilitar "Unix98 PTY support" en 'make
menuconfig'.  O sea que esa parte de la hibridez no la puedo sacar del
kernel.  Y por ahí, por pty, es que pasa toda nuestra interacción de
línea de comando desde terminales en modo gráfico y desde ssh por lo menos.

Igual entiendo tu punto de vista: buena parte de esas cosas podrían ser
en cierta manera "decorativas".  Pero la imposibilidad de matar PTY no
ayuda a esa visión.  Y con su lado esclavo (kernelspace) y su lado
maestro (alimentado desde userspace), con la identidad en el kernel de
un único dispositivo de e/s, es difícil pensarlo como algo que no tiene
una pata de cada lado y que fue diseñado para tenerla.

> Ahí me parece que está el "nucleo" del asunto. A esa frontera entre el
> kernel, y lo que usas para interactuar directamente con el. Yo me
> pongo arriba de la interfaz con userspace, y digo "lo que está abajo
> es el sistema operativo y lo de arriba son las aplicaciones".

Bien.  Se entiende clarito.  En ese caso ifconfig es una aplicación y
punto, igual que shutdown o init o udev.  Igual que 'cat' o 'grep'.
¿Raro, no?  Tener a 'init' y 'cat' igualmente lejos del kernel.  Pero si
esa es la frontera, está bien, es una definición.

> parás un poco más arriba y decís, "sin estas aplicaciones el sistema
> operativo me sirve para muy poco, entonces para mi lo que está más
> abajo es kernel, y con estas aplicaciones es el sistema operativo"

Sí, casi.  No va tanto en la utilidad de la aplicación, como en su
comportamiento.  Una aplicación cuya única/principal función es
parametrizar directamente el kernel, esa aplicación es parte del sistema
operativo, pero no del kernel.  Tengo que ponerle un nombre a:
kernel+init+shutdown+ifconfig y para mí ese nombre es sistema operativo.

> Como vos decís, es la frontera borrosa que vos mencionás.
> ¿Entiendo bien o estoy muy errado?

Si, me parece que me entendiste bárbaro.  Y creo que yo a vos también.
Y es lógico lo que pasa, como ponemos la línea en diferentes lugares
tenemos resultados diferentes, y me parece que son válidos los dos
teniendo en cuenta esas fronteras.

Eduardo.