| Gu�a de Administraci�n de Redes con Linux | ||
|---|---|---|
| Anterior | Cap�tulo 4. Configuraci�n del Hardware Serie | Siguiente |
Como todo dispositivo en un sistema Unix, los puertos serie son accesibles a trav�s de ficheros especiales de dispositivo, localizados en el directorio /dev. Hay dos tipos de ficheros de dispositivo relacionados con manejadores serie, y hay un fichero de dispositivo de cada tipo para cada puerto. El dispositivo tendr� un comportamiento levemente distinto, seg�n cu�l de sus ficheros de dispositivo empleemos. Cubriremos estas diferencias porque ayudar� a entender algunos aspectos de configuraci�n y algunos consejos que puede encontrar respecto a dispositivos serie, pero en la pr�ctica, s�lo necesita utilizar uno de ellos. Quiz� en un futuro desaparezca alguno de estos tipos.
La m�s importante de las dos clases de dispositivos serie tiene un n�mero mayor de 4, y sus ficheros especiales de dispositivo se llaman ttyS0, ttyS1, etc. La otra variedad tiene un n�mero mayor de 5, y fue dise�ada para emplearse en llamadas salientes a trav�s de un puerto; sus ficheros especiales de dispositivo son cua0, cua1, etc. En el mundo Unix, las cuentas comienzan generalmente en cero, mientras que los profanos tienden a comenzar por uno. Esto genera una peque�a confusi�n ya que COM1: se representa por /dev/ttyS0, COM2: por /dev/ttyS1, etc. Un usuario cualquiera familiarizado con hardware del estilo del IBM PC sabe que COM3: y mayores nunca llegaron a ser est�ndar, de todos modos.
Los dispositivos cua, o “llamada salientes,” fueron creados para solucionar el problema de evitar conflictos en dispositivos serie para m�dems que tienen que aceptar tanto conexiones entrantes como conexiones salientes. Desafortunadamente, han creado sus propios problemas y probablemente dejar�n de ser utilizados. Echemos un vistazo al asunto.
GNU/Linux, igual que Unix, permite que un dispositivo, u otro fichero cualquiera, sea abierto por m�s de un proceso de forma simult�nea. Por desgracia, esto es raramente �til para dispositivos tty, ya que ambos procesos interferir�n entre s�. Pero, por suerte, se dise�� un mecanismo que permite a un proceso comprobar si un dispositivo tty est� en uso por otro proceso antes de tratar de abrirlo. Este mecanismo usa lo que denominamos ficheros de bloqueo. La idea es que cuando un proceso trata de abrir un dispositivo tty, ha de comprobar la existencia de un fichero en un lugar especial, llamado de forma parecida al dispositivo tty. Si este fichero no existe, el proceso lo crea y abre el dispositivo tty. Si el fichero, por contra, ya existe, el proceso asume que hay otro proceso que ya ha abierto el dispositivo tty y toma la decisi�n adecuada. Un �ltimo truco para que este sistema de manejo funcionara adecuadamente es escribir el identificador (pid) del proceso que ha creado el fichero de bloqueo en el propio fichero de bloqueo; seguiremos con este punto un poco m�s abajo.
El mecanismo de ficheros de bloqueo funciona perfectamente en los casos en que tenemos una localizaci�n bien definida para estos ficheros de bloqueo, y todos los programas saben d�nde buscarlos. Sin embargo, este no ha sido siempre el caso de GNU/Linux. No fue hasta que se defini� el Est�ndar de Sistema de Ficheros de Linux (Linux Filesystem Standard) cuando comenzaron a trabajar correctamente los ficheros de bloqueo tty. Lleg� a haber cuatro, e incluso m�s lugares elegidos por los programadores para almacenar los ficheros de bloqueo: /usr/spool/locks/, /var/spool/locks/, /var/lock/ y /usr/lock/. La confusi�n trajo el caos. Los programas abr�an ficheros de bloqueo en lugares distintos para controlar un mismo dispositivo tty; la situaci�n era similar a no usar ficheros de bloqueo en absoluto.
Los dispositivos cua fueron creados para solventar este problema. En lugar de confiar a los ficheros de bloqueo la prevenci�n de conflictos entre procesos que pretend�an usar dispositivos serie, se decidi� que el n�cleo podr�a suministrar un m�todo sencillo de arbitrar qui�n deb�a obtener acceso. Si el dispositivo ttyS estaba abierto, un intento de abrir el cua resultar�a en un error que podr�a ser interpretado por el programa como que el dispositivo ya estaba en uso. Si el cua estaba previamente abierto y se trataba de abrir el ttyS, la petici�n crear�a un bloqueo; es decir, se pondr�a en espera hasta que el dispositivo cua fuera cerrado por el otro proceso. Esta soluci�n era adecuada para casos como un m�dem �nico configurado para recibir accesos entrantes y que, en ocasiones, se quisiera emplear para accesos salientes. Pero no era suficiente para �mbitos en los que varios programas tratan de realizar llamadas salientes desde el mismo dispositivo. La �nica forma de remediar este problema era �usar ficheros de bloqueo! De vuelta al problema inicial.
Basta decir que el Est�ndar de Sistema de Ficheros de Linux lleg� al rescate y ahora es obligatorio almacenar los ficheros de bloqueo en el directorio /var/lock, y que, por acuerdo, el nombre del fichero de bloqueo correspondiente al dispositivo ttyS1, por ejemplo, es LCK..ttyS1. Los ficheros de bloqueo cua tambi�n deber�an ir en este directorio, pero el uso de dispositivos cua queda desaconsejado
Los dispositivos cua seguir�n existiendo por un tiempo, para conservar la compatibilidad con software antiguo, pero con el tiempo ser�n retirados. Si usted se pregunta cu�les debe usar, qu�dese con los dispositivos ttyS, y aseg�rese de que su sistema cumpla con el est�ndar Linux FSSTND (Est�ndar de Sistema de Ficheros de Linux), o, como m�nimo, que todos los programas que accedan a dispositivos serie est�n de acuerdo en la localizaci�n de los ficheros de bloqueo. Gran parte del software que trata con dispositivos tty serie proporciona opciones de compilaci�n para especificar la localizaci�n de ficheros de bloqueo. Es probable que aparecer� como una variable llamada LOCKDIR en el Makefile o en alg�n fichero de configuraci�n de cabecera. Si usted mismo compila el software, la mejor opci�n es modificar esto de acuerdo al lugar definido en el FSSTND. Si usa usted binarios precompilados y no est� seguro de d�nde escribir� el programa sus ficheros de bloqueo, quiz� esta orden pueda proporcionarle alguna pista:
strings binaryfile | grep lock |
Los n�meros menores son id�nticos para ambos tipos de dispositivos serie. Si tiene usted su m�dem conectado en un puerto desde COM1: a COM4:, su n�mero menor ser� el n�mero de puerto COM m�s 63. Si emplea usted hardware serie especial, como controladores de m�ltiples puertos serie de gran rendimiento, probablemente necesite crear ficheros especiales de dispositivo para �l; probablemente no emplee el manejador est�ndar de dispositivo. El Serial-HOWTO debe poder ayudarle a encontrar los detalles espec�ficos.
Supongamos que su m�dem est� en COM2:. Su n�mero menor ser� 65, y su n�mero mayor ser� 4 para usos normales. Deber�a existir un dispositivo llamado ttyS1 que tiene estos n�meros. Liste los ttys serie del directorio /dev. La quinta y sexta columna muestran respectivamente el n�mero mayor y el n�mero menor:
$ ls -l /dev/ttyS*
0 crw-rw---- 1 uucp dialout 4, 64 Oct 13 1997 /dev/ttyS0
0 crw-rw---- 1 uucp dialout 4, 65 Jan 26 21:55 /dev/ttyS1
0 crw-rw---- 1 uucp dialout 4, 66 Oct 13 1997 /dev/ttyS2
0 crw-rw---- 1 uucp dialout 4, 67 Oct 13 1997 /dev/ttyS3 |
Si no hay ning�n dispositivo con n�mero mayor 4 y n�mero menor 65, necesitar� crear uno. Pase a modo superusuario y escriba:
# mknod -m 666 /dev/ttyS1 c 4 65
# chown uucp.dialout /dev/ttyS1 |
Hay quien sugiere crear /dev/modem como un enlace simb�lico al dispositivo de m�dem para que los usuarios ocasionales no tengan que recordar el menos intuitivo ttyS1. Pero no se puede utilizar modem en un programa y el fichero real de dispositivo en otro. Sus ficheros de bloqueo tendr�an nombres diferentes, y esto har�a fallar al mecanismo de bloqueo.