Administracion Del Kernel

T e c s u p V i r t u @ ll

E s t r u c t u r a d e l K e r n e l

Copyright © 2010 por TECSUP

Estructura del Kernel

Tecsup

INDICE 1. 2. 3. 4. 5.

6. 7. 8.

9. 10. 11. 12. 13.

Introducción ............................................ ................................................................... .................................... ............. 3 Objetivos ......................................... ............................................................... ............................................ ...................... 3 El Kernel ......................................... ............................................................... ............................................ ...................... 3 Abstracción ............................................. .................................................................... .................................... ............. 4 Composición ........................................... .................................................................. .................................... ............. 4 5.1. Programador de Procesos ....................... .............................................. ......................... .. 5 5.2. Administrador de Memoria ............................... ............................................. .............. 7 5.3. Sistemas de Archivos Virtual .......................................... .......................................... 8 5.4. Inter-Process Comunication .............................. .......................................... ............ 11 5.5. Network Interface .......................................... .......................................................... ................ 12 MODULOS ........................................................... ............................................................................... .................... 15 6.1. Comandos........................................... .................................................................. ........................... .... 15 Numeración del Kernel .......................... ................................................ .................................. ............ 16 Actualización del Kernel ........................................... ........................................................... ................ 17 8.1. Preparación de la actualización ..................................... ..................................... 17 8.2. Paquetes del Kernel ............................................ ....................................................... ........... 18 8.3. Descarga ............................................................ ........................................................................ ............ 19 8.4. Realizando la actualización por RPM ........................... ........................... 20 8.5. Verificación de la imagen de disco RAM inicial .......... 21 8.6. Configuración del gestor de arranque ........................... ........................... 21 Actualización con las fuentes del Kernel .................................. .................................. 24 9.1. Compilar el kernel ......................................... ......................................................... ................ 24 Módulos del kernel ............................................. .................................................................... ....................... 26 Utilidades del módulo del kernel .......................................... .............................................. .... 26 BIBLIOGRAFIA..................................... ........................................................... .................................. ............ 29 Bibliografía ............................................. .................................................................... .................................. ........... 29

Página 2


Tecsup

Estructura del Kernel ”

“

1. Introducción Una de los pilares de la estructura del sistema Operativo Linux es el Kernel. El Kernel es el gestor del software con el hardware. Mostraremos un panorama de esta compleja sección con la intención de familiarizarnos con la estructura y los términos técnicos. 2. Objetivos Analizar la estructura del Kernel. Describir las funciones que usan en la comunicación del Kernel. 3. El Kernel Es parte de la estructura de un Sistema Operativo. La estructura de un Sistema Operativo está compuesto de:

SISTEMA OPERATIVO

PROGRAMAS USUARIO SERVICIOS KERNEL CONTROLADORES DE HARDWARE

Controladores de Hardware Un sistema está compuesto por piezas de hardware, como CPU, memoria, discos duros y dispositivos de red. Kernel Es el área principal de interés de este documento. Servicios del Sistema Operativo Estas son consideradas parte del sistema operativo, como un Administrador de Ventanas o Shells. Además, incluye la plataforma de programación (API) del Kernel (compilador y librerías) “El Kernel es un

Programas de Usuario Depende en realidad del uso que se le dé a la máquina. Por ejemplo, una planilla de cálculo.

programa que es la interface entre el Hardware y los programas de aplicaciones”

Página 3


Tecsup

4. Abstracción El kernel de Linux presenta "una máquina virtual para la ejecución de programas de usuario". Los procesos están escritos de manera de NO conocer la arquitectura final en la cual van a ejecutarse, ya que el Kernel posee una capa de abstracción. Es decir, el Kernel construye una interface virtual consistente independiente de la arquitectura o hardware en que corra, de manera transparente.

Además esta abstracción permite que cada proceso crea que es el único que está corriendo en la máquina, con uso exclusivo de memoria o de otros recursos de hardware. 5. Composición El kernel está compuesto por cinco subsistemas: Process Scheduler o Programador de Procesos Memory Manager o Administrador de Memoria Virtual File System o Sistema de Archivos Virtual Network Interface o Interfaz de Red Inter-Process Comunication o Comunicacion Entre Procesos Estos componentes son independientes entre sí.

PROGRAMADOR PROCESOS

COMUNICACIÓN ENTRE PROCESOS

ADMINISTRADOR MEMORIA

KERNEL

INTERFAZ DE RED

Página 4

SISTEMA DE ARCHIVOS


Tecsup

5.1.

Programador de Procesos

PC o Process Scheduler (Programador de Procesos) es en realidad el corazón del Sistema Operativo. Sus responsabilidades son: Permitirle a los procesos crear nuevas copias de sí mismos (forking) Determinar qué proceso tendrá acceso a la CPU Recibir interrupciones y desviarlas hacia el subsistema respectivo Enviar mensajes a los procesos de usuario Manejar el reloj de Hardware (Hardware Timer) Liberar recursos cuando un programa los haya desocupado. El Process Scheduler también soporta módulos cargados dinámicamente. Una de las funcionabilidades más

Página 5

“Toda operación

que se realiza en el Sistema Operativo es un proceso”


Tecsup

importantes de esto último son el Virtual File System y Network Interface. También provee dos interfaces. Uno, provee una interface de llamada a sistema limitada que los procesos pueden llamar. Dos, provee una interface para el resto del espacio del Kernel. En tiempo de booteo, Linux posee sólo un proceso, init(), que a su vez realiza copias de sí mismo a través de llamadas fork(). Cuando un proceso termina, ejecuta la llamada a _exit(). Acerca del timer, Linux maneja un timer interno que se inicia cada 10 milisegundos. Esto permite que los procesos se reasignen (Scheduling) cada 10 ms. Esta unidad se llama "clock tick" que sirve para medir la cantidad de ticks que un proceso en particular puede continuar ejecutándose sin forzar su reasignación. Cada proceso se asigna con un identificador único, llamado Process ID o pid, que es asignado a la lista de procesos o tabla de procesos. Finalmente, una estructura de módulos es usada para representar los módulos cargados en tiempo de ejecución. Esta estructura posee campos que son usados para implementar una lista de estructura de módulos. Es decir, un campo que apunta a la tabla de símbolos de los módulos y otro con el nombre del módulo.

