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

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

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

Редактировать: Похоже, что WE (Wireless Extensions) были добавлены в ядро ​​Туррхилсом, а не сами беспроводные инструменты. Инструменты доступны в большинстве дистрибутивов как основной способ связи с WE. Вы можете увидеть WE в ядре по адресу /proc/net/wireless.

Theпоследняя выпущенная версияеще v29Ubuntu 14 и 16, похоже, содержат v30бета-версию ( iwconfig -v).

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

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

я нашел этоСтраница на Githubно, похоже, это всего лишь историческая справка.

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

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

решение1

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

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

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

решение2

Мне следовало бы лучше прочитать раздел вопросов и ответов, ссылку на который я привел, потому что там была ссылка на страницу, где обсуждалосьпочему этот проект был заброшен:

Получаем ли мы дальнейшее развитие?

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

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

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

Из книги «Драйверы устройств 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-битном режиме.

Что является заменой Wireless-Extensions?

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


Примечание:Кажется, Жан Туррильс работал над проектом примерно с 1997 по 2009 год. Я нашелстатья от 2014 годаговоря, что Туррильс все еще работал в HP над проектом под названиемOpenFlow:

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

Связанный контент