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

[Eduardo Trápani]

> ¿Y eso no pasa en Linux? ¿En que parte las funciones del kernel no se
> brindan dentro del kernel en espacio privilegiado?

Por ejemplo en cualquier sistema de archivos que corra sobre fuse, como
fuse-zfs.  Si estamos de acuerdo en que el acceso al sistema de archivos
es una función del kernel monolítico.  fuse-zfs es un programa, corre
afuera del kernel en espacio de usuario.

>> Lo de los módulos es en este sentido "anecdótico", es la manera de cargar.
>>  Es como en programas normales, no hay mucha diferencia entre carga dinámica
>> y carga estática, en lo que hace a la arquitectura del programa.  La
>> modularidad del kernel no lo hace más o menos monolítico.
>>
> 
> Perdón, pero no es nada anecdótico. Una vez que un módulo está cargado
> (técnicamente enlazado) está dentro del kernel en espacio
> privilegiado.

Viste que puse "en ese sentido", el de la arquitectura.  Pensalo así.
Cuando no había módulos, como no había al principio, el kernel como tal,
¿tenía una arquitectura diferente?  ¿Cambió la arquitectura global del
kernel cuando aparecieron los módulos?  (en el sentido:
micro/monolítico/híbrido)  No, no cambió.  Se hizo más fácil y
mantenible y se acortaron varios procesos de desarrollo.  Nos cambió la
vida a los desarrolladores.  Pero no se movió de donde estaba: monolítico.

La carga de módulos no es relevante en esa definición.  Y el ejemplo
para mí es el siguiente.  Podés compilar cualquier programa estática o
dinámicamente.  Eso no la arquitectura del programa en cuestión, que ni
se entera.  Y sí, cuando cargás una biblioteca dinámica pasa a formar
parte del programa y maneja el mismo espacio de direcciones, etc.  Como
si hubiera estado ahí siempre (estáticamente).  Para mí es irrelevante
la existencia de carga de módulos de Linux en la discusión sobre la
arquitectura.

>> Mencioné fuse en el entorno de esta conversación, por dos cosas: una porque
>> claramente está desarrollado fuera del kernel.  Es un ejemplo de lo que está
>> en el kernel pero se desarrolla afuera (eso impacta en la autoría actual del
>> kernel).
>>
> Parte de fuse está afuera,  pero otra parte está adentro. Hay un
> módulo del kernel que interviene. Y si bien el acceso a filesystem es
> una de las funciones principales, no es la única ni mucho menos. Tenés
> el manejo de procesos, el manejo de memoria. En su momento, Linus no
> estuvo de acuerdo con FUSE, y acá hay una discusión sobre las cosas
> que no le gustan respecto al tema.

Bárbaro, pero ¡ahí tenés el ejemplo que buscabas!  El hecho es que está,
es que hay *una* (por lo menos) función del kernel, que tampoco es una
función menor, que está afuera del kernel y para el propio Linus no
debería estar ahí.  Eso para mí te saca de lo monolítico puro y duro.
Si querés lo dejamos en "mayormente monolítico", no es grave para mí el
nombre (Linus también dijo que los híbridos no existen y es una cosa de
marketing), pero eso que traés justamente apoya mi reticencia a
considerarlo totalmente monolítico.

Dicho sea de paso, que Linus piense lo que quiere, pero manejar discos
en varias máquinas a la vez con sshfs, ftp y smbfs desde el gfvs de
Gnome ... me hace pensar que las ventajas de fuse sobrepasan largamente
a los problemas posibles.  Porque además mientras tanto hacen el lessfs,
por ejemplo, o sea, no está agotado en lo más mínimo.

Los filesystems son tan importantes, que hasta el manejo de memoria que
ponías se puede ver afectado, como ya discutimos en otro hilo,
simplemente poniendo un swapfile en un filesystem que no esté
enteramente controlado por el kernel.

Pero de tu lista, ¡ni siquiera el manejo de procesos se salva seguro!
OOM (el sacrificio de un programa para liberar memoria cuando ya no
queda y se usó más de la disponible) es una función de manejo de
procesos, la hace el kernel.  Peeeero, la solución pasaría por llevarla
a espacio de usuario[1][2].  Y tiene su lógica sacar eso del kernel.

> En lo que a mi respecta, Linux es monolítico. La única función
> relevante del kernel que se puede hacer en userspace es el acceso a
> filesystems.