VISUALIZANDO LOS PROCESOS

Si usted quiere ver todos los procesos corriendo en el sistema y no solamente los iniciados por usted. Usted puede utilizar la opción –A o la opción -e: ps –A –A # ps

PID TTY TIME CMD 1? 00:00:07 init 2? 00:00:00 kflushd 3? 00:00:02 kupdate . . . 372 ? 00:00:00 klogd

Página 6


Tecsup

5.2.

Administrador de Memoria

El Memory Manager o administrador de memoria permite lo siguiente: Gran espacio de direcciones : Los programas pueden requerir más memoria que la que físicamente existe Protección: La memoria asignada un proceso es privada para tal. Mapas de Memoria : Se puede mapear un archivo dentro de un área de memoria virtual y acceder al archivo como si fuera memoria Acceso Limpio a la Memoria Física : el MM asegura que los procesos puedan usar transparentemente todos los recursos de la máquina, asegurando además un rendimiento aceptable Memoria Compartida: Permite que los procesos puedan compartir trozos de la memoria asignada.

El Administrador de memoria posee dos interfaces: una interfaz con llamada a sistema que es usada por los procesos de usuario (User Space) y una interface que es usada por los otros subsistemas (Kernel Space). Ya que Linux soporta multiples arquitecturas, es necesario entonces que existan rutinas específicas para abstraer los detalles del uso del hardware en una sola interface. El Memory Manager usa el administrador de memoria de hardware para mapear direcciones virtuales a direcciones físicas. Gracias a esto, los procesos no están conscientes de cuanta memoria física está asociada a una dirección virtual. Esto permite al MM poder mover trozos de memoria virtual dentro de la memoria física. Además, permite que dos procesos puedan compartir dos trozos de memoria física si las regiones de memoria virtual asignadas a ellas son mapeadas en la misma dirección física. Otro concepto importante es el Swapping o intercambio, que es intercambiar (swap) memoria ocupada por procesos en un archivo. Esto le permite al kernel poder ejecutar mayor cantidad de procesos que usen mayor cantidad de memoria física existente. El MM posee un demonio, kswapd, para ejecutar la tarea de intercambiar zonas de memoria en archivos y viceversa. Este demonio chequea periódicamente si no existen direcciones físicas mapeadas recientemente. Estas direcciones son vaciadas de la memoria física, y además de esto, el MM minimiza la

Página 7


Tecsup

cantidad de actividad de disco necesaria para hacer este intercambio. Si el administrador de memoria detecta un acceso no permitido (a la memoria) notifica al proceso con una señal. Si el proceso no sabe cómo manejar esta señal, el proceso es finalizado. 5.3.

Sistemas de Archivos Virtual Linux está diseñado para soportar distintos tipos de dispositivos físicos. Incluso para un tipo específico, como un disco duro, existen diferentes interfaces de manejo entre un fabricante de hardware y otro. Además de los dispositivos físicos, Linux posee soporte para sistemas de archivos lógicos que lo hace interoperante entre distintos sistemas operativos, con los siguientes propósitos:

Multiples dispositivos físicos de hardware Multiples sistemas de archivos lógicos Múltiples tipos de archivos ejecutables Homogeneidad, es decir, una interfaz común entre los sistemas de archivos lógicos y el hardware Rendimiento Seguridad de datos, perder o corromper datos Seguridad de acceso, restricción a los archivos, quotas, permisos, etc. También se usan dos interfaces para el manejo de filesystems. Una interfaz para llamadas de usuarios y otra para los subsistemas del kernel. La interfaz para los usuarios maneja archivos y directorios. Las operaciones en archivos incluyen open/read/close/write/seek, que están definidas en el estándar POSIX y en los directorios readdir/creat/unlink/chmod/stat tambien definidas en POSIX. Pero la interface de los subsistemas del Kernel es bastante más interesante. Esta posee estructuras de datos y funciones para manipulación directa para otros subsistemas. De hecho, existen dos interfaces para el resto del kernel: inodos y archivos. Volviendo con los controladores de dispositivos o drivers, Linux posee tres tipos de drivers: char, block y network. Los dos más relevantes son char y block. Los dispositivos char son aquellos que su lectura es secuencial (de a un char a la vez), como un mouse. Los dispositivos block

Página 8


Tecsup

pueden ser accedidos de cualquier manera, pero solo puede leerse o escribirse de a bloques. Todos los drivers soportan las operaciones mencionadas recién. Además, cada dispositivo puede ser accesado como si fuera un archivo. Ya que el Kernel se entiende con los dispositivos de esa manera, no es complicado agregar un nuevo dispositivo, ya que solo es necesario implementar el código específico del hardware para el soporte de la abstracción de archivos. Además, el kernel posee un buffer de caché para mejorar el rendimiento cuando usa dispositivos block. Todo acceso a un dispositivo block pasa a través de un subsistema de buffer. Este buffer aumenta considerablemente el rendimiento minimizando las lecturas y escrituras hacia y desde los dispositivos. Cada dispositivo posee una cola de petición (request queue). Cuando el buffer no puede responder una petición, se agrega una petición a esta cola y hace que la petición duerma (sleep) hasta que pueda responder. Este buffer usa un espacio separado del kernel como un thread único, manejado por kflushd. Existen distintos mecanismos para mover datos entre el computador hacia los dispositivos: Polling (votación) DMA (acceso directo a memoria) Interrupciones En el caso de polling, el driver verifica periódicamente el CSR (Control & Status Register) para ver si la petición ha sido completada. Si es así, el dispositivo inicia la siguiente petición y continúa. Polling es altamente efectivo en dispositivos de transferencia lenta, como disketteras y modems. En el caso de DMA, el driver inicia una transferencia directa entre la memoria del computador y el periférico. Esta transferencia es concurrente con la CPU y permite que la CPU siga haciendo otras tareas mientras se transfieren datos. Cuando la operación termina, la CPU recibe una interrupción. Cuando un dispositivo desea cambiar de estado (por ejemplo, presionar el botón del mouse) o reporta el final de una operación, envía una interrupción al procesador. Si

