Почему беспроводные инструменты версии 30 стали постоянной бета-версией?

Я нашел хорошую информацию о беспроводных инструментах в этом Q / A . По-видимому, он был представлен ядру Linux в 1997 году Жаном Туррихесом, спонсируемым Hewlett Packard.

Изменить: Кажется, мы (беспроводные расширения) был добавлен в ядро ​​Tourrhiles, а не сами инструменты беспроводной связи. Инструменты доступны в большинстве дистрибутивов как основной способ общения с WE. Вы можете увидеть МЫ в ядре на /proc/net/wireless.

Последняя версия выпущена была v29еще Ubuntu 14 и 16 , кажется, содержат v30бета ( iwconfig -v).

Мне интересно, что случилось с этим пакетом? Почему «бета» версия 30 стала используемой стандартной версией defacto?

Перестало ли HP финансировать Джина Туррхилса, чтобы разработка прекратилась? Или, может быть, было решено, что он достаточно стабилен, чтобы остановить разработку, но если это так, почему 30 все еще будет бета?

Я нашел эту страницу Github, но, кажется, она только для исторической справки.

История версий

Беспроводные инструменты устарели в пользу, iwпотому что беспроводные расширения устарели в пользу нового интерфейса nl80211 для беспроводных устройств. В документации по ядру для iw это сказано.

Однако nl80211 находится в активной разработке, и не все драйверы были перенесены на него. Беспроводные инструменты все еще требуются для устройств, которые не были перенесены с беспроводных расширений.

Причина, по которой Ubuntu (и почти все известные мне дистрибутивы) предоставляют бета-версию 30, заключается в том, что эта версия исправляет критическую ошибку, которая была в версии 29, которая приводила к сбою iwconfig, если в области было слишком много сетей из-за буфера переполнение. Репозиторий Github для беспроводных инструментов не показывает этого, но вот соответствующий патч от Arch

Я должен был прочитать Q / A, который я связал лучше, потому что была ссылка на страницу, обсуждающую, почему этот проект был заброшен :

МЫ развиваемся?

Нет. Для МЫ принимаются только исправления ошибок.

Почему мы отказываемся от МЫ

WE основаны ioctl()и хотя ioctl()использовались и все еще используются в качестве стандартного транспорта для связи между пользователями ← → kernelspace. Новые транспорты являются предпочтительными по нескольким причинам.

Из драйверов устройств Linux - 3-е издание:

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

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

Прототип выделяется в списке системных вызовов Unix из-за точек, которые обычно помечают функцию как переменное число аргументов. Однако в реальной системе системный вызов не может иметь переменное число аргументов. Системные вызовы должны иметь четко определенный прототип, потому что пользовательские программы могут получить к ним доступ только через аппаратные «ворота». Следовательно, точки в прототипе представляют собой не переменное количество аргументов, а один необязательный аргумент, традиционно обозначаемый как char *argp. Точки просто существуют, чтобы предотвратить проверку типов во время компиляции.

В нем также говорится:

Неструктурированный характер ioctlвызова привел к тому, что он потерял популярность среди разработчиков ядра. Каждая ioctlкоманда, по сути, является отдельным, обычно недокументированным системным вызовом, и нет никакого способа проверить эти вызовы каким-либо комплексным способом. Также трудно заставить неструктурированные ioctlаргументы работать одинаково во всех системах; например, рассмотрим 64-битные системы с процессом пользовательского пространства, работающим в 32-битном режиме.

Что такое замена беспроводных расширений

Новая разработка должна быть ориентирована на cfg80211 и nl80211.

Дополнительное примечание: Похоже, Жан Туррхилс работал над проектом примерно в 1997-2009 годах. В 2014 году я обнаружил статью о том, что Tourrhiles все еще работает в HP и работает над проектом под названием OpenFlow :

Жан Туррхайлс из HP также возглавляет рабочую группу по расширяемости, которая работает в качестве «редактора» для внедрения новейших технологий в будущие версии OpenFlow.