Get best of the week

A la pregunta de Linux (L)

Procedemos del hecho de que obtienes un sistema operativo completo, que inmediatamente paga por completo todo. (Bill Gates en respuesta a una pregunta sobre la competencia con L.)


Cuanto más aprendo sobre Linux, menos odio a B.G.


Bueno, en realidad, nunca sentí sentimientos tan fuertes por él, solo estoy empezando a entender mejor por qué la compañía que produce Windows toma dinero. Y se hace más claro por qué los consumidores prefieren pagar Bill (hay, por supuesto, opciones aquí, entiendes), en lugar de usar la alternativa gratuita ("es decir, gratis"). Pero comencemos en orden y consideremos dos episodios de interacción con L.

Recientemente, L ha estado funcionando en los dispositivos que desarrollo (en una u otra de sus formas, bueno, ya entiendes ...), en el marco del cual se ejecuta un software especial. Y así, en el proceso de interactuar con dispositivos externos (teclados especializados), se descubrieron artefactos interesantes del comportamiento del sistema operativo, lo que condujo a los pensamientos expresados ​​en el epígrafe.

Episodio uno: durante la corrección del programa de teclado USB, se introdujo un defecto "accidentalmente y no intencionalmente" que condujo a la falla del descriptor de cadena del dispositivo. Para aquellos que no están muy conectados con USB, la explicación necesaria, un descriptor de cadena, es una parte opcional de la descripción del dispositivo, que está destinada únicamente a visualizar el tipo de dispositivo y el fabricante de las utilidades del sistema. Sin embargo, esto no es una excusa para los programadores y no se deben cometer tales errores, sino que todo sucede en la vida. ¿Cómo puede reaccionar un host que ejecuta un SO sano si se conecta un dispositivo incorrecto?

Personalmente, veo 3 estrategias posibles:

  1. , , — , , 7, ;
  2. , , — ;
  3. , , — , , USB ( ).

PNP: Debe tenerse en cuenta que el estándar para la interfaz solo satisface la necesidad (Figura 8.31 en la página 222), mientras espera el mensaje de entrada, para controlar el tiempo y procesar el tiempo de espera, como uno de los posibles errores: repita la solicitud 3 veces y luego dé una señal sobre el fallo de la transacción. Otras acciones del host están determinadas por la implementación. Bueno, al menos, no encontré esa información en el estándar, aunque esto no es definitivo.

Por lo tanto, los desarrolladores de L no se limitaron a las soluciones que se encontraban en la superficie y profundizaron, habiendo ideado una forma inusualmente interesante y, no temeremos a esta palabra, de manera idiota y muy creativa:

4. repita la solicitud un cierto número de veces, después del agotamiento de las cuales marcar el dispositivo como defectuoso y luego apagarlo .

Hasta ahora, nada criminal, si no fuera por un pequeño detalle ("todo lo demás son matices"), mientras que el host L repite la solicitud anterior, monopoliza el acceso a través del bus (lo más probable es que el tiempo de espera en el hardware no se inicie o la interrupción no se procese) y Todos los demás dispositivos USB están inactivos. Este proceso lleva aproximadamente una docena de segundos, durante el cual todos los dispositivos no están disponibles, ya no está mal. Y aquí está la guinda del pastel: después de agotar los intentos de leer el descriptor de cadena desde el teclado incorrecto, los paquetes generalmente dejan de llegar a él, después de 2 minutos, comprende que algo salió mal e intenta presentarse al host nuevamente al volver a conectar, haciendo que el proceso se repita. Los resultados son comprensibles: simplemente no es posible trabajar con el bus si no está listo para usar el modo hipo.Una solución inusualmente original, pero esta (originalidad) es su única ventaja.

Mis conocidos de Linux, después de demostrar este fenómeno, primero intentaron explicarlo al estilo de "esto no es un error, es una característica" (o más bien, al principio, como aceptaron, sugirieron reconstruir el núcleo con los últimos parches, esta es generalmente una respuesta universal a cualquier mensaje en la comunidad L sobre un posible error), y luego dijeron que sí, el comportamiento es incorrecto, pero, probablemente, en algún lugar de los archivos de configuración del ensamblaje hay un indicador, reinicio o configuración que puede desactivar este comportamiento del sistema. Si esto es cierto, entonces el único nombre para la bandera que puedo ofrecer es (en ruso): "Realmente quiero_OS_be_being_being_something_failing_string_descriptor_as_hysterichka", en el estilo "Hasta que esta perra me diga su nombre, no le pediré a nadie que hable con usted". lo siento por mis francés. Bueno, incluso si este es el caso y tal bandera es,¿De manera predeterminada, el sistema operativo no debe recopilarse en modo normal, no pervertido? Por alguna razón, Windows hace exactamente eso. Por supuesto, debe mirar el código fuente del host L (muy probablemente, un controlador USB específico) y determinar si existe dicho indicador y cómo lograr un comportamiento similar del sistema, pero por las razones que se enumeran a continuación, esto no se hizo, por lo que nos limitamos a afirmar el hecho .

La segunda característica (mucho más como un error, porque en el primer caso el dispositivo era incorrecto, lo que enfaticé de inmediato) se detectó después de que se solucionó el error del programa del dispositivo y comenzamos a trabajar más.

El hecho es que en el dispositivo diseñado había dos controladores que implementaban las funciones del joystick y del teclado, mientras que uno procesaba el lado izquierdo del teclado y el segundo procesaba el derecho. Pero un botón en el panel frontal estaba conectado a ambos controladores, ya que tenía la marca "FUEGO" y los resultados de la falla de un controlador serían muy desagradables. Cuando hizo clic en este botón, ambos controladores produjeron un símbolo de "espacio" y todo estuvo bien hasta que notamos que a veces (~ 10% de los casos) después de soltar el botón A, se sigue presionando y la aplicación entra en modo de disparo continuo. Al mismo tiempo, al presionar y bajar el botón nuevamente, el sistema volvió al modo normal.

Se ha sugerido que se pueden omitir eventos espaciados (en el tiempo) desde el teclado, en este caso un mensaje sobre la liberación de un botón.

Además, se tomaron varias medidas para determinar la causa del mal funcionamiento, pero su descripción va más allá del alcance y el tema de esta publicación y (espero) se describirá por separado. Pero el proceso de descubrir las causas de un error tan simple (a primera vista) en sí mismo requirió tales esfuerzos que se perdió cualquier deseo de comprender la razón del primer error descrito en la publicación.
Volviendo al epígrafe, debo decir que en Windows 7 este defecto no se observó durante al menos 100 clics, lo que indica la estabilidad de este sistema operativo en este factor. Nuevamente, no vi el código fuente, pero el comportamiento del programa habla por sí mismo.

Es poco probable que las calificaciones de los desarrolladores de Windows excedan significativamente la de la comunidad de código abierto y la pregunta, aparentemente, es solo como prueba, que se lleva a cabo sin ambigüedades en un volumen mayor (y con mayor calidad), cuando las personas que reciben dinero por su trabajo se dedican a ello ( Además de la satisfacción moral).

Tengo que admitir que el comportamiento de A, al menos en las situaciones descritas, se define mejor con la frase "funciona", que no puede considerarse aceptable para un sistema operativo que dice ser confiable y generalizado, por lo que mi actitud hacia B.G. Como resultado de este episodio, mejoró, ya que definitivamente no tiene la culpa de lo que está sucediendo (aunque puede haber opiniones diferentes).

More articles:


All Articles