Hasta ahora, hemos estado hablando bastante sobre las interfaces de red pero sin explicar realmente qué es lo que pasa cuando el “código de red” del núcleo accede a una parte del hardware. Para ello, y antes que nada, tenemos que hablar un poco sobre los conceptos de interface y drivers.
Primero, evidentemente, está el hardware por sí mismo; por ejemplo, una tarjeta Ethernet, FDDI o Token Ring: es una oblea de silicio, atiborrada de montones de pequeños chips con extraños numeros encima e insertada en una ranura de su PC. Esto es lo que por lo general denominamos un dispositivo fisico.
Para poder utilizar una tarjeta de red son necesarias una serie de funciones especiales definidas en el núcleo de linux que seran capaces de entender la forma particular de acceso al dispositivo. Al software que implementa estas funciones se le llama driver(N. del T.: Con frecuencia, la bibliografía especializada en español también los llama manejadores o controladores). Linux tiene drivers para muchos tipos de tarjetas de red: ISA, PCI, MCA, EISA, Puerto paralelo, PCMCIA, y mas recientemente, USB.
¿Pero que es lo que queremos decir con que un driver “gestione” un dispositivo? Vamos a tratar sobre esto con una tarjeta Ethernet. El driver tiene que ser capaz de comunicarse de alguna forma con la lógica interna de la tarjeta: tiene que enviar comandos y datos a la tarjeta, mientras que la tarjeta debe transmitir al driver cualquier dato recibido.
En un PC compatible, esta comunicacion se establece por medio de una serie de direcciones de E/S que son mapeadas a los registros de la tarjeta y/o a traves de transferencias directas o compartidas a memoria. Todos los comandos y datos que el kernel envia a la tarjeta tienen que ir a estas direcciones. Las direcciones de memoria y E/S son obtenidas generalmente por medio del arranque o de las direcciones base. Las direcciones base tipicas para las tarjetas Ethernet por bus ISA son 0x280 o 0x300. Las tarjetas de red por BUS PCI generalmente ya tienen asigna automaticamente su direccion de E/S.
Normalmente no hay que preocuparse por asuntos de hardware como las direcciones base porque al arrancar el kernel intenta detectar la localizacion de la tarjeta. Esto es llamado autoverificacion (N. del T.: Del inglés autoprobe), que significa que el kernel lee varias posiciones de memoria y compara los datos que ha encontrado con los que esperaria ver si una tarjeta de red en concreto estubiese instalada en esa posicion. De todas maneras, pueden haver tarjetas de red que no puedan ser detectadas automáticamente; esto ocurre a veces con tarjetas de red baratas que no son réplicas exactas de tarjetas estándar de otros fabricantes. Por otro lado, el kernel intentara detectar solamente un único dispositivo de red al arrancar. Si esta usando mas de una tarjeta, tendra que informar al kernel de las otras tarjetas explicitamente.
(N. del T.: Del ingles Interrupt ReQuest) Otro de los parametros del que puede tener que informar al kernel es la linea de petición de interrupcion. Los componentes hardware normalmente interrumpen al kernel cuando tienen la necesidad de que este se ocupe de ellos, por ejemplo, cuando han llegado datos o se presenta una condición especial. En un bus ISA, las interrupciones pueden ocurrir en uno de los 15 canales de interrupcion numerados asi: 0, 1, y del 3 al 15. Al numero de interrupcion asignado a un componente hardware se le denomina numero de peticion de interrupcion (IRQ)..[1]
Como se describe en Capítulo 2, el kernel accede a un dispositivo mediante lo que llamámos una interface. Las interfaces ofrecen un conjunto abstracto de funciones que es el mismo para todo tipo de hardware. Por ejemplo, las funciones para enviar o recibir datagramas.
(N. del T.: Del inglés device files) Las interfaces se identifican por medio de nombres. En muchos sistemas operativos tipo Unix, la interface de red es implementada como como un fichero de dispositivo especial en el directorio /dev/. Si usted teclea el comando ls -las /dev/, vera como aparecen sus ficheros de dispositivos. En la columna de permisos de los ficheros (segunda) vera que los ficheros de dispositivos comienzan con una letra en vez del guión visto con los ficheros normales. Este caracter indica el tipo de dispositivo. Los tipos de dispositivos mas comunes son los b, que indica que es un dispositivo de bloque y maneja grandes bloques de datos cada vez que lee y escribe, y c, que indica que el dispositivo es un dispositvo de caracter y maneja datos de un solo caracter cada vez. Donde normalmente desearia ver el tamaño del fichero en la salida de ls, en vez de eso vera dos numeros, llamados los numeros de dispositivo major y minor (primario y secundario). Estos numeros indican el dispositivo actual al que esta asociado el fichero de dispositivo.
Cada driver de dispositivo registra un unico numero primario para el kernel. En cada caso los registros de dispositivos tienen un unico numero secundario para dicho dispositivo primario. Las interfaces tty, /dev/tty*, son unos dispositivos modo caracter por lo que indica la “c”, y tienen un maximo numero de 4, pero /dev/tty1 tiene un numero menor de 1, y /dev/tty2 tiene un numero menor de 2. Los ficheros de dispositivos son muy utiles para muchos tipos de dispositivos, pero pueden ser pesados de usar cuando intentamos encontrar un dispositivo sin usar para abrir.
Los nombres de las interfaces de linux son definidos internamente en el kernel y no son ficheros de dispositivos del directorio /dev. Algunos nombre de dispositivos tipicos seran listados despues en Sección 3.2.” La asignacion de interfaces a los dispositivos depende normalmente del orden en que los dispositivos son configurados. Por ejemplo, la primera trajeta Ethernet instalada sera eth0, la siguiente eth1, y asi sucesivamente. Las interfaces SLIP son manejadas de forma diferente a otras porque estas son asignadas dinamicamente. Cuando se establece una conexion SLIP, una interface es asignada al puerto serie.
Figura 3-1 Ilustra la relacion entre el hardware, los drivers de dispositivos, y las interfaces.
Al arrancar, el kernel muestra los dispositivos detectados y las interfaces que instala. Lo siguiente es un extracto de la pantalla de arranque:
.
. This processor honors the WP bit even when in supervisor mode./
Good.
Swansea University Computer Society NET3.035 for Linux 2.0
NET3: Unix domain sockets 0.13 for Linux NET3.035.
Swansea University Computer Society TCP/IP for NET3.034
IP Protocols: IGMP,ICMP, UDP, TCP
Swansea University Computer Society IPX 0.34 for NET3.035
IPX Portions Copyright (c) 1995 Caldera, Inc.
Serial driver version 4.13 with no serial options enabled
tty00 at 0x03f8 (irq = 4) is a 16550A
tty01 at 0x02f8 (irq = 3) is a 16550A
CSLIP: code copyright 1989 Regents of the University of California
PPP: Version 2.2.0 (dynamic channel allocation)
PPP Dynamic channel allocation code copyright 1995 Caldera, Inc.
PPP line discipline registered.
eth0: 3c509 at 0x300 tag 1, 10baseT port, address 00 a0 24 0e e4 e0,/
IRQ 10.
3c509.c:1.12 6/4/97 becker@cesdis.gsfc.nasa.gov
Linux Version 2.0.32 (root@perf) (gcc Version 2.7.2.1)
#1 Tue Oct 21 15:30:44 EST 1997
.
. |
Este ejemplo muestra que el kernel ha sido compilado con el TCP/IP activado e incluyendo drivers para SLIP, CSLIP, y PPP. La tercera linea empezando desde abajo muestra que una tarjeta Ethernet 3C509 ha sido detectada y instalada como la interface eth0. Si tiene algun otro tipo de tarjeta de red; quizas un adaptador de bolsillo D-Link, por ejemplo—el kernel normalmente mostrara una linea que empieza con el nombre del dispositivo—dl0 en el caso del ejemplo del D-Link—seguido por el tipo de tarjeta detectada. Si tiene una tarjeta de red instalada pero no aparece ningun mensaje similar significa que el kernel es incapaz de detectar su tarjeta correctamente. Esta situacion sera tratada mas adelante en la seccion“Ethernet Autoprobing.”
| [1] | Los IRQs 2 y 9 son los mismos porque el diseño del IBM PC tiene 2 procesadores de interrupciones en cascada con 8 IRQs cada uno, el procesador secundario es conectado al IRQ 2 del primario. |