Programando el kernel

Como ya se ha comentado, programar un módulo es programar una parte del kernel. Intentaré explicar las diferencias fundamentales que hay entre programar un kernel y programar una aplicación de usuario. Lee atentamente esta sección y asegúrate de entender todos sus puntos, si no entiendes algo, es que todavía no estás preparado para programar un módulo.

• Cuando estamos programando una aplicación en espacio de usuario, y por un error de programación pretendemos escribir en una zona de memoria que no es nuestra (por ejemplo, cuando se nos va un puntero de rango), el kernel no nos deja y nos devuelve el tan familiar mensaje de segmentation fault.

  Cuando estamos programando en el kernel y se nos va un puntero de rango, no hay nadie para avisarnos, escribiremos donde no queríamos, probablemente estropeando lo que allí hubiese antes y generando lo que normalmente es un pequeño desastre que hace que se caiga todo el sistema.

  Pronto comprobaremos que cuando un programador no experimentado pretende incluir en el kernel su propio código (típicamente lleno de errores), aquello empieza a parecerse mucho más a Windows que a Linux, con continuas caídas del sistema, pérdidas de datos y demás catástrofes con fondo azul y letras blancas.

  Con esto lo que pretendo decir es que el código de nuestros módulos ha de ser MUY robusto, o perderemos todo nuestro tiempo reinicializando nuestro ordenador.

• Cuando programamos una aplicación de usuario y queremos digamos, imprimir algo por pantalla, usaremos la función printf() de nuestra querida librería stdio.h.

  Cuando programemos en el kernel, no podemos utilizar ninguna función de las librerías que utilizamos normalmente, el kernel ha de ser capaz de subsistir sin dichas librerías, por lo que no puede depender de ellas. Es por ello que el kernel se define sus propias librerías, que tendrán funciones parecidas-pero-no-exactamente-iguales a las librerías habituales que conocemos.

  A lo largo de este capítulo iremos introduciendo al lector en todas aquellas funciones que el kernel nos proporciona. Al igual que en el caso de las librerías normales de programación, el kernel tiene unos archivos de cabeceras para sus librerías, que tendremos que incluir (#include) en nuestro módulo.

• Aunque nosotros no vamos a implementar la tarea principal de un driver (manejar un hardware), si que vamos a implementar todo aquello que le acompaña, es decir la envoltura que le dice al kernel que funcionalidad ofrece el driver, que memoria necesita, que servicios presta...

  Durante la lectura de este capítulo se irá descubriendo como se implementan todo este tipo de cosas.

• Cuando estamos programando un módulo, este no es un programa, es decir no tiene ninguna función main() que se ejecute al ser lanzado. En realidad nuestro módulo va a parecerse más a una librería; en él definiremos una serie de funciones, informaremos al kernel de cuales son y que argumentos necesitan. Cuando el kernel necesite utilizar una de nuestras funciones mirará en nuestro módulo y usará la porción de él que necesite.

  Por eso cuando vayamos a probar nuestro módulo tendremos que hacerlo a través del kernel. Por ejemplo si estuviésemos implementando un driver para un disquetera, para probarlo, insertaríamos el módulo y montaríamos la disquetera, con eso el kernel ya ha tenido que acceder a unas cuantas de las funciones definidas en el módulo. Podríamos seguir haciendo pruebas a base de copiar ficheros a la disquetera, borrarlos, etc. Durante todo este proceso el kernel estará usando las funciones de lectura y escritura definidas por nosotros mismos en el módulo.

  Para probar módulos es muy recomendable generar unos cuantos scripts de pruebas que inserten el módulo y ejecuten comandos de forma que el kernel tenga que usar las funciones de nuestro módulo. De esta manera podremos ahorrarnos mucho tiempo y además podremos concentrarnos en generar un buen espacio de pruebas para nuestro módulo.

  Volviendo al caso del driver de disquetera, el script de pruebas podría montar la disquetera, copiar unos ficheros al disquete, borrar unos cuantos, cambiarle los permisos para solo lectura, comprobar que ya no puede borrar ninguno de los ficheros, comprimir alguno de esos ficheros, ejecutar alguno de esos ficheros que sean ejecutables, formatear el disquete, etc.

  Recuerda que el profesor va ha hacer lo mismo cuando te corrija las prácticas, por lo que canto más probado esté tu módulo mejor será tu nota^4.1.