Página 9


Tecsup

las interrupciones están habilitadas, el procesador detiene su ejecución actual y comienza a ejecutar el código de manejo de interrupciones del kernel. El kernel encuentra el manejador correcto para invocar. Cuando una interrupción es manejada, la CPU se ejecuta en un contexto especial, es decir, todas las interrupciones quedan pendientes hasta que la interrupción actual haya terminado. Debido a esto, los manejadores de interrupciones deben ser altamente eficientes. Si ocurre el caso que un manejador de interrupciones no puede terminar el trabajo, reasigna el trabajo pendiente en un manejador de tipo "bottom-half" , es decir, código que se ejecutará la próxima vez que la llamada sea completada para evitar latencias y promover la concurrencia. Volviendo ahora a los sistemas de archivos lógicos, es más fácil acceder a un dispositivo si es manejado como un archivo que directamente en el hardware. Un filesystem lógico puede ser montado en un punto de montaje dentro del filesystem virtual. Esto significa que un bloque asociado a un dispositivo contiene archivos y una información de estructura que permite al filesystem lógico acceder al dispositivo. Un dispositivo sólo puede tener un soporte lógico de archivo. Sin embargo, el dispositivo puede ser "adiestrado" para poseer soporte para un soporte lógico en otro tipo de filesystem. En pocas palabras y con una explicación más clara, los dispositivos por lo general se encuentran en /dev y cada dispositivo se representa como un archivo. Es perfectamente posible reescribir el manejador del dispositivo para que soporte otro tipo de filesystem lógico. Para el soporte de filesystems virtuales, Linux usa Inodos para representar un archivo en un dispositivo block. El inodo es virtual en el sentido que contiene operaciones que están implementadas de distintas maneras, dependiendo del sistema lógico y físico donde el archivo reside. El inodo es usado como un lugar de almacenamiento para toda la información relacionada con el manejo de, por ejemplo, abrir un archivo del disco. Guarda buffers, el largo del archivo, etc. Mucha de la funcionabilidad de los filesystems virtuales radica en los módulos. Esta configuración permite a los usuarios compilar un Kernel tan pequeño como sea posible, cargando solamente los módulos que sean necesarios.

Página 10

Tecsup

5.4.


Inter-Process Comunication El IPC es un mecanismo en el cual los procesos que se están ejecutando posean medios para compartir recursos, sincronizarse y compartir datos entre ellos. Linux implementa todas las formas de IPC a través de recursos compartidos, estructuras de datos de kernel y colas de espera.

Estas formas de IPC son a través de Señales Colas de Espera Bloqueos de Archivos Pipes y Named Pipes, que permiten una transferencia de datos bidireccional y orientada a la conexión entre dos procesos, explícitamente seteando los pipes o comunicándolos a través de named pipes en el sistema de archivos (N. del E.:piensen en ls -als | more como una forma de piping) Unix Domain Sockets, otro medio de transferencia, más usado en el modelo INET IPC de System V compuesta por Semáforos Colas de Mensaje Memoria Compartida Una señal es una notificación enviada a un proceso por el kernel o por otro proceso. Las señales se envían a través de send_sig(). El número de señal se da como parámetro, como también el proceso destino. Los procesos pueden registrar sus propias señales, a través de la función signal(). Los bloqueos de archivo están soportados directamente por el kernel. Para bloquear un archivo, puede usarse open() simplemente. Pipes (tuberías) pueden ser usadas con pipe(), para filesystems read() o write() y para named pipes open(). Para Unix Domain Sockets, toda la funcionabilidad está encapsulada en socketcall(). En IPC de System V, existe una interfaz común para los tres métodos, ipc(). Las colas de espera son solo listas con los procesos que esperan por un evento del kernel, como la finalización de una lectura de DMA. Un proceso puede entrar

Página 11


Tecsup

voluntariamente a una cola de espera con sleep_on() o interruptable_sleep_on() y despertar con wake_up() o wake_up_interruptable() (que remueve los procesos de esta cola). Los bloqueos de archivos ocurren para prevenir que dos procesos puedan acceder al mismo archivo. Esta exclusión puede ser hecha al archivo completa o a una porción del archivo. Los Pipes y Named Pipes son similares, pero su creación es diferente. En ambos casos debe existir un descriptor de archivo que esta enlazado a la tubería. Después de la creación de la tubería, una página de memoria es asociada a ella que es tratada como un buffer circular, donde las funciones de escritura se manejan de forma atómica. Si se llena este buffer, se bloquea el proceso de escritura. Si se leen más datos de los existentes, el proceso de lectura se bloquea. Así, cada tubería posee un proceso de espera asociado. Los semáforos se implementan con colas de espera, siguiendo el modelo clásico de semáforos. Cada semáforo posee un valor asociado. Existen dos operaciones para este manejo, up() y down(). Cuando el valor del semáforo es 0, el proceso que ocupa el semáforo (para decrementar su estado) es bloqueado en la cola de espera. Las colas de mensajes son listas que los procesos leen o escriben secuencias de bytes. Los mensajes se reciben en el mismo orden que son escritos. Existen dos colas, una para los procesos que envían un mensaje completo a la cola y otra para ordenar las escrituras de los mensajes. La memoria compartida es la forma más rápida de IPC. Permite que los procesos puedan compartir regiones de la memoria. La creación de esta memoria compartida se hace a través del administrador de memoria 5.5.

Network Interface El sistema de red de Linux permite la conectividad entre distintas máquinas de una red y un modelo de conexión via sockets.

