Acceso a Dispositivos Serie

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, ttyS 1, 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.
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 si. 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 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 ttyS 1, por ejemplo, es LCK.. ttyS 1. 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 Makef¡le 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
Si el lugar encontrado no es compatible con el resto de su sistema, puede tratar de crear un enlace simbólico desde el directorio de bloqueo que pretende usar el binario hacia /var/lock. No es una solución muy elegante, pero funcionará.