¿Por qué las herramientas inalámbricas versión 30 se convirtieron en una versión beta permanente?

He encontrado una buena información acerca de las herramientas inalámbricas en este Q / A . Aparentemente fue introducido al kernel de Linux en 1997 por Jean Tourrhiles patrocinado por Hewlett Packard.

Editar: Parece que WE (Extensiones inalámbricas) fue agregado al Kernel por Tourrhiles, no por las herramientas inalámbricas en sí. Las herramientas están disponibles en la mayoría de las distribuciones como la forma principal de comunicarse con WE. Puedes ver WE en el kernel en /proc/net/wireless.

La última versión lanzadav29 aún era Ubuntu 14 y 16 parece contener la v30beta ( iwconfig -v).

Tengo curiosidad sobre lo que pasó con este paquete? ¿Por qué la versión "beta" 30 se convirtió en la versión estándar de facto utilizada?

¿HP dejó de financiar a Jean Tourrhiles para que se detuviera el desarrollo? O tal vez se decidió que era lo suficientemente estable como para detener el desarrollo, pero si ese fuera el caso, ¿por qué 30 seguiría siendo una versión beta?

Encontré esta página de Github pero parece ser solo para referencia histórica.

Historial de versiones

Las herramientas inalámbricas están en desuso iwporque las extensiones inalámbricas están en desuso en favor de la nueva interfaz nl80211 para dispositivos inalámbricos. La documentación del kernel para iw dice eso.

Sin embargo, nl80211 está en desarrollo activo y no todos los controladores se han migrado a él. Todavía se requieren herramientas inalámbricas para dispositivos que no se han migrado desde extensiones inalámbricas.

La razón por la que Ubuntu (y casi todas las distribuciones que conozco) proporcionan la versión 30 beta es porque esa versión corrige un error crítico que estaba en la versión 29, lo que hacía que el iwconfig fallara si había demasiadas redes en el área debido a un búfer Desbordamiento. El repositorio de Github para herramientas inalámbricas no muestra esto, pero aquí está el parche relevante de Arch

Debería haber leído las preguntas y respuestas que he vinculado mejor porque había un enlace a una página que explicaba por qué se abandonó este proyecto :

¿Estamos siendo desarrollados más?

No, no es. Solo se aceptan las correcciones de errores para WE.

¿Por qué estamos abandonando a WE?

Los WE se basan ioctl()y, aunque ioctl()se han utilizado y se siguen utilizando como transporte estándar para la comunicación entre el usuario ← → kernelspace, se prefieren nuevos transportes por varias razones.

Desde controladores de dispositivos Linux - 3ra edición:

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

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

El prototipo se destaca en la lista de llamadas al sistema Unix debido a los puntos, que generalmente marcan la función como que tiene un número variable de argumentos. Sin embargo, en un sistema real, una llamada al sistema no puede tener un número variable de argumentos. Las llamadas al sistema deben tener un prototipo bien definido, porque los programas de usuario solo pueden acceder a ellas a través de "puertas" de hardware. Por lo tanto, los puntos en el prototipo representan no un número variable de argumentos, sino un solo argumento opcional, tradicionalmente identificado como char *argp. Los puntos simplemente están allí para evitar la verificación de tipos durante la compilación.

También dice:

La naturaleza desestructurada de la ioctlllamada ha hecho que caiga en desgracia entre los desarrolladores del kernel. Cada ioctlcomando es, esencialmente, una llamada de sistema separada, generalmente indocumentada, y no hay forma de auditar estas llamadas de manera integral. También es difícil hacer que los ioctlargumentos no estructurados funcionen de manera idéntica en todos los sistemas; por ejemplo, considere los sistemas de 64 bits con un proceso de espacio de usuario que se ejecuta en modo de 32 bits.

¿Qué es el reemplazo de extensiones inalámbricas?

El nuevo desarrollo debe centrarse en cfg80211 y nl80211.

Nota al margen : Parece que Jean Tourrhiles trabajó en el proyecto entre 1997 y 2009. Encontré un artículo de 2014 que decía que Tourrhiles todavía estaba en HP, trabajando en un proyecto llamado OpenFlow :

Jean Tourrhiles de HP también preside el Grupo de trabajo de extensibilidad, que funciona como un "editor" para impulsar la última tecnología en futuras versiones de OpenFlow