Existen dos tipos de sockets, los BSD y los INET. Linux posee dos protocolos de transporte con distintos tipos de modelo de comunicación y calidad de servicio. Están los mensajes no confiables, basados en el protocolo

Página 12

Tecsup


UDP y los mensajes confiables basados en TCP. Estos dos están implementados sobre el protocolo de transporte y el protocolo IP. El protocolo IP está por encima de los drivers. A los drivers se les provee distintas formas de comunicación: SLIP (Serial Link IP), PLIP (Parallel Line IP) y Ethernet. Un protocolo de resolución de direcciones media entre el protocolo IP y los drivers de Ethernet. Su tarea es resolver direcciones IP lógicas y convertirlas en direcciones físicas ethernet (de capa 3 a capa 2). Los servicios de red son usados por los otros subsistemas y por el usuario atraves de la interfaz de sockets, que son creados y manipulados atraves de socketcall(). Los datos son leidos y escritos a través de read() y write() como si fuera un descriptor de archivo. El modelo BSD de sockets es presentado a los procesos de usuario. El modelo es orientado a la conexión, se permite hacer streaming (flujo) y se permiten buffers. La implementación BSD está por sobre la INET. BSD maneja las tareas de forma similar al VFS (Virtual File System) y administra una estructura de datos general para las conexiones. Su propósito es la portabilidad a través de la abstracción de los detalles, a través de una simple interfaz. La interfaz BSD es usada por Unix y Windows. El modelo INET administra los puntos finales de la comunicación para los protocolos TCP y UDP. La lectura/escritura de red comienza por leer o escribir en un socket. Esto invoca a una llamada de sistema que es manejada por el VFS (o sea, las llamadas a archivo o sockets es simétrica). Desde ahí, se determina que la llamada BSD sock_write() es la que implementa la llamada al filesystem. Esta rutina maneja detalles administrativos (permisos) y pasa el control a inet_write(), para después llamar a una funcion de transporte, como tcp_write(). Las rutinas de escritura de la capa de transporte son las responsables de fragmentar los datos entrantes en paquetes de transporte. Estas rutinas pasan el control a ip_build_header() que construye una cabecera IP para ser insertada en el paquete a enviar. Luego, tcp_build_header() es llamada para crear una cabecera TCP. Una vez hecho esto, se envían los datos directamente al driver de red.

Página 13


Tecsup

El sistema de red posee dos servicios de transporte diferentes. UDP posee una comunicación no orientada a la conexión y no confiable. Está encargada de recibir paquetes de la capa IP y encontrar el socket de destino donde los datos deben ser enviados. Si no se encuentra el socket, se genera un error. TCP, en cambio, es bastante más complicado. Además del manejo de datos entre los procesos de recepción y envío, realiza complicadas tareas de administración de la conexión. TCP envía los datos al socket como un stream (flujo), en vez de una secuencia de datos (como UDP), pero garantiza una comunicación confiable. El protocolo IP provee un servicio de transporte de paquetes. Dado un paquete y un destino, la capa de comunicación IP es responsable del enrutamiento del paquete al host que corresponda. Para un flujo de datos saliente, IP es responsable de Particionar el flujo en paquetes IP Enrutar los paquetes a la dirección de destino Generar una cabecera que será usada por los drivers de red Seleccionar el dispositivo de red apropiado para enviar los datos Para un flujo de datos entrantes, IP es responsable de Verificar la validez de la cabecera Comparar la dirección de destino con la dirección local y reenviarlo si no corresponde Desfragmentar el paquete IP Enviar los paquetes a la capa TCP o UDP según corresponda El protocolo ARP (Address Resolution Protocol) es el responsable de convertir entre direcciones IP y direcciones de red reales. ARP soporta distintos tipos de hardware, Ethernet, FDDI, etc. Esta función es necesaria cuando los sockets se comunican con direcciones IP, ya que no pueden ser usadas directamente por los dispositivos de red. El subsistema de red provee sus propios drivers para conexiones seriales, paralelas y ethernet. Posee una interfaz de abstracción para los dispositivos para ocultar

Página 14


Tecsup

las diferencias entre las comunicaciones de las capas más bajas y más altas de este subsistema. 6. MODULOS En este contexto, módulo se refiere a un controlador de un dispositivo o servicio que puede cargarse o descargarse cuando el usuario o algún dispositivo lo solicitan (generalmente dinámicamente). Los módulos que se distribuyen con el kernel están ubicados en el directorio /lib/modules/version, donde version es la versión de su kernel, con la extensión .ko organizados en directorios que indican el tipo de dispositivo o el propósito por ejemplo: fs - sistema de archivos net - protocolos y hardware para redes. Para lograr configurar un dispositivo controlado por un módulo: •

•

•

6.1.

Asegurar que no haya conflictos entre el dispositivo con otros y eventualmente conocer la configuración que usa (algunos controladores auto detectan la configuración del dispositivo, pero no todos). Encontrar un módulo que pueda manejar el dispositivo. Eventualmente pasar opciones al módulo de acuerdo a la configuración del dispositivo (IRQ o I/O) Comandos 6.1.1. lsmod Lista los módulos cargados, de cada uno presenta nombre, tamaño, cuenta de usos y lista de módulos que lo usan (es equivalente a cat /proc/modules). 6.1.2. rmmod módulos Descarga uno o más módulos cargados, mientras estos no estén siendo usados. Con la opción -r intenta descargar recursivamente módulos de los cuales el módulo especificado dependa. El comando rmmod -a descarga todos los módulos que no estén siendo usados. 6.1.3. insmod módulo [opciones] Trata de cargar el módulo especificado. Pueden pasarse opciones específicas para el módulo, a continuación del nombre con la sintaxis símbolo=valor . Puede indicarse una ruta no estándar para buscar módulos estableciéndola en la variable MODPATH o en /etc/modules.conf. Dado que los módulos se enlazan directamente con el kernel,

Página 15


Tecsup

