Libertonia || Comments || ¿Por qué en C?


Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios

¿Por qué en C? | 19 comentarios (19 temáticos, editoriales, 0 ocultos)

No se que poner aqui (none / 0) (#13)
por thuban a las Wed Jul 28th, 2004 at 06:43:34 PM CET
(Información Usuario)

De verdad que es un problema elegir el titulo...

Tal vez no se use C++ ni ningun lenguaje moderno orientado a objetos porque los lenguajes orientados a objetos no sean adecuados para hacer un kernel.

No es una afirmacion si no una suposicion, aunque pueda leerse de otra manera.

Veamos. Los lenguajes orientados a objetos son adecuados cuando en el analisis puedes hacer una jerarquia de clases, cuando hay una mama que tiene unas cuantas hijas que se parecen mucho a mama paro que no son exactamente iguales. Entonces la POO te viene de miedo porque creas una variable de tipo Mama y la puedes asignar a cualquiera de sus hijas.

¿Al diseñar un kernel se da esa necesidad de diseño? Si. Podemos meter un algoritmo basico de planificacion de procesos dentro de una ProcPlanifMami y despues ponernos a escribir varios PorcPlanifHijo1, PorcPlanifHijo2, PorcPlanifHijo3... permitir a root o al mismisimo usuario cual prefiere aplicar (cad uno dentro de su espacio, claro) y aplicar el que elija.

Estaria bien, pero ¿cuantos sistemas operativos lo permiten realmente? Uno o ninguno. En realidad el SO viene con un algoritmo y te aguantas. Como mucho se puede variar (y lo estoy aventurando) en la instalacion o se podria modificar si te permiten compilarlo. Pero una vez instalado, te aguantas con el que viene.

Y asi, con todos los kernels que lo tienen todo dentro. Los kernels que estan hechos de modulos diferentes para gestionar cosas diferentes, como dispositivos diferentes, sistemas de archivos y otras cositas de esas que hay en los ordenadores, cargan para hacer el trabajo todos los modulos que hagan falta, pero estos modulos son cosas diferentes al kernel. Estan muy relacionados pero no son el kernel.

El kernel en si no requiere hacer un diseño orientado a objetos, asi que por pequeña que sea la sobrecarga del sistema, por pequeño que sea el primer inconveniente que aparezca, se desestima y se va al viejo y conocido C que funciona bien y es *suficiente* para hacer el trabajo. Y en algunos sitios, incluso ensamblador.

Otra cosa es el asunto de los entornos graficos, en los que ni entro ni salgo.

No me convences :) (none / 0) (#14)
por man ls a las Wed Jul 28th, 2004 at 08:07:21 PM CET
(Información Usuario)

El asunto de la herencia no me parece lo más importante de la orientación a objetos. Puedes hacer que nadie herede de tus objetos y listo.

Lo que veo es que los desarrolladores del kelmer se pasan la vida inventando pseudo-objetos para gestionar objetos, de los que encima hay que contar las referencias (otra cosa que en C++ se hace de manera más natural). Eso por no hablar de los incomodísimos nombres de las funciones, lógico ya que en C no hay espacios de nombres.

Me da la impresión de que están siendo constreñidos por el lenguaje que usan. Vamos, que las herramientas se les quedan pequeñas. ¿No os parece?

[ Padre ]

OOP en el Kernel (none / 0) (#16)
por ridiculum a las Thu Jul 29th, 2004 at 12:50:00 AM CET
(Información Usuario)

El kernel de Linux, y el de los BSD tienen unas partes bastante importantes que se pueden modelar como OO. Sin ir mas lejos, el VFS es OO. Tienes un "objeto" generico que representa un sistema de archivos, con un buen puñado de funciones virtuales (implementadas como punteros a funcion) y luego, cada sistema de archivos real "hereda" de ese objeto generico y proporciona la implementacion de esas funciones virtuales.
Ese es el primer susbsitema que se me viene a la cabeza que use OO, pero seguramente los drivers de los dispositivos se puedan generalizar de ese modo, a parte de los kobjects ya mencionados.

Sobre la variedad de planificadores, si nos centramos en los planificadores de I/O, en linux puedes elegir entre 3, sino recuerdo mal (rama 2.6): Anticipatory, Deadline, CFQ, asi que bien podria usarse herencia, no?. Respecto de los planificadores de CPU, cero que ahora mismo solo hay uno, pero con diferentes politicas: Round Robin, FIFO, Other (se puede cambiar la politica con sched_setscheduler() y Other es la politica que siguen los procesos por omision).

Luego nos podriamos ir a las diferentes disciplinas de colas que se usan para el QoS, que bien podria entenderse como un modelo de herencia, al igual que los casos anteriores.

[ Padre ]

El planificador de tareas configurable (none / 0) (#17)
por jorginius ("jorginius" en Google Mail) a las Thu Jul 29th, 2004 at 01:01:59 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

Estaría bien, pero ¿cuantos sistemas operativos lo permiten realmente [cambiar el planificador]? Uno o ninguno. En realidad el SO viene con un algoritmo y te aguantas.

Muchos por no decir todos. Incluso en Linux puedes escoger para una tarea un algoritmo u otro del planificador con la llamada de sistema sched_setscheduler(2) o sencillamente en función de la prioridad, en sistemas multiprocesador el algoritmo de planificación apenas cambia (pero lo hace) y en un Mosix es distinto.

En general un microkernel da soporte para el diagrama de estados pero lo que es el planificador puede correr en espacio de usuario. Esto por ejemplo lo puedes ver en L4, donde puedes usar el tuyo si no te apetece usar el de por defecto en cualquier momento y desde espacio de usuario.

Los kernels que estan hechos de modulos diferentes para gestionar cosas diferentes [...] pero estos modulos son cosas diferentes al kernel. Estan muy relacionados pero no son el kernel.

Si lo dices por Linux, un módulo comparte el espacio de direccionamiento del kernel y a todo los efectos es lo mismo que él. Desde un módulo en teoría sólo deberías acceder a los símbolos públicos que cada módulo y el kernel exportan, con sus chequeos de licencia y demás, pero nada te impide leer/escribir en cualquier otra dirección de memoria. Fijaté que el kernel exporta sus símbolos de la misma manera que todos los módulos. En muchos sentidos se comporta bastante como un módulo más.

... Y ya que hablamos de planificadores, no me parece tan descabellado tener un planificador de tareas modular haciendo relativamente pocos cambios en el kernel.

El kernel en si no requiere hacer un diseño orientado a objetos, asi que por pequeña que sea la sobrecarga del sistema, por pequeño que sea el primer inconveniente que aparezca, se desestima y se va al viejo y conocido C que funciona bien y es *suficiente*

El kernel de NT está orientado a objetos, a pesar de estar escrito en C. En el de BeOS es aún más claro la orientación al estar escrito en C++. En el kernel de Linux hay un montón de abstracciones que recuerdan a clases y objetos (como la capa de VFS o la estructura de los drivers del framebuffer). La orientación a objetos no tiene porque no pegar bien dentro del kernel.

En el caso de Linux, del C y de cómo está escrito supongo que hay que pensar en quién lo escribió y con qué herramientas: Linus después de todo era un estudiante en rodaje, así que siguió el manual y diseñó el kernel semejante al del UNIX clasico, opción más sencilla que inventar un innovador nuevo diseño microkernel orientado a objetos... Y para programarlo usando las herramientas de Gnu que usaba habitualmente tenía sólo un compilador de C, porque si el compilador de C++ apestaba en 1993 un año antes debía ser para echarse a llorar (todo esto suponiendo que Linus estuviera lo bastante familiarizado con el "novedoso" C++ como para considerar usarlo en el kernel).

En fin, sea como sea lo que sí es cierto es que reescribirse ahora mismo el kernel en C++ es un trabajo enorme, no digo ya si además hacemos reingeinería para que quede más OO... Y tampoco es que las mejoras fueran a ser brutales, si es que hubiera alguna.

[ Padre ]

Para man ls, ridiculum y jorginius (none / 0) (#18)
por thuban a las Thu Jul 29th, 2004 at 10:20:59 AM CET
(Información Usuario)

Es que no me apetece escribir lo mismo tres veces...

Cuando escribia eso estaba pensando que en el caso del sistema de archivos la OO si tenia sentido, pero lo tiene a nivel de diseño en una pizarra: tenemos un sistema de ficheros generico con unas cuantas operaciones y un monton de hijos que heredan de el y uno implementa reiser, otro fat que a su vez es mama de fat16, fat32... En la pizarra queda bien y la OO se adapta muy bien al caso. Pero se me ocurren dos cosas:

- ahora eso se hace con C mondo y lirondo y funciona, asi que no hace tanta falta, y alguna ventaja tendra...

- si se hace con OO, no se van a conformar con hacer esa jerarquia de clases. Haran un objeto Fichero, un objeto Atributo, un objeto Informacion que diga lo que puede hacer el "driver" en cuestion... Vamos, que va a quedar precioso en la pizarra pero va a ser pesadisimo (como el Swing de Java, en otro orden de cosas)

Tambien se puede hacer un diseño OO con pocas clases, pero entonces ¿para que OO? ¿Esta bien hacer un diseño OO "a medias"? Incluso se podria programar en C pero compilando con C++, de manera que se podrian declarar las variables cerca de donde se usan y hacer mas legible el codigo, pero eso no es POO.

Y con todo lo demas, parecido.

No se trata de hacer un sistema que sea teoricamente correcto si no de hacer un sistema que funcione y ademas que lo haga muy bien, porque si el kernel no funciona bien, nada funciona bien.

La POO tiene muchas ventajas cuando se trata de hacer el codigo mantenible, ampliable y todo eso siempre que te pases una buena temporada planificandolo todo antes de tirar la primnera linea, pero en el kernel del sistema la facilidad para meter modificaciones o para ampliar el sistema pasa a ser una cuestion secundaria frente al rendimiento y el ahorro de recursos.

No digo que no se puedan modelar cosas del kernel con OO, digo que no es necesario modelarlas asi para que funcione.

PD: No sabia lo de la funcion esa, pero me pregunto eso se puede usar en la practica para cambiar EN VUELO la politica de planificacion de un proceso (¿solo de un proceso?) y tener varios algoritmos funcionando al mismo tiempo en el sistema. Me refiero a que si escribo un comando que reciba por parametro un PID, lo pongo en /usr/bin con el bit de "root el Destructor" o en el sudoers para que cualquiera lo ejecute, ¿podria tener varias politicas funcionando al mismo tiempo?

PD2: A lo que me referia con lo de los modulos es que los modulos pueden estar escritos con cualquier cosa que te funcione porque al fin y al cabo, no son el kernel. Si cargas un modulo pesado escrito en Java compilado (es un ejemplo extremo) es cosa tuya. Los que han hecho el kernel no seran culpables de que tu ordenador vaya despacio. Pero si es culpa suya si el kernel mismo va despacio.

PD3: Si es muy probable que el kernel este escrito en C y sea monolitico porque Linus no supiera hacerlo mejor siendo estudiante. De hecho soy de los que piensan que Linux se le fue a Linus de las manos y que el debio ser de los primeros sorprendidos con el exito que ha tenido.

PD4: Parece que ultimamente en Libertonia hay comentarios...

[ Padre ]

Los libros no muerden :-) (none / 0) (#19)
por jorginius ("jorginius" en Google Mail) a las Thu Jul 29th, 2004 at 01:04:48 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Cuando escribia eso estaba pensando que en el caso del sistema de archivos la OO si tenia sentido [...] Pero se me ocurren dos cosas:

- ahora eso se hace con C mondo y lirondo y funciona, asi que no hace tanta falta, y alguna ventaja tendra...

Ahora está escrito en C, pero es orientado a objetos. La capa VFS de Linux es más o menos como la describes desde que se introdujo en la versión 2.0, y hay más ejemplos de POO en Linux.

- si se hace con OO, no se van a conformar con hacer esa jerarquia de clases. Harán un objeto [tal y cual que haga pascual y...]

Si quieres ver como se hace realmente, consulta el diseño de otros sistema donde la POO se haya considerado desde el principio. Por ejemplo NT, donde "todo" lo que maneja el kernel es o un objeto dispatcher o un objeto de control y donde la jerarquía de herencia se amplía capa a capa (la clase thread de usuario hereda de thread del kernel y así) o BeOS o QNX o cualquer sistema operativo moderno en realidad.

No sabia lo de la funcion esa, pero me pregunto eso se puede usar en la practica para cambiar EN VUELO la politica de planificacion de un proceso [...] ¿podria tener varias politicas funcionando al mismo tiempo?

Sí. Las tareas de tiempo compartido no se planifican igual que las tareas de tiempo real (blando) y puedes tener de ambos tipos (diferentes colas con diferentes políticas) en un sistema. Consulta las páginas man.

Lo que no puedes hacer en Linux es introducir nuevas políticas en caliente, a menos que añadieses soporte modular para planificadores de tareas. Debes escoger entre las que hay. En frío puedes parchear con varios planificadores alternativos bastante populares. Otros sistemas dan más opciones o incluso permiten planificadores en espacio de usuario.

PD2: A lo que me referia con lo de los modulos es que los modulos pueden estar escritos con cualquier cosa que te funcione porque al fin y al cabo, no son el kernel. Si cargas un modulo pesado escrito en Java compilado (es un ejemplo extremo) es cosa tuya.

Te equivocas: los módulos son núcleo. Cuando lo cargas, el código del módulo es insertado en alguna parte del espacio de direccionamiento del kernel y corre desde allí, en modo privilegiado y demás, exáctamente igual que lo hace el código que no es modular. Deberías repasar cómo funciona.

Desde luego no podrías programar ningún módulo en Java a menos que incluyeses de alguna forma la JVM dentro del kernel. Lo mismo si quieres usar una biblioteca de usuario como glib o pcre. No tienes más libertad para programarlos que la que tienes para escribir otro código del kernel.

Para que fuera como tu dices, Linux debería ser micronúcleo :-D

PD4: Parece que ultimamente en Libertonia hay comentarios...

Mejor que estudiar...

[ Padre ]

¿Por qué en C? | 19 comentarios (19 temáticos, editoriales, 0 ocultos)

Menu

· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login


Nueva cuenta
Usuario:
Contraseña:

Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda