Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
Ver: Modo: Orden:
¿Por qué en C? | 19 comentarios (19 temáticos, editoriales, 0 ocultos)
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)
Ver: Modo: Orden:
Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

ecol Logo Powered by Scoop
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