Warum wurde Version 30 der Wireless Tools zu einer permanenten Beta?

Question

Ich habe einige gute Informationen über drahtlose Werkzeuge hier gefunden.Fragen und Antworten. Anscheinend wurde es 1997 von Jean Tourrhiles mit Unterstützung von Hewlett Packard in den Linux-Kernel eingeführt .

Bearbeiten: Es scheint, dass WE (Wireless Extensions) von Tourrhiles zum Kernel hinzugefügt wurde, nicht die Wireless-Tools selbst. Die Tools sind in den meisten Distributionen als primäre Möglichkeit zur Kommunikation mit WE verfügbar. Sie können WE im Kernel unter sehen /proc/net/wireless.

Derletzte veröffentlichte Versionv29Ubuntu 14 und 16 scheinen jedoch die Beta zu enthalten ( v30) iwconfig -v.

Ich bin neugierig, was mit diesem Paket passiert ist. Warum wurde die „Beta“-Version 30 zur de facto verwendeten Standardversion?

Hat HP die Finanzierung von Jean Tourrhiles eingestellt und die Entwicklung deshalb eingestellt? Oder wurde vielleicht entschieden, dass die Software stabil genug sei, um die Entwicklung einzustellen, aber wenn das der Fall war, warum wäre Version 30 dann immer noch eine Beta?

ich habe das gefundenGithub-Seiteaber es scheint nur als historische Referenz zu dienen.

Versionsgeschichte

Answer 1

Wireless-Tools werden zugunsten von veraltet, iwda die Wireless-Erweiterungen zugunsten der neuen nl80211-Schnittstelle für Wireless-Geräte veraltet sind. DieKernel-Dokumentation für iwsagt, dass.

nl80211 wird jedoch aktiv weiterentwickelt und nicht alle Treiber wurden darauf migriert. Für Geräte, die nicht von Wireless-Erweiterungen migriert wurden, sind weiterhin Wireless-Tools erforderlich.

Der Grund, warum Ubuntu (und so ziemlich alle Distributionen, die ich kenne) Version 30 Beta bereitstellen, ist, dass diese Version einen kritischen Fehler behebt, der in Version 29 vorhanden war, der dazu führte, dass iwconfig aufgrund eines Pufferüberlaufs fehlschlug, wenn sich zu viele Netzwerke in der Umgebung befanden. Das Github-Repo für Wireless-Tools zeigt dies nicht, aber hier ist der entsprechende Patch vonBogen

Answer 2

Ich hätte die verlinkte Frage/Antwort besser durchlesen sollen, da sie einen Link zu einer Seite enthielt, auf der es umwarum dieses Projekt aufgegeben wurde:

Wird WE weiterentwickelt?

Nein, ist es nicht. Für WE werden nur Fehlerbehebungen akzeptiert.

Warum wir das WIR aufgeben

WEs basieren auf ioctl()und ioctl()wurden und werden zwar als Standardtransportmittel für die Kommunikation zwischen Benutzer ←→ Kernelspace verwendet, aber aus mehreren Gründen werden neue Transportmittel bevorzugt.

Aus Linux-Gerätetreibern – 3. Ausgabe:

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

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

Der Prototyp fällt in der Liste der Unix-Systemaufrufe durch die Punkte auf, die normalerweise die Funktion als eine Funktion mit variabler Anzahl von Argumenten kennzeichnen. In einem realen System kann ein Systemaufruf jedoch nicht tatsächlich eine variable Anzahl von Argumenten haben. Systemaufrufe müssen einen wohldefinierten Prototyp haben, da Benutzerprogramme nur über Hardware-„Gates“ darauf zugreifen können. Daher stellen die Punkte im Prototyp keine variable Anzahl von Argumenten dar, sondern ein einzelnes optionales Argument, das traditionell als gekennzeichnet wird char *argp. Die Punkte dienen lediglich dazu, eine Typprüfung während der Kompilierung zu verhindern.

Darin heißt es außerdem:

Die unstrukturierte Natur des ioctlAufrufs hat dazu geführt, dass er bei Kernel-Entwicklern in Ungnade gefallen ist. Jeder ioctlBefehl ist im Wesentlichen ein separater, normalerweise undokumentierter Systemaufruf, und es gibt keine Möglichkeit, diese Aufrufe umfassend zu prüfen. Es ist auch schwierig, die unstrukturierten ioctlArgumente auf allen Systemen identisch funktionieren zu lassen; denken Sie beispielsweise an 64-Bit-Systeme mit einem Userspace-Prozess, der im 32-Bit-Modus ausgeführt wird.

Was ist der Ersatz für Wireless-Extensions

Bei Neuentwicklungen sollte der Schwerpunkt auf cfg80211 und nl80211 liegen.

---

Randnotiz:Es scheint, dass Jean Tourrhiles von 1997 bis 2009 an dem Projekt gearbeitet hat. Ich fand eineArtikel aus 2014Tourrhiles sei noch bei HP und arbeite an einem Projekt namensOffener Fluss:

Jean Tourrhiles von HP leitet auch die Extensibility Working Group, die als „Editor“ arbeitet, um die neueste Technologie in zukünftige Versionen von OpenFlow einzubringen.