Bien.  Puntos de vista.  Yo no puedo ignorar DRI/DRM.  ¿No es el acceso
directo a los dispositivos una función exclusiva del kernel?  DRM te da
acceso desde espacio de usuario.  Eso ya serían dos funciones.  O
esperar al OOM en userspace.

Por otro lado, el manejo del networking, ¿es del kernel o no?  Porque si
lo es, entonces algo en tun/tap huele raro también.  No digo que sea una
tercera función compartida con userspace, pero ... da para pensar.

No tengo problema en que le digan monolítico, si se sabe que en realidad
lo es "mayormente" y no completamente.  Y opino que es mejor así, que
las puertas o agujero que se han abierto en lo monolítico lo han hecho
mejor de lo que hubiera sido si, por ejemplo, las opiniones de Linus
hubieran hecho que fuse no entrara al kernel.

> Todas las demás se hacen en espacio privilegiado. Si una
> parte de uno de los 5 subsistemas del kernel que corre en userspace lo
> hace "híbrido" y no monolítico, me parece que estamos estirando mucho
> el concepto de híbrido. Hasta ahora los ejemplos que me has dado han
> sido a nivel de filesystem.

Ahí fueron un par más.  Pero no estoy en condiciones técnicas de saber
cuánto habría que "estirar" la definición.  De repente tenés razón.  En
cualquier caseo me alegro montones de haber leído lo de Linus.  Siento
que no estaba tan errado en mis apreciaciones.

> Me gustaría que me dieras tu definición concreta de lo que es un
> sistema operativo, y en que es diferente del kernel. Porque para no

¡Me estás matando!  Te podría pedir lo mismo, ¿no?  :)  Como puse al
principio, intuitivamente entiendo que no es lo mismo kernel y sistema
operativo, de ahí veníamos.  No puedo argumentar mucho más que lo que ya
hice.  Si me apretás contra la pared y no puedo salir ;) te diría que se
trata de espacios de memoria y ejecución privilegiada.  Y hay tareas que
necesitan una mitad en espacio de kernel y otra en espacio de usuario
para tener sentido.  Digamos que la mitad de afuera del kernel es parte
del sistema operativo, pero no del kernel.

Concreto: fuse es kernel, zfs-fuse no lo es.  Los dos están en el
sistema operativo.  El kernel por sí sólo es ligeramente estéril,
necesita de acompañamiento, de nada sirve manejar una tarjeta de red si
no podés asignarle una dirección.  ifconfig no es parte del kernel, pero
sí del sistema operativo.  Como esa hay otras "aplicaciones" cuya única
función es hablar con el kernel o con estructuras del kernel.  Esas son
del sistema operativo, no del kernel en sí.

Esa distinción me ayudó a entenderlo cuando desarrollaba en el kernel,
me ayuda a entender ahora algunas cosas.  Pero de repente eso responde a
mi "modelo mental" que, aún brindando explicaciones correctas, puede no
corresponderse con la realidad.

>  Creo que
> podemos estar de acuerdo, y es una definición clásica" que el sistema
> operativo es "El programa o conjunto de programas que intermedia el
> acceso entre dispositivos físicos y programas de aplicación" eso se
> acerca más a lo que llamamos "kernel" que a otra cosa.

La duda aparece en lo que es un programa de aplicación, es el borde lo
que es borroso.  Y en general terminás dando círculos, haciendo que lo
que es de aplicación es lo que no está en el kernel.  El servidor X, ¿es
aplicación?  Con el nivel de charla que tiene directamente con el
hardware gráfico ... es difícil verlo así, en alguno de sus módulos al
menos.

Y a esa definición le sobra por lo menos el "físicos" después de los
dispositivos.  Si no te quedan afuera cosas como 'pty'.  Y justamente
cuando sacás eso y empezás a soportar dispositivos "virtuales", que
tienen una pata en el kernel y otra en una aplicación (para pty podés
pensar en 'screen') ... definitivamente la definición se complica.
Porque screen es aplicación, pero al mismo tiempo es la que hace
funcionar el dispositivo pty, en su lado maestro enviando información
que va a ir a kernelspace para volver a userspace (donde se considera
que vino del kernel).  Screen está en cierta manera en los dos lados a
la vez, aunque siempre en userspace, alimentando un dispositivo para el
kernel y guardando una imagen de pantalla de aplicación.

Eduardo.

[1] http://alouche.net/2010/07/11/linux-kernel-out-of-memory-management/
[2] http://www.odi.ch/weblog/posting.php?posting=592