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 interfaz y controladores.
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 n�meros encima e insertada en una ranura de su PC. Esto es lo que por lo general denominamos un dispositivo f�sico.
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 controlador(N. del T.: Con frecuencia, la bibliograf�a especializada en espa�ol tambi�n los llama manejadores o drivers). Linux tiene controladores para muchos tipos de tarjetas de red: ISA, PCI, MCA, EISA, puerto paralelo, PCMCIA, y m�s recientemente, USB.
�Pero qu� es lo que queremos decir con que un controlador “gestione” un dispositivo? Vamos a tratar sobre esto con una tarjeta Ethernet. El controlador tiene que ser capaz de comunicarse de alguna forma con la l�gica interna de la tarjeta: tiene que enviar �rdenes y datos a la tarjeta, mientras que la tarjeta debe transmitir al controlador cualquier dato recibido.
En un PC compatible, esta comunicaci�n se establece por medio de una serie de direcciones de E/S que son mapeadas a los registros de la tarjeta y/o a trav�s de transferencias directas o compartidas a memoria. Todos las �rdenes y datos que el n�cleo env�a 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 t�picas para las tarjetas Ethernet por bus ISA son 0x280 o 0x300. Las tarjetas de red por bus PCI generalmente ya tienen asignada autom�ticamente su direcci�n de E/S.
Normalmente no hay que preocuparse por asuntos de hardware como las direcciones base porque al arrancar el n�cleo intenta detectar la localizaci�n de la tarjeta. Esto es llamado autoverificaci�n (N. del T.: Del ingl�s autoprobe), que significa que el n�cleo lee varias posiciones de memoria y compara los datos que ha encontrado con los que esperar�a ver si una tarjeta de red en concreto estuviese instalada en esa posici�n. De todas maneras, puede haber 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 n�cleo intentar� detectar solamente un �nico dispositivo de red al arrancar. Si est� usando m�s de una tarjeta, tendr� que informar al n�cleo de las otras tarjetas expl�citamente.
[1] Otro de los par�metros del que puede tener que informar al n�cleo es la l�nea de petici�n de interrupci�n. Los componentes hardware normalmente interrumpen al n�cleo cuando tienen la necesidad de que �ste 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 interrupci�n numerados asi: 0, 1, y del 3 al 15. Al n�mero de interrupci�n asignado a un componente hardware se le denomina n�mero de petici�n de interrupci�n (IRQ)..[2]
Como se describe en Cap�tulo 2, el n�cleo accede a un dispositivo mediante lo que llamamos un interfaz. Los 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.
Los interfaces se identifican por medio de nombres. En muchos sistemas operativos tipo Unix, el interfaz de red se implementa como un fichero de dispositivo especial en el directorio /dev/. Si usted teclea la orden ls -las /dev/, ver� como aparecen sus ficheros de dispositivos. En la columna de permisos de los ficheros (segunda) ver� que los ficheros de dispositivos comienzan con una letra en vez del gui�n visto con los ficheros normales. Este car�cter indica el tipo de dispositivo. Los tipos de dispositivos m�s 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 car�cter y maneja datos de un solo car�cter cada vez. Donde normalmente desear�a ver el tama�o del fichero en la salida de ls, en vez de eso ver� dos n�meros, llamados los n�meros de dispositivo "major" y "minor" (primario y secundario). Estos n�meros indican el dispositivo actual al que est� asociado el fichero de dispositivo.
Cada controlador de dispositivo registra un unico n�mero primario para el n�cleo. En cada caso los registros de dispositivos tienen un �nico n�mero secundario para dicho dispositivo primario. Los interfaces tty, /dev/tty*, son unos dispositivos de modo car�cter por lo que indica la “c”, y tienen un maximo n�mero de 4, pero /dev/tty1 tiene un n�mero menor de 1, y /dev/tty2 tiene un n�mero menor de 2. Los ficheros de dispositivos son muy �tiles 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 n�cleo y no son ficheros de dispositivos del directorio /dev. Algunos nombres de dispositivos t�picos ser�n listados despu�s en Secci�n 3.2.” La asignaci�n de interfaces a los dispositivos depende normalmente del orden en que los dispositivos son configurados. Por ejemplo, la primera tarjeta Ethernet instalada ser� eth0, la siguiente eth1, y as� sucesivamente. Las interfaces SLIP son manejadas de forma diferente a otras porque �stas son asignadas din�micamente. Cuando se establece una conexion SLIP, una interfaz es asignada al puerto serie.
Figura 3-1 Ilustra la relaci�n entre el hardware, los controladores de dispositivos, y las interfaces.
. . 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 . . |
[1] | N. del T.: Del ingl�s Interrupt ReQuest |
[2] | Las IRQs 2 y 9 son las mismas porque el dise�o del IBM PC tiene 2 procesadores de interrupciones en cascada con 8 IRQs cada uno, el procesador secundario es conectado a la IRQ 2 del primario. |