deben ser compilados para una versión precisa, con la opción -f puede evitarse el chequeo de versiones. 6.1.4. depmod Como un módulo puede requerir otros, hay dependencias que deben respetarse al cargar y descargar módulos. depmod permite calcular tales dependencias entre varios módulos o entre todos los disponibles con la opción -a. 6.1.5. modprobe módulo opciones Emplea la información de dependencias generada por depmod e información de /etc/modules.conf para cargar el módulo especificado, cargando antes todos los módulos de los cuales dependa. Para especificar el módulo basta escribir el nombre (sin la ruta, ni la extensión .o) o uno de los alias definidos en /etc/modutils/alias.

7. Numeración del Kernel La versión del kernel de Linux actualmente consta de cuatro números. Por ejemplo, asumamos que el número de la versión está compuesta de esta forma: A.B.C[.D] (ej.: 2.2.1, 2.4.13 ó 2.6.12.3). El número A denota la versión del kernel. Es el que cambia con menor frecuencia y solo lo hace cuando se produce un gran cambio en el código o en el concepto del kernel. Históricamente solo ha sido modificado dos veces: en 1994 (versión 1.0) y en 1996 (versión 2.0). El número B denota la mayor revisión del kernel. Antes de la serie de Linux 2.6.x, los números pares indicaban la versión “estable” lanzada. Por ejemplo una para uso de fabricación, como el 1.2, 2.4 ó 2.6. Los números impares, en cambio, como la serie 2.5.x, son versiones de desarrollo, es decir que no son consideradas de producción. Comenzando con la serie Linux 2.6.x, no hay gran diferencia entre los números pares o impares con respecto a las nuevas herramientas desarrolladas en la misma serie del kernel. Linus Torvalds dictaminó que este será el modelo en el futuro. El número C indica una revisión menor en el kernel. En la forma anterior de versiones con tres números, esto fue cambiado cuando se implementaron en el kernel los parches de seguridad, bugfixes, nuevas características o drivers. Con la nueva política, solo es cambiado cuando se introducen nuevos drivers o características; cambios menores se reflejan en el número D.

Página 16


Tecsup

El número D se produjo cuando un grave error, que requiere de un arreglo inmediato, se encontró en el código NFS de la versión 2.6.8. Sin embargo, no había otros cambios como para lanzar una nueva revisión (la cual hubiera sido 2.6.9). Entonces se lanzó la versión 2.6.8.1, con el error arreglado como único cambio. Con 2.6.11, esto fue adoptado como la nueva política de versiones. Bug-fixes y parches de seguridad son actualmente manejados por el cuarto número dejando los cambios mayores para el número C.

8. Actualización del Kernel 8.1.

Preparación de la actualización

Antes de actualizar el kernel, tome algunas precauciones. La primera es asegurarse que tiene un disco de arranque en caso de que haya problemas. Si el gestor de arranque no está configurado apropiadamente para arrancar el nuevo kernel, no será capaz de arrancar su sistema a menos que tenga un disquete de arranque. Para crear un disco de arranque para su sistema, conéctese como usuario root y en el intérprete de comandos teclee el siguiente comando:

# mkbootdisk `uname -r`

Reinicie la máquina con el disquete de arranque y verifique que funciona antes de continuar. Con suerte, no necesitará usar el disquete, pero guárdelo en un lugar seguro por si acaso. Para determinar cuáles paquetes del kernel están instalados, ejecute el comando siguiente en el intérprete de comandos:

# rpm -qa | grep kernel

La salida contendrá alguno o todos de los siguientes paquetes, dependiendo del tipo de instalación que haya realizado (el número de la versión puede variar):

Página 17


Tecsup

kernel-2.4.20-2.47.1 kernel-debug-2.4.20-2.47.1 kernel-source-2.4.20-2.47.1 kernel-doc-2.4.20-2.47.1 kernel-pcmcia-cs-3.1.31-13

kernel-smp-2.4.20-2.47.1

De la anterior salida, puede determinar qué paquetes necesita descargar para actualizar el kernel. El único paquete necesario para un sistema con un único procesador es el kernel. 8.2.

Paquetes del Kernel

Si tiene una computadora con más de un procesador, necesita el paquete kernel-smp que contiene el soporte para más de un procesador. También se recomienda instalar el paquete kernel en el caso de que el kernel con varios procesadores no funcione correctamente con el sistema. Si tiene una computadora con una memoria superior a cuatro GB, necesita el paquete kernel-bigmem para que el sistema pueda usar más de cuatro gigabytes de memoria. De todas maneras, se recomienda instalar el paquete kernel por si ocurriera algún error. El paquete kernelbigmem existe sólo para la arquitectura i686. Si está actualizando el kernel en un ordenador portátil o está usando PCMCIA, el paquete kernel-pcmcia-cs también es necesario. No necesita el paquete kernel-source a menos que vaya a recompilar el kernel por sí mismo o vaya a desarrollarlo. El paquete kernel-doc contiene documentación sobre desarrollo del kernel y no es necesario. Se recomienda si el sistema es usado para desarrollos del kernel. El paquete kernel-util incluye utilidades que pueden ser usadas para controlar el kernel o el hardware del sistema. No es necesario. Red Hat crea kernels que han sido optimizados para diferentes versiones x86. Las opciones son athlon para los sistemas AMD Athlon™ y AMD Duron™, i686 para sistemas Intel® Pentium® II, Intel® Pentium® III, e Intel® Pentium® 4, y i586 para sistemas Intel® Pentium® y AMD K6™. Si no sabe cuál es la versión de su sistema x86, use el

Página 18


Tecsup

kernel para la versión i386 ya que es compatible con todas los sistemas basados en la arquitectura x86. La versión x86 del paquete RPM se encuentra en el nombre del fichero. Por ejemplo, kernel-2.4.202.47.1.athlon.rpm se ha optimizado para los sistemas AMD Athlon™ y AMD Duron™ y kernel-2.4.202.47.1.i686.rpm para los sistemas Intel® Pentium® II, Intel® Pentium® III, e Intel® Pentium® 4. Cuando haya determinado los paquetes necesarios para su kernel, seleccione la arquitectura apropiada para los paquetes kernel, kernel-smp, y kernel-bigmem. Use las versiones i386 de los otros paquetes. 8.3.

