Abo
  1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Android will in den Linux-Kernel…

Wieso muss eigentlich jeder Mist in den Kernel?

Anzeige
  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Wieso muss eigentlich jeder Mist in den Kernel?

    Autor: wer8 16.04.10 - 17:16

    Ich kapiers nicht!

  2. Re: Wieso muss eigentlich jeder Mist in den Kernel?

    Autor: xyzxyz 16.04.10 - 17:21

    Damit Du von Haus aus Unterstützung für alles hast, Du würdest Dich sicher aufregen wenn Du nach dem Installieren denn Kernel Patchen musst damit Du die Funktion x hast und dann für Funktion y wieder, spätestens nach dem 4 oder 5 Patch würde dein Kernel instabil werden oder Du die Lust verlieren...

    xyzxyz

  3. Re: Wieso muss eigentlich jeder Mist in den Kernel?

    Autor: KennNurXP 16.04.10 - 17:24

    Ich kapiers auch nicht! Wieso kann man das denn nicht in Module auslagen? Oder treiberartig regeln? Is mir zu hoch....

  4. Re: Wieso muss eigentlich jeder Mist in den Kernel?

    Autor: ratti 16.04.10 - 17:36

    > Wieso kann man das denn nicht in Module auslagen?
    > Oder treiberartig regeln?

    „Treiber“ gibt es unter Linux nicht. Die heissen dort „Module“ und sind bereits ausgelagert. Insofern war das jetzt doppelt gemoppelt. ;-)

    Diese Module werden automatisch mit dem Kernel erstellt.
    „Im Kernel“ heisst unter Linux nicht, dass es eine dicke fette „kernel.dll“ gibt, sondern viele tausend Dateien.

    Die „Treiber“ werden aber nur geladen, wenn die Hardware tatsächlich erkannt wurde.

    Es schadet also überhaupt nichts, wenn „Treiber“ unter Linux „im Kernel“ sind, weil das nur heisst: Der Treiber wird mitgeliefert, wird aber nicht geladen.

    Man kann sich jetzt akademisch aufregen und den verschwendeten Plattenplatz bemängeln. Naja - der Kernel hat gepackt derzeit glaub ich so um die 20 MB. Drauf gepfiffen.


    Was natürlich wichtig ist, ist das möglicherweise der Kernel nicht mehr kompiliert werden kann, weil jemand ein Modul nicht mehr pflegt. Oder das alter Kram sonstwie die Entwickler nervt.

    Genau das ist bei Android passiert, und deswegen wurde es entfernt. Wenn Google das wieder richtig pflegt, wäre es also eine tolle Sache: Immer der neueste Kernel für Android, immer das neueste Android für Linux.

    Gruß,
    Jörg

  5. Re: Wieso muss eigentlich jeder Mist in den Kernel?

    Autor: Jörg Zweier 16.04.10 - 17:37

    Who cares? Besser in Kernel als außerhalb Kernel.

  6. Re: Wieso muss eigentlich jeder Mist in den Kernel?

    Autor: MBPUser 16.04.10 - 17:38

    wer8 schrieb:
    --------------------------------------------------------------------------------
    > Ich kapiers nicht!

    Dann lern doch erstmal die Grundlagen. Wie sollen Hardwaretreiber funktionieren, wenn sie nicht im Kernel sind? Linux ist keine Microkernel. Also müssen die Treiber fürs GSM Modul, für den Touchscreen usw usf eben auch in den Kernel.

    Hauptproblem bei der Geschichte ist u.a. wohl ein neuer Lock-Typ der von den Android-Entwicklern eingeführt wurde, ohne den die Android Treiber nicht funktionieren - drum können die Treiber nicht einfach in den Kernel wandern.

    Hier wirds erklärt: http://www.kroah.com/log/linux/android-kernel-problems.html

  7. Re: Wieso muss eigentlich jeder Mist in den Kernel?

    Autor: KannNurXP 16.04.10 - 17:42

    ratti schrieb:
    --------------------------------------------------------------------------------
    > Genau das ist bei Android passiert, und deswegen wurde es entfernt. Wenn
    > Google das wieder richtig pflegt, wäre es also eine tolle Sache: Immer der
    > neueste Kernel für Android, immer das neueste Android für Linux.
    >
    > Gruß,
    > Jörg

    Frage: Wie kann es sein, dass Google das Pflegen in so einem Milliarden Markt verpennen kann?!?! Für sowas hab ich Google bisher immer für zu schlau gehalten! M$ macht sowas, aber doch nicht Google!?!

  8. Re: Wieso muss eigentlich jeder Mist in den Kernel?

    Autor: MBPUser 16.04.10 - 17:44

    ratti schrieb:
    --------------------------------------------------------------------------------
    > > Wieso kann man das denn nicht in Module auslagen?
    > > Oder treiberartig regeln?
    >
    > „Treiber“ gibt es unter Linux nicht. Die heissen dort „Module“ und sind
    > bereits ausgelagert. Insofern war das jetzt doppelt gemoppelt. ;-)

    Das ist Nitpicking an Begrifflichkeiten

    > Es schadet also überhaupt nichts, wenn „Treiber“ unter Linux „im Kernel“
    > sind, weil das nur heisst: Der Treiber wird mitgeliefert, wird aber nicht
    > geladen.

    Solange die Treiber mit der im Kernel vorhandene Infrastruktur auskommen, ja. Ist bei Android aber nicht der Fall (siehe den von mir verlinkten Artikel: Stichwort: Locking)

    > Was natürlich wichtig ist, ist das möglicherweise der Kernel nicht mehr
    > kompiliert werden kann, weil jemand ein Modul nicht mehr pflegt. Oder das
    > alter Kram sonstwie die Entwickler nervt.
    >
    > Genau das ist bei Android passiert, und deswegen wurde es entfernt. Wenn

    Nein, das ist nicht genau das Problem. Das Problem ist, dass die Module angepasst werden müssen, um die Vorgaben zu erreichen, die die Kernel-Maintainer an Kernel-Code stellen, der in die offizielle Distribution integriert werden soll. Das haben die Android-Entwickler aber nicht getan. Die Gnadenfrist im staging Bereich ist abgelaufen.

  9. Re: Wieso muss eigentlich jeder Mist in den Kernel?

    Autor: eww 16.04.10 - 18:11

    Bist du Doof? Wie soll das nicht gehen. Systeme wie Solaris haben eine fast gleiche Strucktur wie bei Linux trotzdem gibt es dafür Treiber und muss nicht alles in den Kernel kommen.

  10. Re: Wieso muss eigentlich jeder Mist in den Kernel?

    Autor: linux and kernel 16.04.10 - 18:21

    Du hast Recht. Aber das peilen viele hier nicht.

    Wie der Papst und Creationisten hängen sie am alten Glauben fest.

    Alle USB_Geräte die nicht wirklich Rechenzeit brauchen, gehören raus aus dem Kernel in device-space-treiber.

    FUSE beweist es.
    SANE beweist es teilweise.
    CUPS beweist es.

    Es gibt den USB-Bus und den PCI-Bus. Die kann man per /dev (oder was auch immer grade aktuell ist) zugreifbar machen und darauf arbeiten.

    Macht minicom ja auch. oder pppd. Oder alles was vom inetd gestartet wird.
    Vieles gehört nicht mehr in den Kernel. Weil es eben keinen direkten Hardwarezugriff braucht, sondern nur auf z.B. dem USB-Bus Daten reinschiebt oder geliefert bekommt und abarbeitet.

    Das schöne an solcher Abstraktion ist dann auch, das man Com-Ports oder PPPOE o.ä. Dinge auf Rechnern woanders laufen lassen kann.
    Ich finde es bei rdesktop sehr nett, lokale Drucker und Com-Ports (Tauchcomputer u.ä.) einbinden und dem Windows-Rechner "unterschieben" zu können.
    Ohne das Gerät wirklich am Windows-Rechner anschliessen zu müssen, sondern wo ich sitze.
    Platten und lokale Laufwerke gehen auch.

    Das basiert auf Interfaces. Und diese gehören fast immer nach /dev.

    Ausnahmen ist direkter Hardware-Zugriff oder Bandbreiten-Probleme.

    Das man unbedingt alles im Kernelspace laufen lassen muss, ist nur ein falscher Glaube.
    Und wer ständig angibt, wie viele Virtellen Images er laufen hat, braucht wegen ein paar Prozent langsamerer Maustreiber wohl nicht wirklich die Panik zu schieben.


    Die Android-Sachen gehören vermutlich möglicherweise aber doch in den Kernel. Weil die z.B. auch Rechte-Dinge regeln, die man zwar auch auslagern könnte, aber vielleicht nicht will oder sollte.

    Kernel-Interfaces sind Meschpoken-Interfaces wie damals in der DDR. Wer in der Partei war, durfte im Intershop einkaufen. Alle anderen in den mangel-wirtschafts-Geschäften wo im Dresdner Christstollen nicht mal echte Rosinen waren.
    Dasselbe ist mir Kernel-Modulen. Die gehören zur Meschpoke und Adel, während die gute Software wie SANE oder CUPS oder FUSE die Arbeit ohne kernel-interfaces macht und keine meschpoken-Interfaces braucht.

    Das schöne wäre auch, das man USB-Treiber auf mehrere Kernels nutzen könnte. Ich habe einen DVB-T-Stick. Doof das easyvdr ihn nicht supportet. Knoppix schon. Damit will ich aber nicht aufnehmen. Tja. Alles ärgerlich.
    Nur weil die doofen Kernel-Module zum Kernel passen müssen. Was bei einem normalen USB-Gerät aber gar nicht nötig wäre, weil es ja über /dev-Einträge arbeiten könnte.

    Aber die fanatischen Gläubigen halten die ent-Kernelisierung zum Nachteil der User zurück.

  11. Re: Wieso muss eigentlich jeder Mist in den Kernel?

    Autor: Jörg Zweier 16.04.10 - 19:16

    Was soll alles ent-kernelisiert werden deiner Meinung nach?

  12. Re: Wieso muss eigentlich jeder Mist in den Kernel?

    Autor: linux and kernel 16.04.10 - 20:09

    Vorschlag:
    Die meisten USB-Geräte.
    Z.B. DVB-T-Sticks.

    Bei USB-3 vielleicht nicht, wenn sie Bandbreite brauchen.
    Aber Apache braucht auch Bandbreite und läuft trotzdem nicht im Kernel.

    Bei Filesystemen heulen alle.
    Aber faktisch lädt man den Kernel und initrd o.ä. von irgendwo. z.b. per GRUB.

    Danach erst muss der Kernel das root/home-FS lesen können. Und dazu könnte man ihm FUSE mitgeben.

    Wenn ich von xfs booten will, wieso muss ich einen neuen Kernel backen ? Muss ich nicht. Ich hänge die .ko-Files an den Kernel dran und er lädt sie automatisch. Wäre doch mal eine gute Idee. Macht man natürlich nur mit Boot-relevanten .ko-Files. Also Filesystemen oder Ethernet-Treibern für Netzwerk-Laufwerke oder Appliances. oder Raid-Treibern . Dann kann man mit Tricks auch von Netzwerk booten o.ä. D.h. man wird vom Willen der Distro-Maker/Kernel-Backer unabhängiger, was ich als Opfer/User sehr begrüssen würde.

    Das wäre eleganter, als NUR wegen dem Raid unbedingt den kernel neu backen zu müssen, nur weil man das .ko-File "IN" den Kernel bringen muss. Und es würde Appliances wie linvdr, easyvdr u.ä. besser nutzbar machen. Dort kriegt man die Sourcen nicht immer so einfach und will z.B. bei einen neuen Kernel auch nicht unbedingt die Patches nachvollziehen müssen.


    Davon abgesehen sind möglicherweise virtuelle Systeme wie pppoe, pppd u.ä. kernelfreier implementierbarer. Die arbeiten wie Boxen und erledigen ihre Arbeit im Rahmen der festgelegten Interfaces ausserhalb des Kernel-Spaces.

  13. Re: Wieso muss eigentlich jeder Mist in den Kernel?

    Autor: MBPUser 16.04.10 - 21:01

    eww schrieb:
    --------------------------------------------------------------------------------
    > Bist du Doof?

    Nein, Du.

    > Systeme wie Solaris haben eine fast
    > gleiche Strucktur wie bei Linux trotzdem gibt es dafür Treiber und muss
    > nicht alles in den Kernel kommen.

    Ich lach mich schlapp, Solaris hat eine "fast gleiche 'Strucktur'" Muhaha. Das einzige was bei Solaris "fast gleich" wie bei Linux ist, ist dass beides Monolithen sind, bei denen "Treiber" im Kernelspace laufen. Ansonsten sind die so unterschiedliche wie es nur geht.

  14. Re: Wieso muss eigentlich jeder Mist in den Kernel?

    Autor: MBPUser 16.04.10 - 21:06

    linux and kernel schrieb:
    --------------------------------------------------------------------------------
    > Du hast Recht. Aber das peilen viele hier nicht.
    >
    > Wie der Papst und Creationisten hängen sie am alten Glauben fest.
    >
    > Alle USB_Geräte die nicht wirklich Rechenzeit brauchen, gehören raus aus
    > dem Kernel in device-space-treiber.
    >
    > FUSE beweist es.

    FUSE beweist genau eines: das manche Dinge besser in den Kernel sollten, weil man sonst Rechenpower ohne Ende verschwendet und trotzdem keine Performance rausbekommt.

    Leute, wir können ja gerne diskutieren, ob Sachen im Kernel Space laufen müssen. Dann landen wir irgendwann bei Microkerneln (komischerweise gibts die ausserhalb von Echtzeitbetriebssystemen kaum, ausser "augebohrte" Kernel wie Mach, wo doch wieder dreiviertel aller Treiber im Kernel Space laufen).

    Aber hier gehts darum, dass Teile des Kernelcodes mit ein den "Standard-Source" übernommen werden sollen und das wär bei einer populären embedded Plattform nicht schlecht. Oder will jemand x86 und VGA-Treiber aus dem Main-Tree rausschmeissen?

  15. Re: Wieso muss eigentlich jeder Mist in den Kernel?

    Autor: QDOS 17.04.10 - 00:46

    MBPUser schrieb:
    --------------------------------------------------------------------------------
    > Leute, wir können ja gerne diskutieren, ob Sachen im Kernel Space laufen
    > müssen. Dann landen wir irgendwann bei Microkerneln (komischerweise gibts
    > die ausserhalb von Echtzeitbetriebssystemen kaum, ausser "augebohrte"
    > Kernel wie Mach, wo doch wieder dreiviertel aller Treiber im Kernel Space
    > laufen).
    Ich frage mal rein aus Interesse: wie siehts in der Hinsicht bei Minix und HURD aus?

  16. Re: Wieso muss eigentlich jeder Mist in den Kernel?

    Autor: yeti 17.04.10 - 09:55

    KennNurXP schrieb:
    --------------------------------------------------------------------------------
    > Ich kapiers auch nicht! Wieso kann man das denn nicht in Module auslagen?
    > Oder treiberartig regeln? Is mir zu hoch....
    Auch ich kapiere das nicht.

    Wir haben da z.B. Karten für den PROFIBUS (Feldbus aus der Automatisierungstechnik)
    Der Treiber wird eben mit modprobe als Modul eingebunden.
    Warum soll man das mit der in mobilen Geräten notwendigen Hardware nicht auch so machen ?

    Ein ganz normales RPM oder DEB Paket kann solche Treiber dann doch installieren und auch dafür sorgen, dass die dann beim Booten geladen werden.

    Das Problem bei solchen Treibern besteht eigentlich nur darin, dass das Kernel API nicht stabil ist. Es wandelt sich schon mal von Version zu Version. Es ist also garnicht so einfach einen Treiber zu schreiben, der mit jeder Kernel Version klarkommt. Wir hatten dieses Problem z.B. bei PCMCIA Karten, wo das API "under Construction" war/ist.

  17. Re: Wieso muss eigentlich jeder Mist in den Kernel?

    Autor: labersack 17.04.10 - 10:04

    KannNurXP schrieb:
    -----------------------------------------------------------------
    > Frage: Wie kann es sein, dass Google das Pflegen in so einem Milliarden
    > Markt verpennen kann?!?! Für sowas hab ich Google bisher immer für zu
    > schlau gehalten! M$ macht sowas, aber doch nicht Google!?!


    Die haben gehofft das es ein anderer macht.

  18. Re: Wieso muss eigentlich jeder Mist in den Kernel?

    Autor: Schnuffel 17.04.10 - 11:17

    > Das Problem bei solchen Treibern besteht eigentlich nur darin, dass das
    > Kernel API nicht stabil ist. Es wandelt sich schon mal von Version zu
    > Version. Es ist also garnicht so einfach einen Treiber zu schreiben, der
    > mit jeder Kernel Version klarkommt. Wir hatten dieses Problem z.B. bei
    > PCMCIA Karten, wo das API "under Construction" war/ist.

    Und genau das ist meines Wissens einer der Gründe, weswegen man solche Dinge gern im Kernel haben möchte. Dann hat nämlich derjenige, welcher das Interface anpasst auch die Aufgabe darauf zu achten, dass alles was darauf aufbaut, auch weiterhin funktioniert.

  19. Re: Wieso muss eigentlich jeder Mist in den Kernel?

    Autor: ratti 17.04.10 - 12:01

    yeti schrieb:
    --------------------------------------------------------------------------------
    > KennNurXP schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Ich kapiers auch nicht! Wieso kann man das denn nicht in Module
    > auslagen?
    > > Oder treiberartig regeln? Is mir zu hoch....

    > Auch ich kapiere das nicht.
    >
    > Wir haben da z.B. Karten für den PROFIBUS (Feldbus aus der
    > Automatisierungstechnik)
    > Der Treiber wird eben mit modprobe als Modul eingebunden.

    Weil, und da gibst Du die Antwort selbst…:

    > Das Problem bei solchen Treibern besteht eigentlich nur darin, dass das
    > Kernel API nicht stabil ist. Es wandelt sich schon mal von Version zu
    > Version. Es ist also garnicht so einfach einen Treiber zu schreiben, der
    > mit jeder Kernel Version klarkommt. Wir hatten dieses Problem z.B. bei
    > PCMCIA Karten, wo das API "under Construction" war/ist.

    …Du dann ein RPM oder DEB für DIESEN Kernel brauchst, und zwar genau für diesen, und mglw. für diese Distri. Wobei er hingegen, wenn „im Kernel“ liegt, wie von Magie immer passend da ist. Und zwar genau so als Modul.

    Gruß,
    Jörg

  20. Re: Wieso muss eigentlich jeder Mist in den Kernel?

    Autor: yeti 17.04.10 - 12:08

    > …Du dann ein RPM oder DEB für DIESEN Kernel brauchst, und zwar genau für
    > diesen, und mglw. für diese Distri. Wobei er hingegen, wenn „im Kernel“
    > liegt, wie von Magie immer passend da ist. Und zwar genau so als Modul.

    Da hast Du recht, es wäre aber lösbar, wenn das Kernel API stabil wäre.
    VMware compiliert seine Treiber ja auch bei jedem Kernel Update neu.

    Machbar ist das also.

    Bei der besagten PROFIBUS PCMCIA Karte war aber gerade das Problem,
    dass das PCMCIA API nicht mal Sourcecode kompatibel war (von Version zu Version).

  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Anzeige
