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

Encontré buena información sobre herramientas inalámbricas en esta 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 las herramientas inalámbricas mismas. 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 lanzada fue v29 pero Ubuntu 14 y 16 parecen contener la v30 beta iwconfig -v ( iwconfig -v ).

Tengo curiosidad sobre lo que sucedió con este package? ¿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 el desarrollo se detuviera? 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 reference histórica.

Historial de versiones

Historial de versiones

Las herramientas inalámbricas están en desuso en favor de iw porque las extensiones inalámbricas se han desaprobado a favor de la nueva interfaz nl80211 para dispositivos inalámbricos. La documentation del núcleo para iw dice eso.

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

La razón por la cual Ubuntu (y prácticamente 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, que causó que iwconfig fallara si había demasiadas networkinges en el área debido a un buffer rebosar. El repository Github para herramientas inalámbricas no muestra esto, pero aquí está el parche relevante de Arch

Debería haber leído la Q / A que mejor he vinculado porque había un enlace a una página donde se explicaba por qué se abandonó este proyecto :

¿Estamos siendo más desarrollados?

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

Por qué estamos abandonando

WEs se basan en ioctl() y aunque ioctl() se ha utilizado y todavía se está utilizando como un transporte estándar para la comunicación entre el usuario ← → kernelspace se prefieren los nuevos transportes por varias razones.

Desde los controlleres de dispositivos Linux – 3ª 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 list de llamadas al sistema Unix debido a los puntos, que generalmente marcan la function como que tiene un número variable de arguments. En un sistema real, sin embargo, una llamada al sistema no puede tener una cantidad variable de arguments. Las llamadas al sistema deben tener un prototipo bien definido, porque los progtwigs de usuario solo pueden acceder a ellas a través de "puertas" de hardware. Por lo tanto, los puntos del prototipo no representan un número variable de arguments, sino un único argumento opcional, tradicionalmente identificado como char *argp . Los puntos están simplemente allí para evitar la verificación de types durante la compilation.

También dice:

La naturaleza no estructurada de la ioctl ha causado que caiga en desgracia entre los desarrolladores de kernel. Cada command ioctl es, esencialmente, una llamada al sistema separada, por lo general no documentada, y no hay forma de auditar estas llamadas de ninguna manera. También es difícil hacer que los arguments ioctl no estructurados funcionen de manera idéntica en todos los sistemas; por ejemplo, considere sistemas de 64 bits con un process de espacio de usuario ejecutándose en modo de 32 bits.

¿Qué es el reemploop de Wireless-Extensions?

El nuevo desarrollo debe centrarse en cfg80211 y nl80211.


Nota al margen : parece que Jean Tourrhiles trabajó en el proyecto desde 1997-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