Descarga

Hay varias maneras de saber si hay un kernel actualizado disponible para su sistema. Según las distribuciones que use: 8.3.1.

Distribución RedHAt

http://www.redhat.com/apps/support/errata/, elija la versión del sistema Red Hat Linux que está usando y busque la errata de ésta. Las erratas del kernel, normalmente están bajo la sección Security Advisories. Desde la lista de erratas, pulse kernel errata para ver los informes detallados de erratas. En el informe de erratas, hay una lista de paquetes RPM requeridos y un enlace para descargarlos desde el sitio FTP de Red Hat. También puede descargarlos desde un FTP espejo de Red Hat. Una lista de sitios espejos está disponible desde http://www.redhat.com/download/mirror.html. Use Red Hat Network para descargar los paquetes RPM del kernel e instalarlos. Red Hat Network puede descargar el kernel más reciente, actualizarlo en el sistema, crear una imagen de disco RAM inicial si se necesita y configurar el gestor de arranque para arrancar el nuevo kernel. Para más información, consulte Red Hat Network User Reference Guide disponible en http://www.redhat.com/docs/manuals/RHNet work/. 8.3.2.

Cualquier Distribución Revisar www.kernel.org

Página 19


8.4.

Tecsup

Realizando la actualización por RPM

Después de obtener todos los paquetes necesarios, es hora de actualizar el kernel existente. En el intérprete de comandos de la shell como root, cámbiese al directorio que contiene los paquetes RPM y siga los pasos. Nota: Se recomienda encarecidamente guardar el kernel anterior por si tiene problemas con el kernel nuevo. Use el argumento -i con el comando rpm para mantener el viejo kernel. Si la opción -U es usada para actualizar el paquete kernel, se sobreescribirá el kernel instalado actualmente (la versión del kernel y la versión x86 pueden variar): rpm -ivh kernel-2.4.20-2.47.1.i386.rpm

Si el sistema es un sistema multiprocesador, instale también los paquetes kernel-smp (la versión del kernel y la versión x86 pueden variar): rpm -ivh kernel-smp-2.4.20-2.47.1.i386.rpm

Si el sistema esta basado en i686 y contiene más de 4 gigabytes de RAM, instale el paquete kernel-bigmem construido para la arquitectura i686 así como también (la versión del kernel puede variar): rpm -ivh kernel-bigmem-2.4.20-2.47.1.i686.rpm

Si los paquetes kernel-source, kernel-docs, o kernel-utils se van a actualizar, las versiones más viejas lo más probable es que no sean necesarias. Use los comandos siguientes para actualizar estos paquetes (las versiones pueden variar): rpm -Uvh kernel-source-2.4.20-2.47.1.i386.rpm rpm -Uvh kernel-docs-2.4.20-2.47.1.i386.rpm rpm -Uvh kernel-utils-2.4.20-2.47.1.i386.rpm

Si está usando PCMCIA (por ejemplo, en un portátil), necesitará también instalar kernel-pcmcia-cs y guardar la versión vieja. Si se usa la opción -i probablemente tenga

Página 20


Tecsup

un conflicto ya que el kernel antiguo necesita este paquete para reiniciar con soporte PCMCIA. Para trabajar con ello, use la opción --force como sigue (la versión puede variar): rpm -ivh --force kernel-pcmcia-cs-3.1.24-2.i386.rpm

8.5.

Verificación de la imagen de disco RAM inicial

Si el sistema usa un controlador SCSI o un sistema de archivos ext3, necesitará un disco RAM inicial. El propósito de dicho disco es permitir a un kernel modular tener acceso a los módulos que son necesarios para arrancar antes de que el kernel tenga acceso a los dispositivos donde los módulos normalmente residen. El disco RAM inicial puede ser creado con el comando mkinitrd. Sin embargo, este paso es ejecutado automáticamente si el kernel y sus paquetes asociados son instalados o actualizados desde los paquetes RPM distribuidos por Red Hat, Inc.; por tanto, no necesita ser ejecutado manualmente. Para verificar que fue creado, use el comando: # ls –l /boot

Para asegurarse de que el archivo initrd-2.4.20-2.47.1.img fue creado (la versión debería coincidir la versión del kernel que acaba de instalar). Ahora que ya tiene instalado el nuevo kernel, necesita verificar que el gestor de arranque está configurado para cargar el nuevo kernel.

8.6.

Configuración del gestor de arranque

El paquete RPM kernel configura el gestor de arranque GRUB o LILO para arrancar el nuevo kernel si cualquiera de estos gestores de arranque es instalado. Sin embargo, no configura el gestor de arranque para cargar el nuevo kernel por defecto. Es una buena idea confirmar que el gestor de arranque se ha configurado correctamente. Esto es un paso crucial. Si el gestor de arranque está configurado de forma incorrecta, no podrán arrancar el sistema. Si esto ocurre, arranque el sistema con el disquete de arranque que creó anteriormente e intente configurar de nuevo el gestor de arranque.

Página 21


8.6.1.

Tecsup

GRUB

Si selecciona GRUB como gestor de arranque, asegúrese que el fichero /boot/grub/grub.conf contenga la sección title con la misma versión del paquete kernel que acaba de instalar (lo mismo para los paquetes kernel-smp o kernel-bigmem): # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/hda2 # initrd /initrd-version.img #boot=/dev/hda default=3 timeout=10 splashimage=(hd0,0)/grub/splash.xpm.gz title Red Hat Linux (2.4.20-2.47.1) root (hd0,0) kernel /vmlinuz-2.4.20-2.47.1 ro root=LABEL=/ initrd /initrd-2.4.20-2.47.1.img title Red Hat Linux (2.4.20-2.30) root (hd0,0) kernel /vmlinuz-2.4.20-2.30 ro root=LABEL=/ initrd /initrd-2.4.20-2.30.img

