Hace tiempo que no escribo nada sobre Minix. Vimos como instalarlo, compilar algo,... pero hoy voy a comentaros una antigua discusión que han mantenido a lo largo del tiempo Tanenbaum (el creador de Minix) y Linus (el creador de Linux).
Como ya sabreis, Linus se baso en Minix para crear su primera versión de Linux (lo podéis leer al final de este post). Pero Minix fue diseñado con las últimas tendencias en sistemas operativos (microkernel) y Linux en cambio se empleo el diseño clásico (monolítico).
Ya desde entonces Tanenbaum decía que el diseño de Linux era antiguo. Linus entró a saco. Después Tanenbaum acuso a Linus (y sus seguidores) que antes de hablar tenían que estudiar el tema. Al final se terminó debatiendo la filosofía del software libre. Si había libertad de modificación, de distribución, y cosas por el estilo.
Un resumen de la discusión aquí: http://www.dina.kvl.dk/~abraham/Linus_vs_Tanenbaum.html
Saludos.
Mostrando entradas con la etiqueta minix. Mostrar todas las entradas
Mostrando entradas con la etiqueta minix. Mostrar todas las entradas
martes, marzo 03, 2009
sábado, febrero 07, 2009
Minix. De la 00000 hasta la 000068
Hoy vamos a empezar a analizar el código fuente de MINIX.
Para ello tendremos que recordar algunas nociones de C. El código se encuentra en /usr/src/.
Tanembaun ha numerado cada línea de código desde la 00000 hasta la 28864.
De la 00000 a la 00068 corresponden al fichero include/ansi.h
Recordemos que los ficheros .h son ficheros de cabecera. Una aplicación de cierto tamaño se diseña de forma modular. Cuando se hace un módulo en C (fichero .c), se suele preparar también la interfaz de ese módulo (fichero .h).
La interfaz sirve para hacer público al resto de módulos algunas funciones, variables, tipos de datos y constantes. Los módulos que vayan a utilizar ese módulo lo incluirán por medio de un #include="cabecera.h".
El directorio /usr/src/contiene ficheros de cabecera del estándar POSIX.
Incluye 3 subdirectorios:
-sys: ficheros de cabecera POSIX.
-minix: ficheros de cabecera utilizados por MINIX.
-ibm: ficheros de cabecera específicos de IBM PC.
Ansi.h
Hay una serie de ficheros de cabecera que son de propósito general y se procesan en todas las compilaciones de todos los módulos de MINIX.
Ansi.h es uno de ellos. Es el segundo que se procesa siempre. Sólo se procesa antes /include/minix/config.h
Propósito de Ansi.h:
Comprobar si el compilador sigue los requerimientos del C estándar (ANSI C).
El estándar define varias macros que pueden ser testeadas en tiempo de compilación.
Nota: Para entender Ansi.h hay que conocer las directivas del preprocesador.
Un compilador que siga el estándar establecerá __STDC__ = 1.
Lo primero que se hace en Ansi.h es comprobar el valor __STDC__. Si es 1, entonces _ANSI se define como 31459, que significa que sigue el estándar.
Luego hace una comprobación más (considera que si está definido __GNUC__ también es ANSI). Por lo tanto _ANSI se establece a 31459.
Ahora viene lo más importante. En C antes de utilizar una función hay que declararla por medio de un prototipo. En el prototipo se adelantan los tipos de datos que recibe y el que devuelve. En ANSI C es así:
int calcular(int numero1, int numero2)
Pero en otros C-s puede ser así:
int calcular()
Por medio de la macro _PROTOTYPE el preprocesador transformará nuestros prototipos a la forma adecuada.
Por último, en Ansi.h se define _POSIX_SOURCE como valor 1 en función de otras macros.
Saludos.
Para ello tendremos que recordar algunas nociones de C. El código se encuentra en /usr/src/.
Tanembaun ha numerado cada línea de código desde la 00000 hasta la 28864.
De la 00000 a la 00068 corresponden al fichero include/ansi.h
Recordemos que los ficheros .h son ficheros de cabecera. Una aplicación de cierto tamaño se diseña de forma modular. Cuando se hace un módulo en C (fichero .c), se suele preparar también la interfaz de ese módulo (fichero .h).
La interfaz sirve para hacer público al resto de módulos algunas funciones, variables, tipos de datos y constantes. Los módulos que vayan a utilizar ese módulo lo incluirán por medio de un #include="cabecera.h".
El directorio /usr/src/contiene ficheros de cabecera del estándar POSIX.
Incluye 3 subdirectorios:
-sys: ficheros de cabecera POSIX.
-minix: ficheros de cabecera utilizados por MINIX.
-ibm: ficheros de cabecera específicos de IBM PC.
Ansi.h
Hay una serie de ficheros de cabecera que son de propósito general y se procesan en todas las compilaciones de todos los módulos de MINIX.
Ansi.h es uno de ellos. Es el segundo que se procesa siempre. Sólo se procesa antes /include/minix/config.h
Propósito de Ansi.h:
Comprobar si el compilador sigue los requerimientos del C estándar (ANSI C).
El estándar define varias macros que pueden ser testeadas en tiempo de compilación.
Nota: Para entender Ansi.h hay que conocer las directivas del preprocesador.
Un compilador que siga el estándar establecerá __STDC__ = 1.
Lo primero que se hace en Ansi.h es comprobar el valor __STDC__. Si es 1, entonces _ANSI se define como 31459, que significa que sigue el estándar.
Luego hace una comprobación más (considera que si está definido __GNUC__ también es ANSI). Por lo tanto _ANSI se establece a 31459.
Ahora viene lo más importante. En C antes de utilizar una función hay que declararla por medio de un prototipo. En el prototipo se adelantan los tipos de datos que recibe y el que devuelve. En ANSI C es así:
int calcular(int numero1, int numero2)
Pero en otros C-s puede ser así:
int calcular()
Por medio de la macro _PROTOTYPE el preprocesador transformará nuestros prototipos a la forma adecuada.
Por último, en Ansi.h se define _POSIX_SOURCE como valor 1 en función de otras macros.
Saludos.
miércoles, febrero 04, 2009
Primera compilación MINIX
Jeje, esto del MINIX es un pequeño vicio. Es bastante sencillo pero potente a la vez.
Vamos a probar el compilador C:
Iniciamos MINIX e iniciamos sesión como root.
Ahora a buscar el compilador. Vemos que gcc no está. Probamos cc y ¡BINGO!
Probamos el primer programa obligado editando con el VI el fichero prueba.c
Aviso: En lugar de los símbolos de mayor y menor pongo asteriscos para no confundir el HTML.
#include *stdio.h*
main()
{
printf("Hola mundo");
}
Compilamos...
#cc prueba.c
En este punto el compilador nos avisa que estamos utilizado una sintaxis antigua en la función main. Se solucionaría con main(void) si es que nos molesta el warning.
Y ejecutamos: #./a.out
Para que diga: Hola mundo.
Muy bien, la cosa pinta bien, pero, y ¿las llamadas al sistema?
Utilicemos la fork. Recordad (lo decía ayer), que la fork sirve para crear un proceso hijo.
Nota: En lugar del símbolo menor he utilizado *menor*, y en lugar del símbolo mayor: *mayor*
void main(void)
{
int retorno_fork;
printf("El proceso %d va a crear un proceso hijo", getpid());
retorno_fork = fork();
if (retorno_fork () *menor* 0)
{
printf("No se ha podido crear el proceso");
exit(-1);
}
printf("Esto lo ejecutan tanto el proceso padre como el hijo");
if (retorno_fork *mayor* 0)
{
printf("Soy el proceso padre y he creado el proceso hijo numero %d", retorno_fork);
}
else
{
printf("Soy el proceso hijo. Me voy a dormir");
}
}
Como se ve en el propio código, si la fork devuelve un número negativo algo ha fallado y no se ha creado el proceso hijo.
Luego viene la parte que la ejecutan tanto el padre como el hijo (es lo que está después del fork).
Por último, montamos otra bifurcación. Sabemos que al proceso padre la fork le ha devuelto un número mayor que 0 y que es el pid del proceso hijo. Al proceso hijo la fork le devuelve un 0.
Saludos.
El proceso FORK
El proceso Fork es la única forma que tenemos en MINIX3 para crear un nuevo proceso (por eso es tan importante).
Crea un proceso idéntico al original (proceso padre). Después del Fork, ambos procesos (el hijo y el padre) se ejecutan de forma separada.
El proceso fork devuelve un valor de retorno que es cero en el hijo y en cambio en el padre es el PID del proceso hijo. De esta forma cada proceso sabe si es padre o hijo. Esto es así, porque normalmente el proceso hijo tiene que ejecutar algo diferente al proceso padre.
Respecto a gestión de procesos sólo hay 9 llamadas al sistema más:
waitpid: de esta forma el proceso padre espera a que termine el hijo.
wait: versión antigua de waitpid.
execve: Reemplaza la imagen core de un proceso.
exit: termina la ejecución de un proceso y devuelve el estado.
brk: establece el tamaño del segmento de datos.
getpid: devuelve el pid del proceso.
getpgrp: devuelve el id del grupo de proceso.
setsid: crea un nueva sesión y devuelve el id del grupo de proceso.
ptrace: utilizado para debugging.
Saludos.
Crea un proceso idéntico al original (proceso padre). Después del Fork, ambos procesos (el hijo y el padre) se ejecutan de forma separada.
El proceso fork devuelve un valor de retorno que es cero en el hijo y en cambio en el padre es el PID del proceso hijo. De esta forma cada proceso sabe si es padre o hijo. Esto es así, porque normalmente el proceso hijo tiene que ejecutar algo diferente al proceso padre.
Respecto a gestión de procesos sólo hay 9 llamadas al sistema más:
waitpid: de esta forma el proceso padre espera a que termine el hijo.
wait: versión antigua de waitpid.
execve: Reemplaza la imagen core de un proceso.
exit: termina la ejecución de un proceso y devuelve el estado.
brk: establece el tamaño del segmento de datos.
getpid: devuelve el pid del proceso.
getpgrp: devuelve el id del grupo de proceso.
setsid: crea un nueva sesión y devuelve el id del grupo de proceso.
ptrace: utilizado para debugging.
Saludos.
lunes, febrero 02, 2009
Llamadas al sistema
Hola chic@s,
Ya lo siento, he andado muy liado y no he tenido tiempo para nada. Mañana me quito una complicación para una buena temporada :-)
Vuelvo al tema de los sistemas operativos...
Intentaré contestar lo mejor que pueda a estas tres preguntas básicas.
¿Qué son las llamadas al sistema?
¿Qué es POSIX?
¿Qué es UNIX?
Las llamadas al sistema son la forma en las que las aplicaciones interactúan con el sistema operativo. Digamos que es el interface entre los programas y el S.O.
POSIX significa "Portable Operating System Interface". Richard Stallman propuso el nombre. Hoy en día es un estándar internacional ISO ISO/IEC 9945-1.
El estándar se desarrolló por parte de la IEEE para lograr que los programas pudieran ejecutarse fácilmente (portarse) en los diferentes UNIX. Es un conjunto mínimo común de llamadas al sistema.
Minix3, HP-UX, Solaris, MacOSX, AIX, BSD/OS, etc. etc. cumplen alguna de las versiones POSIX. Es curioso que haya windows POSIX, y linux no certificados POSIX. No hay que darle demasiada importancia a la falta de certificación ya que hay un tema de pasta por detrás.
Para definir UNIX vamos a dejar de lado los temas legales relacionados con marcas registradas (propiedad de "The Open Group"). Solo decir que IEEE certifica sistemas UNIX en base al cumplimiento de POSIX, y que existe otra certificación que por resultar más barata que se ha convertido en el estándar de hecho. Si quieres saber más...http://es.wikipedia.org/wiki/Single_UNIX_Specification
Ahora si, entremos un poco en materia:
MINIX3 tiene 53 llamadas al sistema principales. Nos dice Tanenbaum que hay unas pocas más, pero que son muy especiales.
Es importante un matiz. El estándar POSIX especifica un número de procedimientos que el sistema debe contener, pero no quiere decir que todas sean llamadas al sistema. En el caso de MINIX hay procedimientos POSIX que se soportan en forma de librerías. También ocurre que algunas llamadas del sistema son simples variaciones de otras y se implementan con una sola llamada al sistema.
Mañana a ver si empezamos a desgranar la llamada más bonita de todas: fork.
Saludos.
Ya lo siento, he andado muy liado y no he tenido tiempo para nada. Mañana me quito una complicación para una buena temporada :-)
Vuelvo al tema de los sistemas operativos...
Intentaré contestar lo mejor que pueda a estas tres preguntas básicas.
¿Qué son las llamadas al sistema?
¿Qué es POSIX?
¿Qué es UNIX?
Las llamadas al sistema son la forma en las que las aplicaciones interactúan con el sistema operativo. Digamos que es el interface entre los programas y el S.O.
POSIX significa "Portable Operating System Interface". Richard Stallman propuso el nombre. Hoy en día es un estándar internacional ISO ISO/IEC 9945-1.
El estándar se desarrolló por parte de la IEEE para lograr que los programas pudieran ejecutarse fácilmente (portarse) en los diferentes UNIX. Es un conjunto mínimo común de llamadas al sistema.
Minix3, HP-UX, Solaris, MacOSX, AIX, BSD/OS, etc. etc. cumplen alguna de las versiones POSIX. Es curioso que haya windows POSIX, y linux no certificados POSIX. No hay que darle demasiada importancia a la falta de certificación ya que hay un tema de pasta por detrás.
Para definir UNIX vamos a dejar de lado los temas legales relacionados con marcas registradas (propiedad de "The Open Group"). Solo decir que IEEE certifica sistemas UNIX en base al cumplimiento de POSIX, y que existe otra certificación que por resultar más barata que se ha convertido en el estándar de hecho. Si quieres saber más...http://es.wikipedia.org/wiki/Single_UNIX_Specification
Ahora si, entremos un poco en materia:
MINIX3 tiene 53 llamadas al sistema principales. Nos dice Tanenbaum que hay unas pocas más, pero que son muy especiales.
Es importante un matiz. El estándar POSIX especifica un número de procedimientos que el sistema debe contener, pero no quiere decir que todas sean llamadas al sistema. En el caso de MINIX hay procedimientos POSIX que se soportan en forma de librerías. También ocurre que algunas llamadas del sistema son simples variaciones de otras y se implementan con una sola llamada al sistema.
Mañana a ver si empezamos a desgranar la llamada más bonita de todas: fork.
Saludos.
martes, enero 20, 2009
Instalación de Minix II
Estoy reventado. Hoy dos reuniones de cambio de junta. En una soy de la junta saliente y en la otra de la entrante. ¡Ufff! Ayer explique cómo preparar una partición para Minix. Hoy toca la instalación.
Instalación de MINIX
Arrancamos con el CD de instalación.
Nos aparecerá el siguiente mensaje:
Welcome. Minix 3 is still under development and may contain bugs and other imperfections. If you would like to help develop MINIX 3 further into a rock solid, reliable operating system, please go to the official Website: www.minix3.org to see how you can help. Login as root and run 'setup' to install Minix. Minix Release 3 version 1.0 (console) minix login:
Seguimos esa instrucción:
# setup
: (cuando aparecen los dos puntos está esperando a que pulsemos el enter).
Primero pregunta por el Keyboard y nos da unas opciones de teclado.
Seleccionamos spanish.
Luego preguntar por la tarjeta de red.
Yo he indicado la opción por defecto (que no tengo tarjeta). Más adelante podremos instalarla sin problemas.
Ahora a ver si queremos la instalación Minimal o Full. Por supuesto queremos Full.
Cuando nos pregunte por la partición Minix indicamos automatic mode.
Ahora llegamos a un punto importante y peligroso.
Nos pregunta por el disco a utilizar. Yo sólo tengo un disco con la partición del Kubuntu (partición del S.O. y partición de swap) y un espacio libre en el mismo disco.
Disk number to use: 0 (el único que tengo).
Region: 1 (Yo he tenido que seleccionar la region 1 que es el espacio libre del disco).
Cuidado. Tu instalación es diferente a la mia. El instalador MINIX avisa: "This is the point of no return".
El instalador a elegido mi "region 1 of disk /dev/c0d0".
Ahora nos dice: "MINIX will take up 331 Mb without /home. How big do you want your /home to be in Mb (0-1668)". En este punto no se si he elegido bien. Le he dado el máximo.
Ahora pregunta por el tamaño del bloque: "The maximum (and default) file system block size is 4 kb. Le digo que me parece bien.
Me muestra los filesystems:
root /dev/c0d0p1s0 16 Mb /home /dev/c0d0p1s1 1.668 Mb /usr /dev/c0d0p1s2 rest of c0d0p1
Wait for bad block detection.
Al final nos dice que podemos ejecutar shutdown "to exit MINIX 3 and enter the boot monitor".
Type 'boot c0dXp1 where X is the bios drive number of the drive you installed on, to try your new MINIX system. Probably the right command is boot d0p1.
Con el shutdown final la instalación ya ha terminado. Ahora el problema es arrancar el MINIX ya que el gestor de arranque GRUB no tiene la opción de arranque de MINIX.
Configuración de GRUB:
Arrancamos Kubuntu y abrimos una sesión de terminal.
Hay que editar el fichero /boot/grub/menu.lst
Para editar el fichero hay que darle permisos de escritura a root:
sudo chmod 744 menu.lst
Editamos con sudo vi menu.lst
Después de las opciones de arranque de Kubuntu añadimos el arranque de MINIX:
title Minix 3 rootnoverify (hd0,2) chainloader +1 boot
En mi instalación la cosa ha funcionado con (hd0,2) pero en la tuya puede ser (hd0,0), (hd0,1), etc.
Por supuesto, para reiniciar: shutdown -r now y a disfrutar del nuevo MINIX.
Saludos.
lunes, enero 19, 2009
Instalación de Minix
Ayer os comentaba lo del Minix.
Me he comprado el libro que viene con un CD, pero si os apetece instalarlo os lo podéis bajar gratiX de www.minix3.org
La forma de instalarlo parece sencilla. Se descarga la imagen .iso, se graba el CD y se arranca con él. Se supone que encontrará una partición libre etc. etc.
Mi PC de sobremesa tiene un único disco duro de 40 Gb. Todo el disco está ocupado por Kubuntu , por lo que lo primero es reducir alguna de las particiones.
No he encontrado el CD de arranque de Kubuntu (creo que lo tengo en el trabajo), pero sí he visto un viejo Ubuntu 7.10.
Arrancamos con el CD de Ubuntu. Vamos a System, Administration, y seleccionamos "Partition Editor". Nos abrirá el GParted que es muy parecido a PartitionMagic.
1.-Selecciono la partición /dev/sda1 (ext3).
2.-Clic en botón Resize/Move.
3.-"Free Space Following" (espacio libre por el final) indica 0. Le ponemos 2.000 Megas. El mínimo necesario para Minix es 200 Mb.
4.-Clic en el botón Apply.
---***---
Mientras se reduce la partición os comentaré unos chascarrillos sobre Minix y la rivalidad entre Linus Towards y Andrew S. Tanenbaum.
Tanenbaum creó Minix con propósitos educativos. Su intención no era complicarlo. Quería mantenerlo pequeño de forma que se pudiera estudiar en un curso.
Siendo estudiante, Linus tuvo que aprender Minix. Con los conocimientos que obtuvo de aquel pequeño S.O. creó otro S.O. al que llamo Linux.
Siendo así las cosas, terceras personas acusaron a Linus de robar el código de Minix. Según nos dicen desde el FAQ en castellano de www.minix3.org esto no es más que basura. En el 2004 Tanenbaum ya dejó clara su postura al respecto defendiendo totalmente a Linus Towards y al propio Linux.
Saludos.
Suscribirse a:
Entradas (Atom)
