ioctl

ioctl es una llamada de sistema en Unix que permite a una aplicación controlar o comunicarse con un driver de dispositivo, fuera de los usuales read/write de datos. Esta llamada se originó en la versión 7 del AT&T Unix. Su nombre abrevia la frase input/output control. Proporciona una interfaz para controlar el comportamiento de los dispositivos y de sus descriptores, y para configurar los servicios subyacentes. Terminales, descriptores de archivos, sockets, incluso las unidades de cinta pueden contar llamadas ioctl definidas para ellos mismos y para obtener más información tendrá que acudir al manual de consulta del dispositivo mas. POSIX define únicamente ioctl para los flujos.

El kernel generalmente envía un ioctl directamente al driver, el cual puede interpretar el número de requerimiento y datos en cualquier forma requerida. Los escritores del driver documentan cada número de requerimiento del driver para ese driver particular, y los proveen de constantes en el archivo de cabeceras (*.h)

Algunos sistemas tienen convenciones en su codificación, dentro del número de codificación, el tamaño de los datos a ser transferidos desde o hacia el driver del dispositivo, la dirección de la transferencia de datos y la identidad del driver implementando el requerimiento.

Independientemente de que esa convención se cumpla o no, el kernel y el driver colaboran para entregar un código de error uniforme (señalados por la constante simbólica ENOTTY) a una aplicación que haga un requerimiento al driver que no reconozca.

El nemónico ENOTTY (tradicionalmente asociado con el mensaje textual «Not a typerwriter») viene del hecho de que en los sistemas iniciales que incorporaba una llamada ioctl, solo el dispositivo teletipo (tty) planteaba este error. A través del nemónico simbólico es ajustado por los requerimientos de compatibilidad; algunos sistemas modernos muy útilmente prestan un mensaje más general, como: «Inappropriate device control operation», o la localización del mismo.

TCSETS ejemplifica un ioctl en un puerto serial. Las llamadas de lectura y escritura normales en un puerto serial reciben y envían paquetes de datos. Una llamada ioctl(fd, TCSETS, data), independiente de las llamadas normales I/O, controla varias opciones del controlador, como la manipulación de caracteres especiales, o las señales de salida en el puerto (por ejemplo, la señal DTR).

Un programa de copia de archivos

Con la información que hemos asimilados sobre llamadas la sistema open, read y write podemos escribir un programa de bajo nivel que llamaremos copia_archivo.c que nos servirá para copiar un archivo a otro, carácter a carácter.

1. En primer lugar tendremos que crear un archivo de entrada de comprobación y denominado file.in.
   
2. Después creamos y compilamos copia_archivo.c
   y compilamos:
3. Al ejecutar el programa obtendremos el resultado:

Vemos que el programa a creado el archivo file.out el cual contiene la copia del archivo file.in. Podemos medir cuanto tarda el programa usando la variable TIMEFORMAT que usaremos para invalidar la llamada POSIX predeterminada de TIME ya que no incluye el uso de la CPU.

En el siguiente ejemplo usamos la prestación time para medir cuánto tarda el programa en ejecutarse.

Podemos ver que el archivo de entrada file.in, se copió correctamente a file.out, que fue creado con permisos de lectura/escritura para el propietario. Sin consumir tiempo en su ejecución. Para comparar una comprobación similar usando un kernel inferior a 2.6 seguramente tardaría más en ejecutar el programa.

En mi equipo, vemos la versión de kernel que posee actualmente, y muestra lo que duró la copia del archivo.

Otro programa de copia de archivos

Podemos mejorar las cosas copiando bloques más extensos. Observaremos el programa modificado, copia_bloque.c, que copia los archivos en bloques de 1K, usando de nuevo las llamadas al sistema:

Probaremos el programa, pero antes tenemos que borrar el archivo files.out:

El programa es mucho más rápido ejecutándose en centésimas de segundos, por supuesto, el tiempo depende del sistema, pero lo que demuestran es que las llamadas al sistema tienen unos costes perceptibles, por eso merece la pena optimizar su uso.