Ingeniería en Informática Sistemas Operativos
Anuncio
Ingeniería en Informática Sistemas Operativos MBUM (MultiBootloader de la Universidad de La Matanza) Equipo De Investigación Alvarez Matías Barrett Guillermo Leguizamón Romina Otero Andrea 33.081.870 33.676.599 28.053.350 28.350.661 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM Índice TEMAS RELACIONADOS ...................................................................................................................................... 3 OBJETIVOS ............................................................................................................................................................ 10 DESARROLLO ....................................................................................................................................................... 10 Instalación del MBUM...................................................................................................................................... 10 Estructura de la partición del BUM .................................................................................................................. 11 Funciónamiento del MBUM .............................................................................................................................. 11 Gestor de particiones ................................................................................................................................................................. 13 Restricciones .................................................................................................................................................... 14 CONCLUSIONES.................................................................................................................................................... 14 Pendientes: ....................................................................................................................................................... 14 Booteo directo de Linux. ........................................................................................................................................................... 14 Reconocimiento de varios discos.............................................................................................................................................. 15 Reconocer Windows sin que la partición este marcada como activa. ..................................................................................... 15 File system para la partición del BUM. .................................................................................................................................... 15 Booteo desde pendrive. ............................................................................................................................................................. 16 APENDICE A .......................................................................................................................................................... 17 Organización de archivos ................................................................................................................................. 17 Estructuras de datos utilizadas: ........................................................................................................................ 17 stuCHS: ...................................................................................................................................................................................... 17 stuDiskAddressPacket ............................................................................................................................................................... 17 stuPartitionBootRecord ............................................................................................................................................................. 18 stuComando ............................................................................................................................................................................... 18 Descripción del contenido de los subdirectorios del proyecto. .......................................................................... 18 ./bum..................................................................................................................................................................................... 18 . /bum/bs_instalador ............................................................................................................................................................. 18 . /bum/include/multiboot ..................................................................................................................................................... 18 ./bum/mbr_hdd ..................................................................................................................................................................... 18 ./bum/pbr_hdd ...................................................................................................................................................................... 18 ./libInit16 .............................................................................................................................................................................. 18 Variables, constantes y funciones definidas en algunos de los archivos intervinientes ....................................... 18 Directorio /bum/ ........................................................................................................................................................................ 18 Archivo: bum.c .................................................................................................................................................................... 18 Archivo: bum.h .................................................................................................................................................................... 19 Archivo: config.c ................................................................................................................................................................. 19 Archivo: comandos.c ........................................................................................................................................................... 20 Archivo: consola.c ............................................................................................................................................................... 26 Directorio / libInit16/ ................................................................................................................................................................ 27 Archivo: bios.c ..................................................................................................................................................................... 27 Archivo: consola.c ............................................................................................................................................................... 31 Archivo: floppy.c ................................................................................................................................................................. 37 Archivo: mem.c.................................................................................................................................................................... 39 Archivo: part.c ..................................................................................................................................................................... 40 Archivo: puertos.c................................................................................................................................................................ 45 Archivo: string.c .................................................................................................................................................................. 45 GLOSARIO.............................................................................................................................................................. 47 BIBLIOGRAFÍA: .................................................................................................................................................... 48 Internet ............................................................................................................................................................. 48 2/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM Temas Relacionados Master Boot Record De todos los sectores de una unidad de disco, el primero de la primera cabeza del primer cilindro tiene una gran importancia ya que es el sitio al que se dirige la BIOS cuando busca si existe en el sistema un dispositivo cargable. Sus 512 bytes contienen tres bloques con información sobre la arquitectura física y lógica del disco: el código maestro de carga, la tabla de particiones y la firma. Código maestro de carga: Si el disco es "bootable", los primeros 446 bytes del MBR (sector de arranque), están ocupados por un pequeño trozo de código denominado código maestro de carga MBC ("Master Boot Code") o cargador inicial (bootstrap loader), que es cargado por la BIOS para comenzar el proceso de carga. El bootstrap loader repasa la tabla maestra de particiones buscando una partición activa. En caso de encontrarla, busca su sector inicial, carga su código en memoria, y le transfiere el control. Dicho código es ya capaz de cargar y ejecutar cualquier otro programa situado en cualquier partición del disco. Que a su vez inicializará directamente el SO, o tal vez una utilidad conocida como gestor de arranque, que permite elegir entre distintas alternativas. Tabla de particiones: A continuación del MBC, se sitúa la tabla maestra de particiones MPT ("Master Partition Table"). Está constituida por cuatro trozos de 16 bytes (4 entradas) que contienen información sobre las particiones definidas en la unidad. Para que un disco "maestro" (cuyo MBR pueda ser accedido por el proceso de carga de la BIOS) sea "bootable", se precisa que alguna de las entradas de la tabla contenga un 80h en el bit de estado, señalando cual es partición activa Firma: Los dos últimos bytes del sector de arranque (MBR) contienen dos caracteres (55h, AAh). que son denominados firma del sector de carga ("Boot record signature") 3/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM Particiones La estructura lógica de segundo nivel que puede encontrarse en un disco físico es la partición primaria. En realidad, una partición no es más que un artificio por el que el sistema puede considerar dividida la unidad física en varias partes, que pueden incluso tener distinta estructura. De hecho, cada una de estas particiones puede albergar un sistema de archivos distinto. Por ejemplo, un sistema FAT de DOS/Windows y un sistema ext2 Linux. Además de otras ventajas, las particiones ofrecen la posibilidad de montar distintos sistemas operativos, lo que a su vez, permite al equipo adoptar "personalidades" distintas según el SO que se cargue en cada momento. En cada unidad se puede tener una partición primaria y una extendida. La partición primaria consume 4 posibilidades del disco, por su parte la extendida consume otras 4 posibilidades. Estructuras: La parte superior corresponde al MBR ("Master Boot Record"). A continuación siguen tres particiones primarias que son de estructura muy sencilla; solo tienen sector de carga ("Boot sector") y área de datos. El área de datos tiene composición análoga en todos los casos; comienza con las tablas FAT; sigue con la estructura del directorio raíz y a continuación los datos propiamente dichos [6]. 4/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM En principio una partición extendida xDp no debería ser distinta de las demás particiones primarias de la unidad. Sin embargo, se le incluyeron algunas estructuras adicionales para poder subdividir su espacio en partes más pequeñas denominadas volúmenes lógicos VL. Lo mismo que la información de la pDp y de cualquier otra partición primaria que se hubiese definido en la unidad, la información básica sobre la xDp está en la entrada correspondiente de la MPT del sector de arranque. A su vez, el primer sector de la xDp es de funciónalidad y estructura semejantes a las del bloque de carga MBR, aunque en este caso se denomina EBR ("Extended Boot Record"). La imagen anterior muestra la organización interna de una partición extendida que contiene tres volúmenes lógicos. La tabla de particiones del EBR se denomina tabla de partición extendida xPT ("Extended Partition table"), y tiene la misma disposición interna que la tabla MPT. Aunque la xPT solo utilizan las dos primeras entradas. La figura muestra el detalle de la estructura interna de una partición extendida con tres volúmenes lógicos. 5/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM La primera entrada de la xPT señala a su propio sector de carga "Boot sector". La segunda señala al EBR del siguiente volumen lógico (si no existiera ningún otro, contiene ceros). Las 2 entradas restantes no se utilizan (contienen ceros). El segundo volumen lógico tiene una estructura similar al primero. La segunda entrada de su xPT señala a la EBR del siguiente y así sucesivamente. Puede verse que la estructura de los VLs es una cadena de enlaces que comienza en la MPT, y que cada volumen lógico contiene su propio EBR. Cuando se declara una xDp, inicialmente el espacio está vacío, pero puede habilitarse construyendo en su interior una o varias particiones lógicas ("Logical partitions"), también denominadas volúmenes lógicos VL. Posteriormente los sistemas DOS/Windows las referencian con una letra, de la C a la Z, como si fuesen discos distintos. Las letras A y B se reservan para designar los sistemas de fichero de los disquetes (que no admiten particiones). Durante el proceso de carga, el SO realiza una exploración ordenada de las unidades de disco y sus volúmenes lógicos. Los sistemas DOS/Windows asignan sucesivamente una letra a cada volumen encontrado. Por esta razón, en una xDp pueden declararse hasta 24 volúmenes lógicos si no se está usando una pDp, o 23 en caso contrario. El factor limitador es la letra que se asigna a cada VL (empiezan por C y terminan con la Z). Por supuesto que salvo circunstancias excepcionales, es muy raro que se definan tal número de VLs en una partición extendida DOS. GRUB El GRand Unified Bootloader (GRUB) es un gestor de arranque múltiple que se usa comúnmente para iniciar dos o más sistemas operativos instalados. Mientras los gestores de arranque convencionales tienen una tabla de bloques en el disco duro, GRUB es capaz de examinar el sistema de archivos. Actualmente, soporta los siguientes sistemas 6/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM de archivos: ext2/ext3 usado por los sistemas UNIX y su variante GNU/Linux ext4 en versiones de pruebas. ReiserFS. XFS de SGI (aunque puede provocar problemas). UFS. VFAT, como FAT16 y FAT32 que son usados por Windows 9.x NTFS usado por los sistemas Windows NT (a partir de Windows NT v.3.51). JFS de IBM. HFS de Apple Inc. Otros ejemplos de cargadores multi arranque son LILO y SYSLINUX. La configuración del grub está basada en tres archivos que se describen a continuación: /boot/grub/menú.lst Este archivo contiene toda la información acerca de las particiones o de los sistemas operativos que se pueden arrancar con GRUB. Sin esta información, el control del sistema no se puede pasar al sistema operativo. /boot/grub/device.map Este archivo traduce los nombre de los dispositivos desde GRUB y la notación del BIOS a nombres de dispositivo s de Linux. /etc/grub.conf Este archivo contiene los parámetros y las opciones que necesita GRUB para instalar el gestor de arranque de forma correcta. GRUB 2 está basado en un proyecto llamado PUPA cuya meta era desarrollar un GRUB más “limpio”, seguro, robusto y potente así como más portable y con soporte para diferentes idiomas. Sin embargo Grub2 es un paquete nuevo que permite: Permitir scripting, condicionales, bucles, variables y funciones. Interfaz gráfica. Extensibilidad mediante carga dinámica de módulos. Portabilidad a distintas arquitecturas. Internacionalización. Soporte para caracteres fuera del conjunto ASCII, mensajes localizados, etc. Mejor administración de memoria. Marco de trabajo modular, jerárquico y orientado a objetos para sistemas de archivo, archivos, dispositivos, unidades, terminales, comandos, tablas de partición y cargadores de SO. 7/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM Instalación multiplataforma. Modo de rescate para casos en los cuales es imposible iniciar. Corregir errores de diseño de la versión anterior de GRUB, que no pueden resolverse debido a compatibilidad inversa, por ejemplo el numerado de las particiones PROCESO DE INICIO DE GRUB 1 [01] 1. El BIOS busca un dispositivo de inicio, como el disco duro, y lee el MBR del disco (Master Boot Record, los primeros 512 bytes del disco duro, mira últimos 2 bytes para verificar si el MBR), para pasarle el control. 2. El MBR contiene la fase 1 de GRUB. Como el MBR es pequeño (512 bytes), la fase 1 sólo carga la siguiente fase del GRUB, ubicado físicamente en cualquier parte del disco duro. La fase 1 puede cargar ya sea la fase 1.5 o directamente la etapa 2. 3. La fase 1.5 GRUB está ubicada en los siguientes 30 kilobytes del disco duro ( “DOS compact Space” inmediatamente después de la MBR). La fase 1.5 carga la fase 2. 4. La fase 2 GRUB recibe el control, y presenta al usuario el menú de inicio de GRUB. Etapa contiene la mayor parte de la lógica de GRUB. Se carga el archivo menu.lst y ejecuta las instrucciones, por lo general proporciona un menú para el usuario. 5. GRUB carga el kernel seleccionado por el usuario en la memoria y le pasa el control. GRUB PROCESO DE INICIO DE GRUB 2 [03] La estructura de GRUB ha cambiado un poco con la versión 2. En lugar de la etapa 1, etapa de 1,5 y la fase 2 tiene una colección de módulos que se pueden combinar de diferentes maneras. Para reflejar la funciónalidad original de las etapas del GRUB como se describe anteriormente, se tiene por ejemplo: stage 1 = boot.img stage 1.5 = diskboot.img+kernel.img+pc.mod+ext2.mod (la imagen principal) stage 2 = normal.mod+_chain.mod El proceso de arranque del grub2 es más flexible y sería el siguiente: 1. El BIOS lee el MBR de un disco (mira últimos 2 bytes para verificar si MBR). 2. Inicia la ejecución de código del bootloader (boot.img). 8/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM 3. Esto carga el primer sector de la imagen principal (diskboot.img), cuya ubicación se guarda en un lugar determinado en el boot.img en el momento de la instalación de GRUB y por lo general apunta a la imagen principal situada en el “DOS compact Space” inmediatamente después de la MBR. Diskboot.img a su vez carga y ejecuta el resto de la imagen principal. 4. Estos módulos de la imagen principal buscan y cargan el normal.mod El normal.mod carga el archivo grub.cfg y ejecuta las sentencias, por lo general proporciona un menú para el usuario, etc. Diferencias entre GRUB y GRUB 2: 9/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM Objetivos SODIUM es un sistema operativo didáctico desarrollado por alumnos de la Materia. Hoy en día la instalación del mismo está en desarrollo y quizás muy pronta a concluirse e implementarse, por lo tanto es posible que SODIUM este conviviendo con otros sistemas operativos como Windows y Linux. Para los alumnos que necesiten o deseen ver su funciónamiento, esto puede ser un problema ya que los multibootloaders disponibles no lo reconocerían en el momento del booteo. Si bien ya existía un multibootloader desarrollado por alumnos de la materia que reconozca SODIUM, éste necesitaba algunas modificaciones y mejoras en su funciónamiento. Es por ello que como propuestas nos fijamos el objetivo de mejorarlo y agregarle funciónalidades como una instalación independiente del SODIUM, además encontrar la posibilidad de volver al estado anterior a su instalación, es decir, realizar un Backup del MBR. Dada la naturaleza de SODIUM de mejora continua nos propusimos desarrollar la mayor parte de lo implementado en lenguaje C, lo cual facilita futuras modificaciones. Además se implementaron estructuras y funciones para manejo de disco que pueden ser reutilizadas para otras aplicaciones dentro de SODIUM. Desarrollo El BUM es un bootloader que permite ejecutarse en modo Live y bootear los sistemas operativos encontrados en el disco primario (sólo es capaz de ver el disco marcado como primario). En ésta condición, permite instalarse de forma residente en la PC; pero para esto requiere crear una partición dedicada para él (ya se primaria como lógica). El propio BUM provee la funciónalidad necesaria para crear y borrar particiones. Instalación del MBUM Cuando se corre el BUM en modo LIVE este permite, entre otras funciones, la instalación del BUM de forma definitiva en el sistema. A continuación se resume el proceso de instalación: 1. Al iniciar tanto en modo LIVE con desde disco el BUM recorre el disco y genera la tabla de particiones del sistema. El comando instalar recorre la tabla de particiones y las lista dando la opción al usuario de elegir en que partición desea instalar el BUM. 2. Pregunta si se desea generar un Backup del MBR original del sistema en la partición elegida por el usuario. De ser así, lo copia en el segundo sector. 3. Lee el archivo BUM.bin (funciónalidades y estructuras del BUM) del diskette y lo copia en la partición a partir del cuarto sector de la partición. 4. Copia el archivo PBR.bin del diskette al primer sector de la partición. 5. Lee el archivo BUMMBR.bin del diskette (este contiene el MBR del BUM) y lo copia en el primer sector del disco. Antes de copiar el MBR le pega la tabla de particiones, la cual se obtiene del MBR original. 6. Por último cambia el tipo del partición a 0x12 (partición tipo BUM) 10/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM Estructura de la partición del BUM Como resultado de la instalación del BUM, la partición queda con una configuración como se muestra en la figura. A continuación se enumeran los archivos/sectores arriba mostrados: PBR BUM: contiene el código capaz de cargar el BUM.bin Backup MBR original: contiene una copia del MBR al momento de la instalación. Sector reservado para el archivo de configuración: de crearse un archivo de configuración, aquí se ubicara. Este archivo permite fijar el tiempo de la cuenta regresiva para el arranque, cambiar el sistema operativo por defecto y asignar etiquetas a los SOs. BUM.bin: segunda etapa del BUM. Es el BUM propiamente dicho. Al cedérsele la ejecución, se encarga de todas las funciones (buscar los SOs ejecutables, crear/borrar particiones, ejecutar algún sistema operativo, provee la consola, etc) Se deduce que esta partición no posee un sistema de archivos popular y estándar como FAT; queda para una futura mejora implementarlo. Funciónamiento del MBUM El BUM es un cargador de 2 etapas y media. El BIOS carga el MBR del disco (que corresponde al MBR copiado durante la instalación) en la posición 0x000:0x7C00 y le cede la ejecución. Éste recorre el disco en busca de la etapa 2 del BUM: busca un partición primaria o lógica del tipo BUM (0x12). Al encontrarla, carga su primer sector (PBR BUM) en 0x000:0x7C00 y le cede la ejecución. Éste repite la búsqueda anterior para encontrarse a sí mismo, carga el BUM.bin (que se encuentra 3 sectores más adelante) en la dirección 0x8000:0x0000 y posicióna la pila al final de este segmento (que crece hacia abajo). Luego le cede la ejecución. 11/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM Se eliminaron las referencias explicitas a memoria ganando mayor flexibilidad y aprovechamiento de la misma. La segunda etapa recorre el disco (MPT y EBRs de haber particiones extendidas) y crea la tabla de particiones del sistema y la tabla de particiones ejecutables (ambas definidas de un tamaño máximo en un define). Una vez creadas estas 2 tablas, busca en el archivo de configuración el sistema operativo que debe cargar por defecto. De no existir un archivo de configuración, toma la primera partición ejecutable, espera el tiempo indicado el archivo de configuración o el que tiene por defecto y ejecuta la partición indicada. Si no encuentra ninguna partición ejecutable, pasa a la consola. MBR Partición Primaria Extendida Partición Extendida Extendida Partición MBUM Extendida MBUM Partición Primaria AA55 En ésta versión del BUM, el criterio utilizado para decidir si una partición es ejecutable se indica a continuación (esto se realiza consultando el byte de tipo): Partición tipo SODIUM. Partición tipo BUM que tenga un backup del MBR (se fija la firma). Esto se realiza para permitir la ejecución del MBR anterior. IMPORTANTE: esto se realiza cediéndole la ejecución tal como está, con la MPT vieja, por lo que pueden aparecer inconsistencias en caso de haber formateado el disto después de realizar el backup. Partición tipo Windows marcada como activa (para entender por qué se pide que esté marcada como activa, ver sección Pendientes:Reconocer Windows sin que la partición esté marcada como activa) Como se ve, el BUM no permite que una partición tipo Linux sea ejecutable. Para entender el motivo, dirigirse a la sección Pendientes:Booteo directo de Linux. Sin embargo, se permite bootear Linux (o cualquier otro sistema operativo que haya estado instalado y booteando en la maquina al momento de la instalación del BUM, a través del backup del MBR). 12/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM Gestor de particiones Finalmente, mencionar que la consola provee una serie de facilidades, entre las que se encuentra un gestor de particiones que permite crear y borrar particiones primerias y lógicas. La explicación de su funciónamiento merecería un capítulo aparte. Confiamos que el código se encuentra lo suficientemente documentado (a través de doxygen) y autodocumentado como para permitir su comprensión. Pidiendo disculpas por el capítulo que vamos a deber y con el objetivo de alivianarlas un poco, comentamos rápidamente algunos detalles que creemos que pueden ayudar a su comprensión: Para su funciónamiento, copia la tabla de particiones creada para manipularla sin riesgo de afectar la actividad normal de BUM. El disco se puede ver como una tira de sectores. Las particiones son un invento de los programas/SOs. Ellos las crean y sólo ellos las entienden; por lo tanto, lo único que se hace es seguir la forma que implementó DOS originalmente (por cuestiones de compatibilidad) con todos sus aciertos y errores. La manipulación de particiones (crear, borrar, mover, etc) sólo consiste en escribir el número adecuado en el sector correcto siguiendo la estructura apropiada. El puntero a sí mismo del EBR está dado de forma relativa al comienzo de la partición lógica (o sea, el sector que nos encontramos leyendo). En cambio, el puntero a la partición siguiente se encuentra dado en forma relativa al comienzo de la partición extendida. A continuación de cada EBR se repite la región de compatibilidad de DOS que se observa a continuación del MBR (no se usa ningún sector hasta la siguiente pista). Para crear una partición, debe existir un espacio libre en el disco. Para su cálculo se buscan sectores libres (que superen un mínimo especificado) entre el fin y el inicio de particiones consecutivas y entre el fin e inicio del disco. Esto se realiza teniendo en cuenta las siguientes consideraciones: o Tanto las entradas de la MPT las particiones lógicas no tienen que estar en orden (por ejemplo, la primer entrada de la MPT puede apuntar a una partición posterior a la segunda así como una partición lógica puede encontrarse seguida de otra que se comienza en un sector menor). Es por esto que la tabla de particiones se ordena por sector de comienzo (ignorando las particiones extendidas). o El primer/último sector disponible de la primer/última partición lógica es el primer/último sector de la partición extendida en donde se encuentra. o El primer/último sector disponible de la primer/última partición primaria o extendida es el primer/último sector del disco rígido. Para ejemplificar este punto y el anterior, se incluye el siguiente gráfico. 13/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM o Los últimos 5104 sectores del disco no se utilizaron ya que DOS no los utiliza (y no reconoce bien las particiones creadas y se tienen en cuenta). Con el GParted se observó una limitación semejante, pero de menor cantidad de sectores. No se incluyó la posibilidad de redimensionar por el peligro que supone cambiar el tamaño de la partición sin conocer el sistema de archivos (se desconoce el último sector utilizado). Se permite elegir el tamaño de la partición a crear, pero siempre empezará al principio del “hueco” encontrado, dejando el espacio restante al final. Esperemos que con estas pequeñas consideraciones sea suficiente para “echar un poco de luz” sobre esta funciónalidad del BUM. Volvemos a pedir disculpas por la falta de una explicación más profunda. Restricciones Para la instalación del MBUM es necesario contar con las extensiones del BIOS, las cuales se utilizarán para leer y escribir en disco. Se agregó una validación que avisa de la imposibilidad de utilizar el bootloader en caso de no tenerlas. Conclusiones Una vez desarrollado el mBum y viéndolo funciónar, observamos que hemos llegado a una forma sencilla de instalar un multibootloader capaz de reconocer, por defecto, SODIUM sin necesidad de realizar modificaciones al SO. Permite la carga de varios Sistemas Operativos facilitando de esta manera la tarea de prueba de SODIUM en entornos reales mientras se sigue desarrollando, dejando a la PC completamente utilizable para realizar otras tareas. El hecho de que gran parte este programado en C va a facilitar futuras modificaciones. Además durante el desarrollo se crearon varias estructuras y funciones para manejo de disco que pueden ser fácilmente aplicadas a SODIUM, un ejemplo de ello es el comando fdisk que se implementó. Pendientes: Booteo directo de Linux. En este momento, el BUM no es capaz de bootear de forma directa a Linux debido a ciertas particularidades del mismo que obligan a añadir inteligencia al bootloader. Tanto en Windows como en SODIUM, el BUM carga en 0x0000:0x7C00 el primer sector de la partición donde se encuentran instalados y le cede la ejecución. Esto no es posible en Linux. En este sistema operativo debemos buscar al kernel en el sistema de archivos para poder cargarlo en memoria y cederle la ejecución. Para esto es necesario, minimamente, ser capaces de identificar el sistema de archivos (información disponible en el byte de tipo de la entrada correspondiente en el MBR o EBR, según sea primaria o lógica) y, en función del mismo, buscar los archivos necesarios para cargar el sistema operativo. Basicamente, para que el BUM pueda bootear Linux en forma directa es necesario desarrollar funciones para leer y buscar dentro del árbol de subdirectorios para cada uno de los file system que puede utilizar Linux para su instalación. Entre los file system más comunes de Linux se encuentran ext2, ext3 y ext4 entre muchos otros. Cabe destacar que todas estas funciones deben realizarse utilizando los servicios de la BIOS ya que el BUM se ejecuta en modo real. 14/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM También es necesario investigar si existen diferencias para bootear las distintas distribuciones de Linux, el nombre cada archivo, etc. Reconocimiento de varios discos. Esta versión del BUM sólo trabaja con el disco configurado como primario en el BIOS. Se podría modificar para que sea capaz de leer y trabajar con todos los discos permitiendo tanto la instalación del BUM (aunque después sea necesario marcarlo como primario para que arranque una vez instalado) como el booteo de un sistema operativo en cualquiera de ellos. La modificación para realizar esta tarea no es excesivamente compleja, aunque requiere modificar muchas líneas de código. Reconocer Windows sin que la partición este marcada como activa. Básicamente, la pregunta podría generalizarse de la siguiente manera: “¿En una partición dada, hay un sistema operativo instalado?”. Algo que parece tan sencillo, no lo es. Esto se debe a que la única información que poseemos acerca del contenido de una partición (sin verificar dentro de ella, ya que esto depende de lo que haya ahí) es el byte de tipo de la entrada del MBR o EBR. Sin embargo, el valor es totalmente arbitrario y cada uno lo usa como quiere (no está regulada una correspondencia entre números y sistemas de archivos, sólo se “saben” usos conocidos de ciertos números (ver http://www.win.tue.nl/~aeb/partitions/partition_types-1.html)). Además, el tipo sólo identifica el sistema de archivos, pero no da información alguna sobre la existencia de un sistema operativo dentro. Por ejemplo: es habitual que todos tengamos una partición para Windows y otra para nuestros datos. En el caso de que ambas estén formateadas en NTFS, tendrán los mismos números (aunque en una haya un SO instalado y en la otra no). Como resumen, para identificar si existe un SO (tanto Windows como Linux) se debe buscar algún patrón que nos dé una pista sobre ello. En el caso de Windows se puede buscar algún archivo característico (si se sabe leer el sistema de archivos) o algún patrón que se repita en los primeros sectores. Por ejemplo, nosotros encontramos que los primeros caracteres del segundo sector de la partición donde se encuentra un gestor de arranque de Windows (que, en definitiva, es lo que nos interesa) corresponden al nombre del gestor correspondiente (NTLDR, BOOTMGR, etc). Sin embargo, esto no fue investigado lo suficiente como para asegurar que sea siempre así. En el caso de Linux, basta con buscar la existencia de un kernel (pero para esto debemos ser capaces de leer el sistema de archivos, al igual que para bootearlo). File system para la partición del BUM. Actualmente el BUM se instala en una partición de tipo BUM (0x12), la cual no tiene un file system. Los archivos que componen el BUM se copian en sectores definidos arbitrariamente por nosotros (como se mostró en la sección Estructura de la partición tipo BUM). Si bien esto no produce grandes inconvenientes, la existencia de un file system para esta partición le daría al BUM un grado mayor de flexibilidad. Además, permitiría cambiar el archivo de configuración actual del BUM por un archivo de texto plano que contenga la configuración para el BUM y que pueda ser modificado desde cualquier SO que pueda leer el file system del BUM, de manera similar al archivo menu.lst que posee el GRUB. Para poder implementar este cambio es necesario desarrollar un PBR para el BUM que pueda leer el file system elegido y funciones para el BUM que permitan leer y escribir en dicho file system. 15/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM Booteo desde pendrive. La idea principal de esta mejora es cambiar el dispositivo desde el que bootea el BUM. Como todos sabemos hace años que los disketes son obsoletos debido a su limitada capacidad de almacenamiento y a su corta vida útil. Hoy en día, la mayoría de las maquinas permiten bootear desde un pendrive y cada vez son menos las maquinas que cuentan con disquetera. Aún más, cada vez son menos los SO que dan soporte a ese medio de almacenamiento. Mientras se estaba desarrollando el BUM, otro de los proyectos en desarrollo consistía en investigar e implementar el booteo desde pendrive para SODIUM. El proceso para poder bootear el BUM debería ser muy similar y gran parte de lo desarrollado para el SODIUM debería poder utilizarse en el BUM sin grandes dificultades. 16/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM APENDICE A Organización de archivos El BUM se encuentra desarrollado por dos ramas diferentes. Por un lado la del BUM propiamente dicho (bajo el directorio bum) y por otro, una biblioteca de funciones (bajo el directorio libinit16) que proveen una API basada en los servicios del BIOS para realizar acciones como escribir en pantalla, leer del teclado, etc. Ambos proyectos son, a pesar de lo que pueda parecer, independientes. Se busca que la libinit16 provea una serie de servicios que sean utilizados por el BUM o cualquier otro proyecto que los necesite con sólo incluir la biblioteca compilada. Estructuras de datos utilizadas: stuCHS stuCHSExt stuDiskAddressPacket stuEntradaTablaParticion stuPartitionBootRecord stuComando stuEncabezadoConfig stuEntradaConfig Estructura que contiene la geometria del disco, si no estan las extensiones de la int 13h StuCHSExt Estructura que contiene la geometria del disco, que se utiliza con las extensiones de la int 13h Estructura utilizada para leer el disco utilizando las extensiones del BIOS Entrada Tabla Particion Estructura del MBR Estructura referente a la linea de comando StuEncabezadoConfig Estructura que constituye el encabezado del arch de config StuEntradaConfig Estructura que constituye una entrada en el arch de config stuCHS: unsigned char H (8 bits de H) unsigned char C_S (2 ultimos bits de C y los 6 de S) unsigned char C (Primeros 8 bits de C) stuDiskAddressPacket unsigned char Size unsigned char SinUso1 unsigned char CantidadSectores unsigned char SinUso2 unsigned int SegmentOffsetBuffer unsigned int SectorLBALow unsigned int SectorLBAHigh 17/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM stuPartitionBootRecord unsigned char BootFlag stuCHS SectorInicialParticionCHS unsigned char TipoParticion stuCHS UltimoSectorParticionCHS unsigned int SectorInicialParticionLBA unsigned int LongitudParticionLBA stuComando char comando [LONG_CMD_MAX] void(* ayuda )() void(* func )(int) Descripción del contenido de los subdirectorios del proyecto. A continuación se listan los subdirectorios con una breve descripción de cada uno. ./bum Se encuentran los archivos que implementan las funciónalidades del MBUM. . /bum/bs_instalador boot sector disquete para ejecutar el modo live . /bum/include/multiboot Contien las funciones principales, así como también, constantes y variables referentes al funciónamiento de la consola. Se encuentran los headers que declaran las distintas estructuras y funciónalidades provistas por el mbum. ./bum/mbr_hdd MBR que irá en el disco cuando se instale el MBUM. ./bum/pbr_hdd PBR que irá en el disco cuando se instale el MBUM. ./libInit16 Se encuentran distintas estructuras y funciónalidades provistas para el manejo de servicios del BIOS. Variables, constantes y funciones definidas en algunos de los archivos intervinientes A continuación se listan los archivos con sus correspondientes variables, constantes y funciones significativas con una breve descripción de cada uno. Directorio /bum/ Archivo: bum.c 18/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM Contiene el proceso principal del MBUM. Se cargan las tablas de comandos, se crea la lista de particiones ejecutables y se inicializa el archivo de configuración. Dependencia entre archivos: Relación entre funciones: Funciones: vfnInicializarTodo: En esta función se encuentran las inicializaciones de todas las variables globales. vfnCrearTablaDeParticiones: Crea la tabla de particiones ejecutables. Archivo: bum.h Contiene las constantes, variables globales, estructuras y funciones principales. Archivo: config.c Contiene el codigo de las funciones declaradas en bum.h Se compila en 16 bits (modo real) Relación de archivos: Relación de funciones: 19/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM Funciones: ifnLeerArchivoConfig: Función que provee la funciónalidad de hacer lectura de la entrada del archivo de configuración. Parámetros de entrada: o int iPos o stuEntradaConfig *pstuEntrada Devuelve: Int ifnLeerEncabezado: Función que provee la funciónalidad de hacer LECTURA del encabezado del archivo de configuración Parámetros de entrada: o stuEncabezadoConfig *pstuEncabezado Devuelve: Int ifnEscribirEncabezado : Función que provee la funciónalidad de hacer la escritura del encabezado del archivo de configuración Parámetros de entrada: o stuEncabezadoConfig *pstuEncabezado Devuelve: Int fnEscribirArchivoConfig : Función que provee la funciónalidad de hacer LECTURA del encabezado del archivo de configuración Parámetros de entrada: o int iPos o stuEntradaConfig *pstuEntrada Devuelve: Int Archivo: comandos.c Contiene los comandos que permite ejecutar el MBUM. Dependencia entre archivos: Dependencia entre funciones: 20/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM 21/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM 22/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM 23/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM 24/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM Funciones: vfnComandosCls: Función que limpia la pantalla. vfnLlenarTablasComandos: Función que Obtiene el parámetro cNumParam-esimo que se encuentra en el comando ejecutado Se asume que el primer parámetro es el parámetro. vfnAyudaArchc: Función que lista la ayuda. vfnAyudaComs: Función que llama a la ayuda del comando ingresado por pantalla. vfnComandoComs: Función que llama al comando ingresado por pantalla. vfnAyudaEjecutar: Función que lista la ayuda del comando Ejecutar. vfnAyudaListar: Función que lista la ayuda del comando Listar. vfnAyudaCls: Función que lista la ayuda del comando cls. vfnAyudaInstalar: Función que lista la ayuda del comando instalar. vfnAyudaDesinstalar: Función que lista la ayuda del comando Desinstalar. vfnAyudaRepararMBR: Función que lista la ayuda del comando repararmbr. vfnAyudaGestorParticiones: Función que lista la ayuda sobre el comando de particiones. vfnComandoAyuda: Función que lista la ayuda. vfnComandoAyuda: Función que Intenta ejecutar el comando escrito por el usuario. cfnComandoEjecutar: Función que Ejecuta la partición pasada como parámetro. Devuelve: Char vfnComandoArchc: Función destinada para el arch de config. vfnComandoListar: Función que Lista y muestra en pantalla la particiones ejecutables encontradas. vfnComandoInstalar: Función que Ejecuta el instalador del BUM. vfnComandoDesinstalar: Función que Ejecuta el Desinstalador del BUM. vfnComandoRepararMBR: Función que copia el archivo binario del MBR del disket en el MBR del disco. 25/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM vfnObtenerParamNum: Función que Obtiene el parámetro cNumParam-esimo que se encuentra en el comando ejecutado Se asume que el primer parámetro es el parámetro 0. Parámetros de entrada o cNumParam variable que contiene el comando ejecutado o iValor variable puentero al comando ejecutado Devuelve: 0 si encuentra el espacio que buscaba, de lo contrario devuelve 1 vfnObtenerNombreComando: Función que obtiene el nombre del comando que se desea ejecutar Se asume que el nombre del comando es la cadena que termina con el primer espacio en blanco. Parámetros de entrada: o strResultado contiene la cadena de la linea de comandos Devuelve: Devuelve 1 por defecto cfnObtenerParamStr: Función que el parámetro cNumParam-esimo que se encuentra en el comando ejecutado Se asume que el primer parámetro es el parámetro 0. Parámetros de entrada: o cNumParam parámetro asociado al comando ejecutado o strResultado contiene la cadena de la linea de comandos Devuelve: Char vfnComandoGestorParticiones: Administrador de particiones. cPedirConfirmacion: Pide confirmación para realizar una acción mostrando la leyenda pasada por parámetro. Parámetros de entrada: o char *leyenda (leyenda a ser mostrada.) Devuelve: Char (1 si en caso de aceptar, 0 si no acepto.) Archivo: consola.c Contiene las funciones que manejan la consola del MBUM. Relación entre archivos: Relación entre funciones: 26/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM Funciones: cfnMostrarMenu: Función que muestra el menú, con las particiones ubicadas en el disco. Parámetros de entrada: o ucTipoPart indica el tipo de partición o strEtiqueta indica si existe alguna partición o ucTimeout timeout de respuesta Devuelve: Char Directorio / libInit16/ Archivo: bios.c 27/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM Relación entre archivos: Relación entre funciones: 28/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM 29/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM Funciones ifnLeerSectorLBA : Si están las extensiones se leen con LBA, si no están, lee con CHS. Parámetros de entrada: o buf es una region de 512 bytes para guardar el sector buscado o uiLBA es el numero LBA del sector a leer Devuelve: Si pudo leer devuelve un 1, si no pudo un 0 ifnLeerSectorCHS : Lee un sector con la direccion CHS. Parámetros de entrada: o char * buf, es una region de 512 bytes para guardar el sector buscado o stuCHS * stu_CHS, es la direccion CHS del sector a leer Devuelve: Si pudo leer devuelve un 1, si no pudo un 0 ifnEscribirSectorLBA : Escribe en un sector 512 bytes. Parámetros de entrada: o char *buf, unsigned int uiLBA Devuelve: Int vfnInicializarInt13 : Verifica que estén disponibles las extensiones y obtiene la geometría del disco. vfnVerificarExtensionesInt13 : variable global cExtPresentes. vfnObtenerGeometriaCHS : Si están las extensiones la guarda en la variable global stuCHSGeomtriaDiscoExt. Si no están las extensiones la guarda en la variable global stuCHSGeomtriaDisco. Se utiliza para funciónar con LBA Pone el resultado en la Parámetros de entrada: o cEexten dice si estan o no las extensiones Devuelve: Si estan vale 1, si no vale 0 ifnConvertirCHSALBAExt : Convierte una direccion CHS a una LBA. Parámetros de entrada: o *puiLBADestino es la direccion en donde se guardara la direccion LBA o *pstuCHSExtOrigen es la direccion CHS Devuelve: 1 si pudo realizar la conversion y 0 si no pudo 30/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM ifnConvertirLBAACHS : Esta función convierte de LBA a CHS, por si las extensiones del BIOS no se encuentran presentes. Parámetros de entrada: o *pstuCHSDestino es la stuCHS en donde se va guardar el resultado, si se pudo hacer la conversion o uiLBAOrigen es la direccion LBA origen. Devuelve: 1 si pudo hacer la conversion y 0 si no pudo cfnDelay : Función que define el delay utilizado. Parámetros de entrada: o iSegs parámetro que define la cantidad de segundos del delay Devuelve: Si pudo leer el cTiempo, devuelve 1, sino, devuelve 0. Tambien devuelve 0 si iSegs esta mal (<0) Archivo: consola.c Relación entre archivos: Relación entre funciones: 31/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM 32/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM 33/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM 34/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM Funciones vfnImprimirAVentana : Función que posee la misma funciónalidad que 'printf', en el sentido en que usa las coordenadas actuales para imprimir el string. Parámetros de entrada: o *str es la cadena a imprimir o cCarNum variable que indica si lo que se imprime es caracter o numero vfnImprimirStr : La función imprime un Str en la iFila y iCol especificada. Si paso -1 a iFila y columna, imprime según las coords actuales. Se imprimirá el Str mientras no se encuentre un o mientras la cantidad de caracteres impresos sea menor a lo especificado en el parámetro siCant. Parámetros de entrada: 35/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM o *str cadena a imprimir o iFila fila a imprimir o iCol columna a imprimir o cCarNum Imprime el string en forma de caracteres o numeros hexadecimales segun se setee 1 o 0 en cCarNum, respectivamente. o siCant cantidad maxima de caracteres a imprimir vfnEscribirCar: Función que permite escribir los caracteres en la línea de comandos. Parámetros de entrada: o iCar se pasa por parámetro para definir el caracter que quiero imprimir o iPos se pasa por parámetro para indicar la posición en la pantalla vfnEscribirCarColor: Función que permite escribir los caracteres en la línea de comandos. Parámetros de entrada: o iCar se pasa por parámetro para definir el caracter que quiero imprimir o iPos se pasa por parámetro para indicar la posición en la pantalla o cColor se pasa por parámetro para indicar el color a imprimir en la pantalla cfnLeerMemVideo: Función que permite leer la memoria del video. Parámetros de entrada: o uiOffset es el parámetro que se pasa a la función para indicar el desplazamiento de acceso a la posición de memoria Devuelve: Char cfnEscribirMemVideo: Función que permite escribir la memoria del video. Parámetros de entrada: o cByte el byte a escribir o uiOffset es el parámetro que se pasa a la función para indicar el desplazamiento de acceso a la posición de memoria cfnHexToChar: Función que traduce un Hexa a Char. Parámetros de entrada: o cNum parámetro a traducir Devuelve: Char cfnCls:Función que limpia la pantalla. Devuelve: Char vfnSubirFila: Función que sube una iFila lo que hay en pantalla. cfnTeclaPresionada: Función que me indica si se presiona una tecla. Devuelve: Char cfnLeerTecla: Función que me permite leer la cTecla que se presiono. Devuelve: Char cfnImprimirTecla: Función que me permite Imprimir lo que haya ingresado el usuario. Parámetros de entrada: o cModo es un parámetro que responde al modo de impresion de la tecla 36/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM o cTeclaP tecla a imprimir, si se pasa 0 se lee la tecla del bufer. Devuelve: Char (la tecla que imprimio.) vfnBorrarCaracter: Función que me permite borrar los caracteres de la línea de comandos, retrocediendo las coordenadas; si las mismas valen cero, no se borra nada. Solo se permite borrar hasta que se llega al prompt. vfnNuevaLinea: Función que me permite obtener una nueva línea. vfnTabulador: Función que provee la funciónalidad de un tabulador que permite avanzar hasta el siguiente tab stop. vfnActualizarCoords: Función que actualiza las coordenadas. vfnActualizarCursor: Función que actualiza las coordenadas del cursor. cfnSetPromptPos: Función que permite setear la posición del prompt. Parámetros de entrada: o iFila parámetro correspondiente a la fila de la coordenada o Columna parámetro correspondiente a la columna de la coordenada Devuelve: si se le pasa un cualquiera devuelve cero, de lo contrario uno vfnImpNum : Función que imprime un numera en la ubicación correspondiente. Parámetros de entrada: o unsigned long int uliDir o int iFila o int iCol ifnLeerStr : Función que lee un string desde el teclado mientras lo ingresado sea menor a iTamMax y mientras no se encuentre un caracter igual a cStop. Parámetros de entrada: o *strDestino variable puntero que o iTamMaxtamanio maximo del caracter ingresado o cStop indica el tamanio que puedo ingresar como comando Devuelve: Devuelve cero si el tamanio maximo es menor a cero, de lo contrario devuelve iCont, que es el tamnio del string ingresado Archivo: floppy.c Relación entre archivos: Relación entre funciones: 37/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM Funciones ifnLeerDeDiskette : lee n sectores del disket Parámetros de entrada: o cantSect cantidad de sectores a leer o sectInicial sector del diskete apartir del cual se comienza a leer o *buf region de memoria donde se almacenan los sectores leidos Devuelve: 0 si puedo leer, 1 si ocurrio algun error ifnCargarDirRaiz : lee el directorio raíz y lo guarda en la variable pasada por parameto Devuelve: Int - 0 si pudo leer, 1 si ocurrio algun error. ifnCargarFatDiskette : carga la posición en pcCargaFat Devuelve: Int - 0 si pudo leer, 1 si ocurrio algun error. ifnGrabarArchivoADisco : lee "archivo" del disket y lo graba en el disco Parámetros de entrada: 38/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM o entrada nombre del archivo a copiar en formato 8+3 (8 caracteres para el nombre y 3 de extencion) ejemplo (BUM BIN) o sectorInicial sector del disco en LBa a partir del cual de quiere grabar el archivo. Devuelve: 1 si no ocurre ningun error, -1 si no encuentra el archivo o no puede leerlo, -2 si no puede grabarlo. uifnCalcularSecSig : busca en al fat el siguiente sector Parámetros de entrada: o sector actual Devuelve: unsigned int (siguiente sector a leer o finDeArchivo (0x0FFF).) ifnBuscarEntradaDirRaiz : busca una entrada en el directorio Raíz Parámetros de entrada: o entrada nombre del archivo buscado en formato 8+3 Devuelve: int - nro de entrada si la encuentra o -1 si no la encuentra uifnBuscarPrimerSector : busca en la entrada del directorio raíz el primer sector del archivo Parámetros de entrada: o nroEntrada entrada en el directorio raiz correspondiente al archivo que se quiere leer Devuelve: unsigned int (sector inicial del archivo) Archivo: mem.c Relación entre archivos: Relación entre funciones: 39/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM Funciones ifnDireccionAbsoluta : Calcula la direccion absoluta (esto es, adicionarle el DS) del puntero que se le pasa como parámetro. Parámetros de entrada: o *pvVariable variable de la que quiero averiguar su direccion absoluta Devuelve: unsigned int (Direccion absoluta de la variable que se pasa por parámetro) ifnCopiarADirAbs: Esta función copia memoria. Parámetros de entrada: o *ucpDestino puntero al destino dirDestino Direccion absoluta de memoria uiTamanio cantidad de bytes a copiar Devuelve: int (Siempre 1) Archivo: part.c Relación entre archivos: Relación entre funciones: 40/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM 41/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM 42/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM Funciones pstufnNuevaParticion : Función que me permite alocar memoria para el array particiones. Devuelve: Devuelve un puntero a la nueva entrada. 0 si no hay mas lugar. pstufnNuevaParticionEjec : Función que me permite alocar memoria para el array de particiones ejecutables. Devuelve: Devuelve un puntero a la nueva entrada. 0 si no hay mas lugar. cfnTodosLosCamposEnCero : Verifica si una entrada de la tabla tiene todos los campos en cero. Parámetros de entrada: o *entrada entrada a analizar Devuelve: Si esta toda en cero: 1, si no: 0 vfnPonerTodosLosCamposEnCero : pone todos los campos de una entrada de la tabla en cero. Parámetros de entrada: o *entrada entrada a limpiar vfnCederEjecucion : Cede la ejecución al PBR apuntado por el parámetro pstuEntrada. Parámetros de entrada: o *entrada que contiene la direccion del PBR al que se le cedera la ejecucion ifnExplorarExtendida : Explora la partición extendida recibida por parámetro en busca de particiones lógicas y las agrega a la tabla de particiones. Parámetros de entrada: 43/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM o *pstuEntrada es la entrada de la particion extendida. Devuelve: int (1 si fue exitoso, 0 si hubo error (de lectura de disco o EBRs no firmados)) vfnHacerSalto : vfnCopiarPartTable : Copia la tabla de particiones del MBR origen al MBR destino. Hace un salto a 0x0000:0x7C00. Parámetros de entrada: o stuPartitionBootRecord * MBR original stuPartitionBootRecord * MBR destido vfnCrearTablaDeParticiones : Genera la tabla de particiones del sistema. Guarda las entradas de todas las particiones primarias y lógicas en la tabla de particiones. La tabla de particiones tiene cCantParticiones Particiones y es apuntada por la Var. gloabal astuTablaParticiones. vfnListarTablaDeParticiones : Función que recorre las cCantParticiones (Var. global) de la tabla de particiones apuntada por la Var. global astuTablaParticiones y la lista por pantalla. Muestra el tipo de partición y su tamaño. cfnCalcularEspacioNoUsado : crea una tabla de espacios no asignado en el disco de tamaño mayor a una constante definida en la función. Parámetros de entrada: o pstuTablaHuecos puntero donde se almacenara la tabla de espacios libres. Devuelve: char (devuelve la cantidad de espacios libres encontrados (cantidad de entradas en la tabla).) vfnCrearParticionPrimaria : crea una partición Parámetros de entrada: o particion es un puntero a una estructura que contiene los datos de la particion a crear. vfnCrearParticionLogica : crea una partición lógica Parámetros de entrada: o particion es un puntero a una estructura que contiene los datos de la particion a crear. o numExtendida es la entrada en la tabla de particiones que corresponde a la particion extendida dentro de la cual se creara la nueva particion logica. *pstuExtendida vfnBorrarParticionPrimaria: borra una partición Parámetros de entrada: o stuParticionABorrar entrada de la tabla astuTablaParticiones a borrar. vfnBorrarParticionLogica : borra una partición lógica Parámetros de entrada: o stuParticionABorrar entrada de la tabla astuTablaParticiones a borrar pcfnObtenerDescTipoParticion : devuelve una descripción relacionada al tipo de partición. Parámetros de entrada: o tipo numero que identifica el tipo de particion. Devuelve: puntero a un string que contiene la descripcion del tipo. 44/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM ifnSonEntradasIguales : verifica si 2 entradas son iguales. Compara campo por campo y verifica que sean iguales, si algún campo es distinto las entradas son distintas Parámetros de entrada: o punteros a la entradas a comparar Devuelve: int (1 si son iguales, 0 si son distintas) Archivo: puertos.c Relación entre funciones: Funciones outb: función que escribe un cByte en un puerto determinado (implementada en assembler) Parámetros de entrada: o iValor parámetro a escribir en el puerto puerto donde escribir Archivo: string.c Relación entre archivos: Relación entre funciones: 45/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM Funciones ifnCopiarMemoria : Esta función copia memoria. Parámetros de entrada: o *ucpDestino puntero al destino o *ucpOrigen puntero al origen o uiTamanio cantidad de bytes a copiar Devuelve: int (Siempre 1) ifnAtoI : Convierte un string ASCII a Integer. Parámetros de entrada: o char *strA o int iBase Devuelve: Devuelve el entero correspondiente cfnStrCat : Concatena el origen con destino y el resultado queda en destino. Parámetros de entrada: o *dest cadena destino o *org cadena origen Devuelve: char (siempre 1) ifnStrLen : Devuelve la longitud de un string. Parámetros de entrada: o *str,es el string que se va a analizar Devuelve: int (Longitud del string que se mando por parámetro) cfnStrIguales: Verifica la igualdad de dos strings. Parámetros de entrada: o *a string 1 o *b string 2 Devuelve: Si son iguales: 1, si son distintos: 0 pcFnIntToString : Convierte un entero a string en la base especificada. Parámetros de entrada: o iNum el numero a convertir o pcStr puntero a char que apunta a la region de memoria donde se guardara el numero convertido. IMPORTANTE: el usuario de la función se debe encargar de la reserva de memoria necesaria para convertir el numero. o iBase base del numero convertido. Debe estar entre 2 y 16 (inclusive). La función NO verifica limites. Devuelve: char * (puntero al string convertido. Tiene el mismo valor que pcStr.) 46/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM Glosario BIOS: Basic Input Output System BUM: ver MBUM CHS: Cilinder-Head-Sector EBR: Extended Boot Record GRUB: GRand Unified Bootloader LBA: Logical Bolck Address MBC: Master Boot Code MBR: Master Boot Record MBUM: MultiBootloader de la Universidad de La Matanza MPT: Master Partition Table PBR: Partition Boot Record SO: Sistema Operativo SODIUM: Sistema Operativo del Departamento de Ingeniería de la Universidad de La Matanza 47/48 SISTEMAS OPERATIVOS-UNLAM 2010 – DOCUMENTACIÓN DEL MBUM Bibliografía: [01] Bootloaders – an introduction Barry Nauta. December 3, 2008. [02] the GNU GRUB manual Version 0.97. May 8, 2005 Internet [03] Details of GRUB on the PC (2005) http://www.pixelbeat.org/docs/disk/ [04] SUSE Documentación de LINUX. Capítulo 29. Cargador de arranque / 29.3. Arranque con GRUB (Novell Inc.) http://www.mafuso.net/susemanual//index.html [05] Sitio Oficial de Grub, http://www.gnu.org/software/grub/ [06] Manual de Grub desde GNU, http://www.gnu.org/software/grub/manual/html_node/ [07] http://www.zator.com/Hardware/H8_1_2c.htm [08] http://mirror.href.com/thestarman/asm/mbr/index.html 48/48
