Pourquoi la version 30 des outils sans fil est-elle devenue une version bêta permanente?

J'ai trouvé quelques bonnes informations sur les outils sans fil dans ce Q / A . Apparemment, il a été introduit dans le noyau Linux en 1997 par Jean Tourrhiles parrainé par Hewlett Packard.

Edit: Il semble que WE (extensions sans fil) ait été ajouté au noyau par Tourrhiles, pas les outils sans fil eux-mêmes. Les outils sont disponibles sur la plupart des distributions comme principal moyen de communiquer avec WE. Vous pouvez voir WE dans le noyau à /proc/net/wireless.

La dernière version publiée était v29encore Ubuntu 14 & 16 semble contenir la v30bêta ( iwconfig -v).

Je suis curieux de savoir ce qui est arrivé à ce package? Pourquoi la version "beta" 30 est-elle devenue la version standard de facto utilisée?

HP a-t-il cessé de financer Jean Tourrhiles pour que le développement s'arrête? Ou peut-être a-t-on décidé qu'il était suffisamment stable pour arrêter le développement, mais si c'était le cas, pourquoi 30 serait-il toujours une version bêta?

J'ai trouvé cette page Github mais elle semble être pour référence historique seulement.

Historique des versions

Les outils sans fil sont déconseillés au profit de iwparce que les extensions sans fil ont été déconseillées au profit de la nouvelle interface nl80211 pour les périphériques sans fil. La documentation du noyau pour iw le dit.

Cependant, nl80211 est en cours de développement actif et tous les pilotes n'y ont pas été migrés. Des outils sans fil sont toujours requis pour les appareils qui n'ont pas été migrés à partir d'extensions sans fil.

La raison pour laquelle Ubuntu (et à peu près toutes les distributions que je connais) fournit la version 30 bêta parce que cette version corrige un bogue critique qui était dans la version 29, ce qui provoquait l'échec d'iwconfig s'il y avait trop de réseaux dans la zone en raison d'un tampon débordement. Le dépôt Github pour les outils sans fil ne le montre pas, mais voici le patch pertinent d' Arch

J'aurais dû lire le Q / A que j'ai mieux lié car il y avait un lien vers une page expliquant pourquoi ce projet a été abandonné :

NOUS nous développons-nous encore?

Non ça ne l'est pas. Seules les corrections de bugs sont acceptées pour WE.

Pourquoi nous abandonnons NOUS

Les WE sont basés sur ioctl()et bien qu'ils ioctl()aient été utilisés et sont toujours utilisés comme moyen de transport standard pour la communication entre les utilisateurs ← → kernelspace, de nouveaux transports sont préférés pour plusieurs raisons.

Depuis les pilotes de périphériques Linux - 3e édition:

In user space, the ioctl system call has the following prototype:

int ioctl(int fd, unsigned long cmd, ...);

Le prototype se démarque dans la liste des appels système Unix en raison des points, qui marquent généralement la fonction comme ayant un nombre variable d'arguments. Dans un système réel, cependant, un appel système ne peut pas avoir réellement un nombre variable d'arguments. Les appels système doivent avoir un prototype bien défini, car les programmes utilisateur ne peuvent y accéder que via des «portes» matérielles. Par conséquent, les points dans le prototype ne représentent pas un nombre variable d'arguments mais un seul argument facultatif, traditionnellement identifié comme char *argp. Les points sont simplement là pour empêcher la vérification de type pendant la compilation.

Il indique également:

La nature non structurée de l' ioctlappel l'a fait tomber en disgrâce parmi les développeurs du noyau. Chaque ioctlcommande est, pour l'essentiel, un appel système distinct, généralement non documenté, et il n'y a aucun moyen d'auditer ces appels d'une manière complète. Il est également difficile de faire fonctionner les ioctlarguments non structurés de manière identique sur tous les systèmes; par exemple, considérons les systèmes 64 bits avec un processus d'espace utilisateur s'exécutant en mode 32 bits.

Qu'est-ce que le remplacement des extensions sans fil

Les nouveaux développements devraient se concentrer sur cfg80211 et nl80211.

Note latérale: Il semble que Jean Tourrhiles ait travaillé sur le projet vers 1997-2009. J'ai trouvé un article de 2014 disant que Tourrhiles était toujours chez HP, travaillant sur un projet appelé OpenFlow :

Jean Tourrhiles de HP préside également le groupe de travail sur l'extensibilité, qui fonctionne comme un «éditeur» pour intégrer les dernières technologies dans les futures versions d'OpenFlow.