Von nick name am Di, 22. September 2009 um 14:36 #
> Ein weiterer Gedanke währe so einer Art Programm zu machen oder eine Routine bei der Installation einer Distro, oder einfach ne GUI die die gesamte hardware ermitteln kann, und dem entsprechend einen kernel baut.
Das wäre so und auch so wünschenswert. Mal abgesehen davon, das es kaum eine Disto mit Vanilla-Kernel gibt. (Oder irre ich da?)
> Eine zusätzliche abfrage des Einstatzgebiets des Rechners währe noch angebracht damit auch die nötigen Features hineinkompiliert werden können.
Und bei euen Geräten müss ich ihn da wieder selbst bauen und Zeit operfn? Im Falle eines HW-Tausch ist das schlecht.
> Ein anderes Konzept, währe eine separate treiberinstallation alá Windows. Nur müsste das dann vom Hardwarehersteller übernohmen werden, wie das heute ist wissen ja alle Linux benutzer.
Dann muss aber auch die ganze API für alle Module vorgehalten werden?. Anders: Wodurch genau entstehen die Performanzverluste?
>Anders: Wodurch genau entstehen die Performanzverluste?<
Ich würd ma behaupten durch verschiedene Routinen und Treiber von den manche nicht mal gebrauch werden, die jedoch im Hintergrund laufen. Wurde aber schon im dem eigentlichem Artickel gesagt.
>Mal abgesehen davon, das es kaum eine Disto mit Vanilla-Kernel gibt. (Oder irre ich da?)<
Wenn ich mich nicht irre, hat zumindest debian ne möglichkeit die Kernelsource als paket zu laden und dann kannst du damit anstellen was du willst. Es sei den, das was die da anbieten kein Vanila ist.
> Anders: Wodurch genau entstehen die Performanzverluste? >> Ich würd ma behaupten durch verschiedene Routinen und Treiber von den manche nicht mal gebrauch werden, die jedoch im Hintergrund laufen. Wurde aber schon im dem eigentlichem Artickel gesagt. Kann ich mir ehrlich gesagt überhaupt nicht vorstellen. Du kriegst keinen Treiber upstream der, obwohl nicht nötig, irgendeine Task oder so startet. Ich glaube nicht, dass die Treiber unmittelbar das Problem sind. Wenn ein Treiber ob einkompiliert oder als Modul gebaut nicht benötigt wird, weil die Hardware nicht vorhanden ist, wird der Treiber selbst nicht verwendet. Er wird entweder geladen oder nie wieder aufgerufen.
Der Performanzverlust kann nur von zentralen Komponenten des Kernels herrühren (Scheduler, Slab-Allocator, ...).
Von Alan Smithee am Di, 22. September 2009 um 15:07 #
> Wenn ich mich nicht irre, hat zumindest debian ne möglichkeit die Kernelsource als paket zu laden und dann kannst du damit anstellen was du willst. Es sei den, das was die da anbieten kein Vanila ist.
vanilla = kein kernel patch das hat weniger mit den features zu tun die du aktivierst.
Das wäre so und auch so wünschenswert. Mal abgesehen davon, das es kaum eine Disto mit Vanilla-Kernel gibt. (Oder irre ich da?)
> Eine zusätzliche abfrage des Einstatzgebiets des Rechners währe noch angebracht damit auch die nötigen Features hineinkompiliert werden können.
Und bei euen Geräten müss ich ihn da wieder selbst bauen und Zeit operfn? Im Falle eines HW-Tausch ist das schlecht.
> Ein anderes Konzept, währe eine separate treiberinstallation alá Windows. Nur müsste das dann vom Hardwarehersteller übernohmen werden, wie das heute ist wissen ja alle Linux benutzer.
Dann muss aber auch die ganze API für alle Module vorgehalten werden?.
Anders: Wodurch genau entstehen die Performanzverluste?
Ich würd ma behaupten durch verschiedene Routinen und Treiber von den manche nicht mal gebrauch werden, die jedoch im Hintergrund laufen. Wurde aber schon im dem eigentlichem Artickel gesagt.
>Mal abgesehen davon, das es kaum eine Disto mit Vanilla-Kernel gibt. (Oder irre ich da?)<
Wenn ich mich nicht irre, hat zumindest debian ne möglichkeit die Kernelsource als paket zu laden und dann kannst du damit anstellen was du willst. Es sei den, das was die da anbieten kein Vanila ist.
>> Ich würd ma behaupten durch verschiedene Routinen und Treiber von den manche nicht mal gebrauch werden, die jedoch im Hintergrund laufen. Wurde aber schon im dem eigentlichem Artickel gesagt.
Kann ich mir ehrlich gesagt überhaupt nicht vorstellen. Du kriegst keinen Treiber upstream der, obwohl nicht nötig, irgendeine Task oder so startet. Ich glaube nicht, dass die Treiber unmittelbar das Problem sind. Wenn ein Treiber ob einkompiliert oder als Modul gebaut nicht benötigt wird, weil die Hardware nicht vorhanden ist, wird der Treiber selbst nicht verwendet. Er wird entweder geladen oder nie wieder aufgerufen.
Der Performanzverlust kann nur von zentralen Komponenten des Kernels herrühren (Scheduler, Slab-Allocator, ...).
vanilla = kein kernel patch
das hat weniger mit den features zu tun die du aktivierst.
Slackware