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

Question

Encontré buena información sobre herramientas inalámbricas en estePreguntas y respuestas. Aparentemente fue introducido en el kernel de Linux en 1997 por Jean Tourrhiles patrocinado por Hewlett Packard.

Editar: Parece que Tourrhiles agregó WE (Extensiones inalámbricas) al Kernel, no 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 NOSOTROS. Puedes ver WE en el kernel en /proc/net/wireless.

Elúltima versión lanzadaTodavía v29Ubuntu 14 y 16 parecen contener la v30versión beta ( iwconfig -v).

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

¿HP dejó de financiar a Jean Tourrhiles y por eso se detuvo 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é estopágina de githubpero parece ser sólo una referencia histórica.

Historial de versiones

Answer 1

Las herramientas inalámbricas están en desuso en favor deiw porque las extensiones inalámbricas han quedado en desuso en favor de la nueva interfaz nl80211 para dispositivos inalámbricos. Eldocumentación del kernel para iwdice que.

Sin embargo, nl80211 está en desarrollo activo y no todos los controladores se han migrado a él. Aún se requieren herramientas inalámbricas para los 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 causaba que iwconfig fallara si había demasiadas redes en el área debido a un buffer. Desbordamiento. El repositorio de Github para herramientas inalámbricas no muestra esto, pero aquí está el parche relevante deArco

Answer 2

Debería haber leído mejor las preguntas y respuestas que vinculé porque había un enlace a una página que discutíapor qué este proyecto fue abandonado:

¿Estamos NOSOTROS desarrollándonos aún más?

No, no es. Para NOSOTROS solo se aceptan correcciones de errores.

¿Por qué estamos abandonando a NOSOTROS?

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

De controladores 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 lista de llamadas al sistema Unix debido a los puntos, que generalmente marcan que la función 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 sólo pueden acceder a ellas a través de “puertas” de hardware. Por lo tanto, los puntos en el prototipo no representan un número variable de argumentos sino un único argumento opcional, tradicionalmente identificado como char *argp. Los puntos simplemente están ahí para evitar la verificación de tipos durante la compilación.

También afirma:

La naturaleza no estructurada de la ioctlllamada ha hecho que pierda el favor de los desarrolladores del kernel. Cada ioctlcomando es, esencialmente, una llamada al sistema separada, generalmente no documentada, 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 sistemas de 64 bits con un proceso de espacio de usuario ejecutándose en modo de 32 bits.

¿Qué es el reemplazo de Wireless-Extensions?

El nuevo desarrollo debería centrarse en cfg80211 y nl80211.

---

Nota al margen:Parece que Jean Tourrhiles trabajó en el proyecto aproximadamente entre 1997 y 2009. encontré unartículo de 2014diciendo que Tourrhiles todavía estaba en HP, trabajando en un proyecto llamadoflujo abierto:

Jean Tourrhiles de HP también preside el Grupo de Trabajo de Extensibilidad, que trabaja como "editor" para impulsar la última tecnología en futuras versiones de OpenFlow.