Si ha creado una partición separada para /boot, el camino al kernel y la imagen initrd será relativo a la partición /boot. Observe que el nuevo kernel no está configurado para ser el kernel por defecto. Para configurar GRUB para que arranque el nuevo kernel por defecto, cambie el valor de la variable default al número del título de la sección que contiene el nuevo kernel. La cuenta comienza con 0. Por ejemplo, si el nuevo kernel es el segundo título en la sección, configure default a 1. Comience evaluando el nuevo kernel reiniciando el computador y vigilando los mensajes para asegurarse de que el hardware es detectado adecuadamente. 8.6.2.

LILO

Si se utiliza LILO como el gestor de arranque, confirme que el archivo /etc/lilo.conf contiene una sección image con la misma versión que el

Página 22


Tecsup

paquete kernel que acaba de instalar (lo mismo para los paquetes kernel-smp o kernel-bigmem): prompt timeout=50 default=2.4.20-2.30 O boot=/dev/hda b map=/boot/map s install=/boot/boot.b e message=/boot/message r linear

v

image=/boot/vmlinuz-2.4.20-2.47.1 e label=2.4.20-2.47.1 initrd=/boot/initrd-2.4.20-2.47.1.img q read-only u append="root=LABEL=/"

e

image=/boot/vmlinuz-2.4.20-2.30 label=2.4.20-2.30 initrd=/boot/initrd-2.4.20-2.30.img read-only append="root=LABEL=/"

El nuevo kernel no está configurado para ser el kernel por defecto. Para configurar LILO para que arranque el nuevo kernel por defecto, cambie el valor de la variable default al valor de label de la sección image del nuevo kernel. Debe ejecutar el comando /sbin/lilo como root para activar los cambios. Después de ejecutarlo, verá un resultado similar al siguiente:

Added 2.4.20-2.47.1 * Added linux

El * después de 2.4.20-2.47.1 significa que el kernel en esa sección es el kernel por defecto que LILO arrancará.

“El gestor LILO esta

Comience evaluando el nuevo kernel reiniciando su ordenador y viendo los mensajes para asegurarse que su hardware es detectado apropiadamente.

que aparecerá”

Página 23

discontinuado en la mayoría de las distribuciones el GRUB es el único


Tecsup

9. Actualización con las fuentes del Kernel Descargar las fuentes desde www.kernel.org o un mirror. También vía ftp anónimo: ftp ftp://ftp.kernel.org/pub/linux/kernel/ El archivo con las fuentes se nombra como linux-x.y.z.tar.gz, donde x e y son las cifras que determinan la versión de nuestro kernel. La primera hace referencia a la generación y la segunda a la fase de desarrollo en la que se encuentra. Si la segunda cifra es impar, significa que nos encontramos ante un kernel inestable, por el contrario si la cifra es par el núcleo será estable. Por último, la z representa el número de versión en la que se encuentra una determinada versión del kernel, y como es lógico, intentaremos disponer de la versión más actual possible, para así gozar de las numerosas ventajas que se van introduciendo con cada versión. Para descomprimir el tarball es importante que no haya ningún directorio /usr/src/linux. Normalmente este fichero suele ser un link simbólico que apunta hacia el árbol de directorios de la versión del núcleo que este instalado en nuestra máquina. Si es así podemos borrarlo con un rm linux, o bien renombrar el directorio con mv:

# tar zxvf linux-2.4.17.tar.gz # ln -s linux-2.4.17 linux Para poder compilar el kernel necesitaremos tener el compilador de C gcc, se encuentra en los instaladores de Linux.  gccxxxx.rpm 9.1.

Compilar el kernel

Entraremos como root en el sistema y nos situaremos en el directorio que contiene las fuentes del núcleo: # cd /usr/src/linux (esto nos sita en el directorio que contiene las fuentes) # make mrproper (trae la fuente del kernel a su estado básico)

Lo primero es generar los archivos de configuración del nuevo kernel. Existen tres formas de generar estos archivos.

Página 24

Tecsup


# make config (modo texto basado en preguntas algo engorroso) # make menuconfig (modo texto con menús con ayuda) # make xconfig (modo gráfico, requiere X-windows)

La primera opción es poco recomendable ya que deberemos responder a infinidad de complicadas preguntas que no deberemos fallar, de lo contrario, tendremos que volver a empezar otra vez desde el principio. El segundo método se basa en una serie de menús y submenús. Bastará con ir seleccionando las diferentes opciones que aparecen para adaptar el núcleo a nuestro hardware y capacitarlo para que haga lo que nos interese. Esta opción dispone de una ayuda que nos explicará en qué consiste cada una de las opciones. Para ejecutar esta opción es necesario tener instalado en nuestro sistema el paquete ncurses. El tercer método sólo funcionará si tenemos configurado el sistema X-windows. Si hemos optado por el método de menús (menuconfig), o por el gráfico (xconfig),una vez seleccionadas todas las opciones que nos interese saldremos de la aplicación guardando los cambios realizados. Ahora ya estamos en condiciones de compilar el núcleo con las opciones que acabamos de seleccionar, para ello haremos lo siguiente:

# make dep (o make depend libera de dependencias del núcleo para que la compilación sea correcta) # make clean # make bzImage (Este comando compila el núcleo y genera una imagen comprimida) # make modules (Compila los modulos) # make modules_install (instala los módulos ) # make install (Copia el nuevo núcleo al directorio /boot)

Otra manera de instalar los módulos y el kernel una vez compilados podría ser esta: # cp arch/i386/boot/bzImage > /boot/ (Esto desde la ubicación actual --> /usr/src/linux # mv /boot/System.map /boot/System.old # cp System.map /boot/System.map

Página 25


Tecsup

