À la question de Linux (L)

Nous partons du fait que vous obtenez un système d'exploitation à part entière, en payant immédiatement tout pour tout. (Bill Gates en réponse à une question sur la concurrence avec L.)


Plus j'en apprends sur Linux, moins je déteste B.G.


Eh bien, en fait, je n'ai jamais ressenti de sentiments aussi forts pour lui, je commence juste à mieux comprendre pourquoi la société qui produit Windows prend de l'argent. Et il devient plus clair pourquoi les consommateurs préfèrent payer Bill (il y a, bien sûr, des options ici, vous comprenez), au lieu d'utiliser l'alternative gratuite («c'est-à-dire gratuite»). Mais commençons dans l'ordre et considérons deux épisodes d'interaction avec L.

Récemment, L fonctionnait sur les appareils que je développe (sous l'une ou l'autre de ses formes, eh bien, vous comprenez ...), dans le cadre desquels un logiciel spécifique est exécuté. Et donc, au cours de l'interaction avec des périphériques externes (claviers spécialisés), des artefacts intéressants du comportement du système d'exploitation ont été découverts, ce qui a conduit aux pensées énoncées dans l'épigraphe.

Épisode 1 - lors de la correction du programme du clavier USB, un défaut «accidentel, involontaire» a été introduit, ce qui a entraîné la défaillance du descripteur de chaîne de l'appareil. Pour ceux qui ne sont pas très connectés avec USB, l'explication nécessaire - un descripteur de chaîne - est une partie facultative de la description de l'appareil, qui est destinée uniquement à visualiser le type d'appareil et le fabricant des utilitaires système. Néanmoins, ce n'est pas une excuse pour les programmeurs et de telles erreurs ne devraient pas être faites, mais tout se passe dans la vie. Comment un hôte exécutant un système d'exploitation sain peut-il réagir si un tel périphérique incorrect lui est connecté?

Personnellement, je vois 3 stratégies possibles:

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

PNP: Il convient de noter que la norme pour l'interface ne prévoit que le besoin (figure 8.31 à la page 223), en attendant le message d'entrée, de contrôler l'heure et de traiter le délai d'attente, comme l'une des erreurs possibles - répétez la demande 3 fois, puis donnez un signal sur l'échec de la transaction. Les autres actions de l'hôte sont déterminées par la mise en œuvre. Eh bien, au moins, je n'ai pas trouvé de telles informations dans la norme, bien que ce ne soit pas définitif.

Ainsi, les développeurs de L ne se sont pas limités aux solutions qui se trouvaient à la surface et sont allés plus loin, ayant trouvé une manière inhabituellement intéressante et, nous n'aurons pas peur de ce mot, idiot très créatif:

4. répétez la demande un certain nombre de fois, après l'épuisement de laquelle marquer l'appareil comme défectueux puis l'éteindre .

Jusqu'à présent, rien de criminel, si ce n'est pour un petit détail («et tout le reste est des nuances») - tandis que l'hôte L répète la demande ci-dessus, il monopolise l'accès via le bus (très probablement le délai d'attente dans le matériel ne démarre pas ou l'interruption de celui-ci n'est pas traitée) et tous (!!!) les autres périphériques USB sont inactifs. Ce processus prend environ une douzaine de secondes, pendant lesquelles tous les appareils ne sont pas disponibles - déjà pas mal. Et voici la cerise sur le gâteau - après des tentatives épuisantes de lire le descripteur de chaîne à partir du mauvais clavier, les paquets cessent généralement de lui arriver, après 2 minutes, il comprend "quelque chose s'est mal passé" et essaie de se présenter à l'hôte à nouveau en se reconnectant, provoquant la répétition du processus. Les résultats sont compréhensibles - travailler avec le bus n'est tout simplement pas possible si vous n'êtes pas prêt à utiliser le mode hoquet.Une solution inhabituellement originale, mais cela (originalité) est son seul avantage.

Mes connaissances Linux, après avoir démontré ce phénomène, ont d'abord essayé de l'expliquer dans le style de "ce n'est pas un bug, c'est une telle fonctionnalité" (ou plutôt, au début, comme ils l'ont accepté, ont suggéré de reconstruire le noyau avec les derniers correctifs, c'est généralement une réponse universelle à tout message dans la communauté L à propos d'une erreur possible), puis ils ont dit que, oui, le comportement est incorrect, mais, probablement, quelque part dans les fichiers de configuration de l'assemblage, il y a un indicateur, une réinitialisation ou un paramètre qui, vous pouvez désactiver ce comportement du système. Si cela est vrai, alors le seul nom pour le drapeau que je peux offrir est (en russe): "Je veux vraiment_OS_be_being_being_something_failing_string_descriptor_as_hysterichka", dans le style "Jusqu'à ce que cette garce me dise son nom, je ne demanderai à personne de vous parler", Désolé pour mon français. Eh bien, même si c'est le cas, il y a un tel drapeau,Par défaut, le système d'exploitation ne doit-il pas être collecté en mode normal et non perverti? Pour une raison quelconque, Windows fait exactement cela. Bien sûr, vous devez regarder le texte source de l'hôte L (très probablement, un pilote USB spécifique) et déterminer s'il existe un tel indicateur et comment obtenir un comportement système similaire, mais pour les raisons énumérées ci-dessous, cela n'a pas été fait, nous nous limitons donc à déclarer le fait .

La deuxième fonctionnalité (beaucoup plus comme une erreur, car dans le premier cas, l'appareil était incorrect, ce que j'ai immédiatement souligné) a été détectée après la correction de l'erreur de programme de l'appareil et nous avons commencé à travailler plus loin.

Le fait est que sur l'appareil conçu, il y avait deux contrôleurs qui implémentaient chacun les fonctions du joystick et du clavier, tandis qu'un traitait le côté gauche du clavier et le second le droit. Mais un bouton sur le panneau avant était connecté aux deux contrôleurs, car il y avait le marquage "FEU" dessus et les résultats d'une défaillance d'un contrôleur seraient très désagréables. Lorsque vous avez cliqué sur ce bouton, les deux contrôleurs ont produit un symbole «espace» et tout allait bien jusqu'à ce que nous remarquions que parfois (~ 10% des cas) après avoir relâché le bouton A, il continue d'être considéré comme appuyé et l'application passe en mode de tir continu. En même temps, appuyer et abaisser à nouveau le bouton ramène le système en mode normal.

Il a été suggéré que des événements rapprochés (dans le temps) du clavier puissent être ignorés, dans ce cas un message sur la libération d'un bouton.

En outre, diverses mesures ont été prises pour déterminer la cause du dysfonctionnement, mais leur description va au-delà de la portée et du sujet de cet article et sera (j'espère) décrite séparément. Mais le processus de découverte des causes d'une erreur si simple (à première vue) en soi nécessitait des efforts tels que tout désir de comprendre la raison du premier bogue décrit dans le message a été perdu.
Revenant à l'épigraphe, je dois dire que sur Windows 7 ce défaut n'a pas été observé pendant au moins 100 clics, ce qui indique la stabilité de cet OS sur ce facteur. Encore une fois, je n'ai pas vu le code source, mais le comportement du programme parle de lui-même.

Il est peu probable que les qualifications des développeurs Windows dépassent considérablement celles de la communauté open source et la question, apparemment, ne concerne que les tests, qui sont effectués sans ambiguïté dans un plus grand volume (et avec une qualité supérieure), lorsque des personnes qui reçoivent de l'argent pour leur travail y participent ( outre la satisfaction morale).

Je dois admettre que le comportement de A, au moins dans les situations décrites, est mieux défini par l'expression `` ça marche '', qui ne peut pas être considérée comme acceptable pour un système d'exploitation qui prétend être fiable et répandu, c'est pourquoi mon attitude envers B.G. À la suite de cet épisode, il s'est amélioré, car il n'est certainement pas à blâmer pour ce qui se passe (bien qu'il puisse y avoir des opinions différentes).

All Articles