Ich bin auch kein Dev, aber was heißt denn "der Kernel ist zu groß"?
Wenn man nur auf die immer weiter ansteigenden Quellcode-Zeilen guckt, könnte man den Eindruck bekommen. Aber nach Allem, was ich als interessierter User von Linux verstehe, ist das trotzdem ein sehr modulares Gebilde. Die Hälfte des "großen" Kernels sind sowieso "nur" Treiber für Hardware. Die werden natürlich überwiegend nicht fest eingebaut, sondern bei Bedarf als Kernelmodule geladen. Kernelmodule sind generell das Stichwort, denn obwohl Linux architektonisch ein monolithischer Kernel ist, hat man das Konzept mit Kernelmodulen flexibilisiert.
Offensichtlich lassen sich ja auch nach wie vor sehr kleine, minimale Linux-Kernel bauen, die "einfach" auch Funktionen weglassen, die nicht benötigt werden. Also scheint mir Linux generell intern modularer aufgebaut zu sein, als Du hier unterstellst. (Das ein minimaler Linux-Kernel heutzutage dennoch wesentlich größer ist als andere Systeme oder ein OS aus den 80ern, hat dann vermutlich damit zu tun, das Linux auch wesentlich mehr kann)
Das Thema kernel-interne API/ABI würde ich komplett außen vorlassen bei dem Thema Größe und Sicherheit. Die Kernel-Devs haben offensichtlich dazu einen klaren Standpunkt und der ist nunmal, das kernelINTERNE Schnittstellen sich der Gesamtentwicklung unterordnen müssen, während EXTERNE Schnittstellen möglichst stabil zu halten sind. Bisher scheint diese Linie Linux auch nicht geschadet zu haben.
Von schmidicom am Di, 13. September 2016 um 12:40 #
Das "zu Groß?" kommt daher das mir (ich benutze Gentoo und konfiguriere/baue meinen Kernel daher selbst) schon oft aufgefallen ist das viele Bereiche im Kernel (hauptsächlich Geräte-Treiber welche für den bootvorgang eher unwichtig sind und/oder auch selten zum Einsatz kommen) nur deshalb angefasst wurden weil sich eine Abhängigkeit von ihnen leicht verändert hat. Und gerade solche Sachen finde ich sollte man auslagern und über eine API, welche über mehrere Versionen hinweg kompatibel bleibt, mit dem Kernel verbinden.
EDIT: So etwas hätte, z.B. bei den Smartphones, vielleicht auch geholfen Kernel-Updates zügiger auszuliefern.
EDIT2: Auch so ein Beispiel wäre der WLAN-Treiber (broadcom-sta), jene die auf diesen Treiber angewiesen sind müssen bei fast jedem Kernel-Update befürchten das er sich plötzlich nicht mehr bauen lässt. Natürlich wäre es viel besser wenn solche Geschichten als OpenSource vorliegen würden aber wie sich zeigt ist das kaum zu erzwingen und ein Kampf den man nicht auf dem Rücken der User austragen sollte.
Dieser Beitrag wurde 3 mal editiert. Zuletzt am 13. Sep 2016 um 12:52.
Von Sie haben vergessen, Ihren Nam am Di, 13. September 2016 um 13:42 #
> EDIT: > So etwas hätte, z.B. bei den Smartphones, vielleicht auch geholfen Kernel-Updates zügiger auszuliefern.
Nein.
> EDIT2: [...]
Selbst wenn die ganze Lizenz- und Sicherheitsthematik nicht wäre, möchte ich keine kommerziell entwickelten Treiber. Heutzutage ist selbst die Qualität der Treiber unter Windows z. T. miserabel. Wenn solche Hersteller dann noch Alibi-Treiber für Linux schreiben...
Schau dir mal die kommerziell entwickelte Linux-Firmware von z.B. NAS oder Routern an. Da bekommt man das kalte Grauen. FHS? Fehlanzeige. Ein Skriptverhau den keine mehr durchblickt, mit z. T. seitenweise auskommentiertem Code. In der Firmware meines alten Dlink-NAS wurde der Zugriff auf die GPIOs der Prozessors in den Ethernet-Treiber hineingebastelt. Kein Scherz.
Ich bin auch kein Dev, aber was heißt denn "der Kernel ist zu groß"?
Wenn man nur auf die immer weiter ansteigenden Quellcode-Zeilen guckt, könnte man den Eindruck bekommen.
Aber nach Allem, was ich als interessierter User von Linux verstehe, ist das trotzdem ein sehr modulares Gebilde. Die Hälfte des "großen" Kernels sind sowieso "nur" Treiber für Hardware. Die werden natürlich überwiegend nicht fest eingebaut, sondern bei Bedarf als Kernelmodule geladen.
Kernelmodule sind generell das Stichwort, denn obwohl Linux architektonisch ein monolithischer Kernel ist, hat man das Konzept mit Kernelmodulen flexibilisiert.
Offensichtlich lassen sich ja auch nach wie vor sehr kleine, minimale Linux-Kernel bauen, die "einfach" auch Funktionen weglassen, die nicht benötigt werden. Also scheint mir Linux generell intern modularer aufgebaut zu sein, als Du hier unterstellst. (Das ein minimaler Linux-Kernel heutzutage dennoch wesentlich größer ist als andere Systeme oder ein OS aus den 80ern, hat dann vermutlich damit zu tun, das Linux auch wesentlich mehr kann)
Das Thema kernel-interne API/ABI würde ich komplett außen vorlassen bei dem Thema Größe und Sicherheit. Die Kernel-Devs haben offensichtlich dazu einen klaren Standpunkt und der ist nunmal, das kernelINTERNE Schnittstellen sich der Gesamtentwicklung unterordnen müssen, während EXTERNE Schnittstellen möglichst stabil zu halten sind.
Bisher scheint diese Linie Linux auch nicht geschadet zu haben.
Das "zu Groß?" kommt daher das mir (ich benutze Gentoo und konfiguriere/baue meinen Kernel daher selbst) schon oft aufgefallen ist das viele Bereiche im Kernel (hauptsächlich Geräte-Treiber welche für den bootvorgang eher unwichtig sind und/oder auch selten zum Einsatz kommen) nur deshalb angefasst wurden weil sich eine Abhängigkeit von ihnen leicht verändert hat. Und gerade solche Sachen finde ich sollte man auslagern und über eine API, welche über mehrere Versionen hinweg kompatibel bleibt, mit dem Kernel verbinden.
EDIT:
So etwas hätte, z.B. bei den Smartphones, vielleicht auch geholfen Kernel-Updates zügiger auszuliefern.
EDIT2:
Dieser Beitrag wurde 3 mal editiert. Zuletzt am 13. Sep 2016 um 12:52.Auch so ein Beispiel wäre der WLAN-Treiber (broadcom-sta), jene die auf diesen Treiber angewiesen sind müssen bei fast jedem Kernel-Update befürchten das er sich plötzlich nicht mehr bauen lässt. Natürlich wäre es viel besser wenn solche Geschichten als OpenSource vorliegen würden aber wie sich zeigt ist das kaum zu erzwingen und ein Kampf den man nicht auf dem Rücken der User austragen sollte.
> EDIT:
> So etwas hätte, z.B. bei den Smartphones, vielleicht auch geholfen Kernel-Updates zügiger auszuliefern.
Nein.
> EDIT2: [...]
Selbst wenn die ganze Lizenz- und Sicherheitsthematik nicht wäre, möchte ich keine kommerziell entwickelten Treiber. Heutzutage ist selbst die Qualität der Treiber unter Windows z. T. miserabel. Wenn solche Hersteller dann noch Alibi-Treiber für Linux schreiben...
Schau dir mal die kommerziell entwickelte Linux-Firmware von z.B. NAS oder Routern an. Da bekommt man das kalte Grauen. FHS? Fehlanzeige. Ein Skriptverhau den keine mehr durchblickt, mit z. T. seitenweise auskommentiertem Code. In der Firmware meines alten Dlink-NAS wurde der Zugriff auf die GPIOs der Prozessors in den Ethernet-Treiber hineingebastelt. Kein Scherz.