io - que - ¿Cuáles son las consecuencias de llamar a write() con longitud cero?
latitud y longitud ejemplos (6)
En un nivel bastante alto en la función de escritura () de Linux, filtra las solicitudes para escribir buffers de longitud 0. Lo cual tiene sentido. ¿Quién querría que el sistema operativo perdiera tiempo para explorar capas solo para determinar que no hay trabajo por hacer?
Pues yo.
Está relacionado con esta pregunta ; y el descubrimiento de que el driver I2C con muchos bits dará un código de retorno potencialmente útil si la dirección (enviada en el bus antes de los datos) dará un error si el handshaking es incorrecto.
Uno podría enviar datos ficticios después de la dirección, pero no con el dispositivo que estoy usando. (Quizás voy a intentar leer ...).
Entonces la pregunta es: ¿Qué tipo de infierno se desencadenaría si el kernel permitiera escribir cero (0) largos?
¿Qué significaría una escritura de longitud cero? En general, escribir significa transferencia de datos ... y estoy seguro de que causarán más problemas al no verificarlo y, por lo tanto, atrapar la mayoría de las malas entradas para los controladores. y
si se trata de una llamada de "haz esto" de un solo bit de información, creo que ioctl es el camino a seguir. No es bonito, pero ¿qué puedes hacer?
Alternativamente, tome la opción nuclear, use mmap () y mueva todo al espacio de usuario. Bajo costo indirecto, y puede escribir un código de inserción clásico como "escriba X en este registro", que casi parece ser lo que necesita.
Lo que estás describiendo equivale esencialmente al mismo tipo de mal que infesta varias API de Windows que necesitan cantidades de memoria impredecibles. La práctica es llamarlos sin búfer para colocar su trabajo, hacen el trabajo de todos modos, sin almacenar los resultados, pero contando el número de bytes que necesitarían en el camino. Luego asigna un búfer de ese tamaño y vuelve a llamar a la función con el búfer, sabiendo el tamaño.
Esto es indescriptiblemente malvado. Es el equivalente de una computadora de programación de una burocracia deteriorada, donde cada departamento requiere que llene un formulario que tenga la misma información que el que le dio al departamento anterior, pero dado que hay información diferente en cada formulario, ellos no solo tomarán una copia del formulario que le dieron a los otros muchachos. Ptui!
El tiempo del programador es caro, el tiempo de CPU es barato. Exigir a los programadores que escriban la misma llamada API N veces para suscitar algún estado mundial que la API misma podría resolver por sí misma para voltear esto en su cabeza.
La mejor práctica, entonces, es hacer que el conductor haga todo lo posible para asegurarse de que su escritura () tenga éxito. Si es posible predecir de antemano que no puede tener éxito al verificar algún estado del mundo, tal vez debería ser un ioctl ().
Me estremezco al sugerir un ioctl () pero ¿no sería una mejor interfaz para obtener información de estado sobre la interfaz?
Muy poco, creo, es posible que una escritura de longitud cero se bloquee si el búfer al que está escribiendo tiene cero espacio disponible también, en algunos controladores. Si se rechazan las escrituras de duración cero, se simplificará la tarea en casos como ese, y se evitará un gran desperdicio de trabajo.
¿Por qué no simplemente quitar ese cheque y ver qué tipo de infierno realmente se desata? :)
Solo por el bien del cierre, voy con la idea de Warren Young de actualizar el controlador y publicar el parche (cuando tenga una ronda tuit ).
no es una respuesta seria: es posible que obtenga un programa como toque : P