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?

  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

Stellenmarkt
  1. Lebensversicherung von 1871 a. G. München, München
  2. über experteer GmbH, Düsseldorf
  3. Laempe Mössner Sinto GmbH, Barleben
  4. Siltronic AG, Burghausen

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 59,99€ mit Vorbesteller-Preisgarantie (Release 26.02.)
  2. 2,99€
  3. (-79%) 4,25€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Resident Evil 2 angespielt: Neuer Horror mit altbekannten Helden
Resident Evil 2 angespielt
Neuer Horror mit altbekannten Helden

Eigentlich ein Remake - tatsächlich aber fühlt sich Resident Evil 2 an wie ein neues Spiel: Golem.de hat mit Leon und Claire gegen Zombies und andere Schrecken von Raccoon City gekämpft.
Von Peter Steinlechner

  1. Resident Evil Monster und Mafia werden neu aufgelegt

Google Nachtsicht im Test: Starke Nachtaufnahmen mit dem Pixel
Google Nachtsicht im Test
Starke Nachtaufnahmen mit dem Pixel

Gut einen Monat nach der Vorstellung der neuen Pixel-Smartphones hat Google die Kamerafunktion Nachtsicht vorgestellt. Mit dieser lassen sich tolle Nachtaufnahmen machen, die mit denen von Huaweis Nachtmodus vergleichbar sind - und dessen Qualität bei Selbstporträts deutlich übersteigt.
Ein Test von Tobias Költzsch

  1. Pixel 3 Google patcht Probleme mit Speichermanagement
  2. Smartphone Google soll Pixel 3 Lite mit Kopfhörerbuchse planen
  3. Google Dem Pixel 3 XL wächst eine zweite Notch

Mars Insight: Nasa hofft auf Langeweile auf dem Mars
Mars Insight
Nasa hofft auf Langeweile auf dem Mars

Bei der Frage, wie es im Inneren des Mars aussieht, kann eine Raumsonde keine spektakuläre Landschaft gebrauchen. Eine möglichst langweilige Sandwüste wäre den beteiligten Wissenschaftlern am liebsten. Der Nasa-Livestream zeigte ab 20 Uhr MEZ, dass die Suche nach der perfekten Langeweile tatsächlich gelang.

  1. Astronomie Flüssiges Wasser auf dem Mars war Messfehler
  2. Mars Die Nasa gibt den Rover nicht auf
  3. Raumfahrt Terraforming des Mars ist mit heutiger Technik nicht möglich

  1. Nuraphone im Test: Kopfhörer mit eingebautem Hörtest und Spitzenklang
    Nuraphone im Test
    Kopfhörer mit eingebautem Hörtest und Spitzenklang

    Die Kopfhörer von Nura sehen auf den Ohren aus wie normale Over-Ear-Kopfhörer, im Inneren stecken aber auch In-Ear-Stöpsel. Das ermöglicht einen automatisierten Hörtest für individuelle Frequenzeinstellungen und eine Höhen-/Mitten- und Bass-Trennung für unglaublich guten Klang - inklusive Noise Cancelling.

  2. Machine Learning: Microsofts Clarity analysiert Verhalten von Webseitennutzern
    Machine Learning
    Microsofts Clarity analysiert Verhalten von Webseitennutzern

    Clarity können Webseitenbetreiber als Javascript-Plugin einbetten, um das Verhalten ihrer Besucher zu verfolgen. Microsofts Software wertet diese Daten aus und kann mit Machine Learning Muster erkennen - etwa welche Elemente besonders häufig geklickt oder übersehen werden.

  3. EuGH-Gutachten: Deutsches Leistungsschutzrecht soll unzulässig sein
    EuGH-Gutachten
    Deutsches Leistungsschutzrecht soll unzulässig sein

    Der früheren schwarz-gelben Bundesregierung droht eine Ohrfeige aus Luxemburg. Das deutsche Leistungsschutzrecht hätte nach Ansicht eines EuGH-Gutachters nicht in Kraft treten dürfen. Den Verlagen könnten Millionenverluste entstehen.


  1. 12:00

  2. 11:55

  3. 11:40

  4. 10:55

  5. 10:39

  6. 10:27

  7. 10:03

  8. 09:20