10. Módulos del kernel El kernel de Linux tiene un diseño modular. En el momento de arranque, sólo se carga un kernel residente mínimo en memoria. Por ello, cuando un usuario solicita alguna característica que no está presente en el kernel residente, se carga dinámicamente en memoria un módulo kernel, también conocido algunas veces como un controlador . Durante la instalación, se prueba el hardware en el sistema. Basado en esta prueba y en la información proporcionada por el usuario, el programa de instalación decide qué módulos necesita cargar en el momento de arranque. El programa de instalación configura el mecanismo de carga dinámica para que funcione de forma transparente. Si se añade un nuevo hardware después de la instalación y este requiere un módulo kernel, el sistema debe ser configurado para cargar el módulo adecuado para el nuevo hardware. Cuando el sistema es arrancado con el nuevo hardware, se ejecuta el programa Kudzu detecta el nuevo hardware si es soportado y configura el módulo necesario para él. El módulo también puede ser especificado manualmente modificando el archivo de configuración del módulo, /etc/modules.conf. “ Los módulos de tarjetas de vídeo usados para desplegar la interfaz del sistema X Window son parte del paquete XFree86, no del kernel; por lo tanto, este capítulo no se aplica a ellos.”

Por ejemplo, si un sistema incluye un adaptador de red SMC EtherPower 10 PCI, el archivo de configuración del módulo contiene la línea siguiente:

alias eth0 tulip

Si una segunda tarjeta de red es añadida al sistema y es idéntica a la primera tarjeta, añada la línea siguiente al archivo /etc/modules.conf:

alias eth1 tulip

11. Utilidades del módulo del kernel Está disponible un grupo de comandos para el manejo de módulos kernel si el paquete modutils está instalado. Use estos

Página 26


Tecsup

comandos para determinar si un módulo ha sido cargado exitosamente o cuando se esté probando módulos diferentes para una nueva pieza de hardware. El comando /sbin/lsmod muestra una lista de los módulos cargados actualmente. Por ejemplo: Module iptable_filter ip_tables nfs lockd sunrpc soundcore ide-cd cdrom parport_pc lp parport autofs e100 microcode keybdev mousedev hid input usb-uhci usbcore ext3 jbd

Size 2412 15864 84632 59536 87452 7044 35836 34144 19204 9188 39072 13692 62148 5184 2976 5656 22308 6208 27468 82752 91464 56336

Used by Not tainted 0 (autoclean) (unused) 1 [iptable_filter] 1 (autoclean) 1 (autoclean) [nfs] 1 (autoclean) [nfs lockd] 0 (autoclean) 0 (autoclean) 0 (autoclean) [ide-cd] 1 (autoclean) 0 (autoclean) 1 (autoclean) [parport_pc lp] 0 (autoclean) (unused) 1 0 (autoclean) 0 (unused) 1 0 (unused) 0 [keybdev mousedev hid] 0 (unused) 1 [hid usb-uhci] 2 2 [ext3]

Por cada línea, la primera columna es el nombre del módulo, la segunda columna es el tamaño del módulo y la tercera es el recuento de usos. La información después del recuento de usos varía un poco por módulo. Si se lista (unused) en la línea del módulo, el módulo no está siendo usado actualmente. Si (autoclean) está en la línea para el módulo, este puede ser limpiado automáticamente por el comando rmmod -a. Cuando se ejecuta este comando, cualquier módulo que este etiquetado con autoclean, que no ha sido usado desde la acción previa de autoclean, será cargado. Red Hat Linux no realiza esta acción de autoclean por defecto. Si el nombre de un módulo esta listado al final de la línea entre corchetes, el módulo entre corchetes es dependiente del módulo listado en la primera columna de la línea. Por ejemplo, en la línea usbcore

82752

1 [hid usb-uhci]

Los módulo del kernel hid y usb-uhci dependen del módulo usbcore.

Página 27


Tecsup

La salida /sbin/lsmod es la misma que la salida de /proc/modules. Para cargar un módulo del kernel, use el comando /sbin/modprobe seguido del nombre del módulo. Por defecto, modprobe intenta cargar el módulo desde los subdirectorios /lib/modules/ /kernel/drivers/. Hay un subdirectorio para cada tipo de módulo, tal como el subdirectorio net/ para los controladores de interfaces de red. Algunos módulos del kernel tienen dependencias, es decir que otros módulos deben ser cargados antes para que el otro se cargue. El comando /sbin/modprobe verifica estas dependencias y carga los módulos necesarios antes de cargar el módulo específico. Por ejemplo, el comando /sbin/modprobe hid

Carga cualquier dependencia de módulos y luego el módulo hid. Para imprimir a la pantalla todos los comandos a medida en que /sbin/modprobe los ejecuta, use la opción -v. Por ejemplo: /sbin/modprobe -v hid

Se despliega una salida similar a lo siguiente: # /sbin/insmod /lib/modules/2.4.20-2.47.1/kernel/drivers/usb/hid.o Using /lib/modules/2.4.20-2.47.1/kernel/drivers/usb/hid.o version prefix 'smp_'

Symbol

El comando /sbin/insmod también existe para cargar módulos kernel; sin embargo no resuelve dependencias. Por ello se recomienda el uso de /sbin/modprobe. Para descargar módulos del kernel, use el comando /sbin/rmmod seguido por el nombre del módulo. La utilidad rmmod sólo descarga módulos que ya no son usados y que no son una dependencia de otro módulo en uso. Por ejemplo, el comando: /sbin/rmmod hid

Página 28

Tecsup


Baja el módulo del kernel hid. Otra utilidad muy conveniente es modinfo. Use el comando /sbin/modinfo para mostrar información sobre el módulo del kernel. La sintaxis general es: /sbin/modinfo [options]

Las opciones incluyen -d, lo cual muestra una breve descripción del módulo, y -p lo que lista los parámetros que el módulo soporta. Para una lista completa de las opciones, consulte la página del manual de modinfo (man modinfo).

12. BIBLIOGRAFIA Libro de Kernel http://www.kroah.com/lkn/ Video de Kernel http://video.google.com/videoplay?docid=3498228245415745977

13. Bibliografía Manual de Kernel (www.kernel.org)

Página 29

Administracion Del Kernel

Recommend Documents