Stellenmarkt
  1. Robert Bosch GmbH, Leonberg
  2. über Hays AG, Raum Frankfurt
  3. EOS GmbH Electro Optical Systems, Freiberg
  4. Robert Bosch GmbH, Bamberg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Blu-ray-Angebote
  1. 299,99€ (Vorbesteller-Preisgarantie)
  2. Einzelne Folge für 2,99€ oder ganze Staffel für 19,99€ kaufen (Amazon Video)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Montagewerk in Tilburg: Wo Tesla seine E-Autos für Europa produziert
Montagewerk in Tilburg
Wo Tesla seine E-Autos für Europa produziert
  1. Elektroauto Walmart will den Tesla-Truck
  2. Elektrosportwagen Tesla Roadster 2 beschleunigt in 2 Sekunden auf Tempo 100
  3. Elektromobilität Tesla Truck soll in 30 Minuten 630 km Reichweite laden

Fitbit Ionic im Test: Die (noch) nicht ganz so smarte Sportuhr
Fitbit Ionic im Test
Die (noch) nicht ganz so smarte Sportuhr
  1. Verbraucherschutz Sportuhr-Hersteller gehen unsportlich mit Daten um
  2. Wii Remote Nintendo muss 10 Millionen US-Dollar in Patentstreit zahlen
  3. Ionic Fitbit stellt Smartwatch mit Vier-Tage-Akku vor

E-Golf im Praxistest: Und lädt und lädt und lädt
E-Golf im Praxistest
Und lädt und lädt und lädt
  1. Garmin Vivoactive 3 im Test Bananaware fürs Handgelenk
  2. Microsoft Sonar überprüft kostenlos Webseiten auf Fehler
  3. Inspiron 5675 im Test Dells Ryzen-Gaming-PC reicht mindestens bis 2020

  1. Verbraucherzentrale: Regulierungsfreiheit für Glasfaser bringt Preissteigerung
    Verbraucherzentrale
    Regulierungsfreiheit für Glasfaser bringt Preissteigerung

    Die Verbraucherzentrale hat untersuchen lassen, was die Aufhebung der Regulierung für den Glasfaserausbau bringt. Ergebnis: Höhere Preise wegen fehlendem Wettbewerb für FTTH/B.

  2. WW2: Kostenpflichtige Profispieler für Call of Duty verfügbar
    WW2
    Kostenpflichtige Profispieler für Call of Duty verfügbar

    Eine kleine britische Firma will Profispieler für Call of Duty WW2 vermitteln - etwa, um Extras freizuschalten. Damit können Poser nun dank der offiziell von Activision freigeschalteten Mikrotransaktionen richtig viel Geld ins Aufhübschen ihrer Statistiken stecken.

  3. Firefox Nightly Build 58: Firefox warnt künftig vor Webseiten mit Datenlecks
    Firefox Nightly Build 58
    Firefox warnt künftig vor Webseiten mit Datenlecks

    Im Nightly Build 58 testet Mozilla einige neue Funktionen: So sollen Nutzer bald personalisierte Artikelvorschläge von Pocket bekommen. Außerdem werden Nutzer womöglich bald vor Webseiten gewarnt, die im großen Stil Nutzerdaten verloren haben.


  1. 18:40

  2. 17:44

  3. 17:23

  4. 17:05

  5. 17:04

  6. 14:39

  7. 14:24

  8. 12:56