Android-code zit nu in Linux-kernel

De Linux Foundation heeft een nieuwe versie van de Linux-kernel uitgebracht. Versie 3.3 heeft als grootste wijziging dat aanpassingen die Google heeft gedaan aan de kernel voor Android nu in de officiële Linux-kernel zijn opgenomen.

De samenvoeging van de Android-code met de Linux-kernel moet het voor Linux-distro's gemakkelijker maken om Android-apps te draaien, terwijl ontwikkelaars van custom roms ook gemakkelijker firmware moeten kunnen uitbrengen, meldt Kernelnewbies. Sinds december 2009 werden aanpassingen die Android-ontwikkelaars deden aan de Linux-kernel niet meer in de officiële kernel opgenomen door onenigheid. Inmiddels is het conflict bijgelegd.

In Linux 3.3 zijn nog meer aanpassingen gedaan aan onder meer geheugenbeheer en virtualisatie. Linus Torvalds heeft zondag de release van de nieuwe kernelversie aangekondigd. De releases van de Linux-kernel volgen nu telkens enkele maanden na elkaar. Versie 3.0 kwam in de afgelopen zomer uit, terwijl aan het begin van de winter Linux-kernel 3.2 uitkwam.

Reacties (123)

Toen ik dit bericht las dacht ik direct aan de veiligheidsimplicatie die dit met zich mee kan brengen. Android is niet als veilig OS gebouwd maar als datagraai OS voor Google, dus wat is het nut om de sterke en veilige Linux kernel te vervuilen met Android.

Een unified kernel zorgt voor een eenvoudiger development process. Het voorkomt dat men continue code moet porten tussen verschillende teams en dat er geen werk dubbel gebeurd.

Uiteindelijk is de opbouw van de kernel zeer modulair en kunnen/zullen vele android specifieke zaken uitgeschakeld worden op platformen waar er geen nood aan is.

En android is natuurlijk meer dan een aangepaste kernel. Alle user interactie zit op applicatie niveau en heeft niets te zien met welke kernel er onder zit.

Bedenk je wel dat alle code door een stevige review gaan voordat het geaccepteerd wordt. En zoals Blokker_1999 al zei zal het datagraaien in userspace plaatsvinden.

Over een tijdje draait alle apperatuur op Linux en zijn windows en mac osx verleden tijd

Dat hoop zelfs ik als levenslange Linux-gebruiker niet. Ik zal niet ontkennen dat ik graag (grote) groei in de Linux-wereld zie, maar een monopoliepositie is onder geen enkele omstandigheid wenselijk; zelfs niet voor (delen van) Linux. Net als dat een monopolie van Android op de mobiele markt niet wenselijk is; een monopolie van GNOME op de desktop environmentmarkt niet wenselijk is en een monopolie van Apache op de webservermarkt niet wenselijk is, om maar wat voorbeelden te noemen. Eerlijke concurrentie is de enige manier om tot echte innovatie te komen, en voordat we zelfs dat punt maar bereikt hebben, zullen we nog heel wat jaren moeten wachten, als het er überhaupt ooit van komt. Ik zie Microsoft haar monopolie niet snel opgeven namelijk.

[Reactie gewijzigd door Anoniem: 289544 op 20 maart 2012 08:22]

Ik dacht dat meneer Torvalds de Linux kernel al bloated vond, en nu word er vanalles opgenomen om Android makkelijker te laten draaien op een paar specifieke distro's? Dat klinkt toch als iets wat er juist niet in moet, maar gewoon appart moet blijven voor de groep die het nodig heeft.

Ik zit er niet op te wachten dat er vanallerlij Android zooi geladen word terwijl ik het niet gebruik.

Verbeteringen aan de kernel zijn welkom maar meer load nee bedankt.

edit:
Even een linkje naar mijn claim:
Torvalds vind linux kernel bloated.

Torvalds stelde dat elke nieuwe feature die aan de bestaande kernelcode wordt toegevoegd het probleem groter maakt.

.

[Reactie gewijzigd door LOTG op 19 maart 2012 11:48]

Ik denk dat het hier specifiek gaat om het gegeven voor touch input, ARM comptabiliteit en ondersteuning voor 3G modems (of iig voor mobile verbindingen) Het is echt niet zo dat je dadelijk je linux start en een android lockscreen tezien krijgt.

Het gaat om een paar hele basis functionaliteiten van Android: het logging mechanisme, het inter-process communication mechanisme wat apps o.a. gebruiken om berichten naar elkaar en het OS te sturen en de low-memory killer.

Android heeft ook nog wat mooie dingen voor power management, maar die zitten er nog niet in, wel geplanned voor 3.4.

Geen van deze functionaliteiten wordt overigens gebruikt als je de kernel niet zodanig configureert dat ze aan staan. De meeste PC distro's zullen dit dus gewoon uit laten staan en het zit vervolgens ook helemaal niet in de weg.

Een hele belangrijke reden om deze merge te doen is de volgende:

Het maakt het voor device manufacturers een heel stuk makkelijker om Android te porten naar hun eigen device. Voorheen had je als device manufacturer een probleem als je zowel Android functionaliteit nodig had als drivers die in een nieuwere versie van de algemene Linux kernel zaten, aangezien Android altijd iets achter liep. Dus dit maakt hun werk een stuk makkelijker.

Ik dacht dat meneer Torvalds de Linux kernel al bloated vond

Was het niet Tanenbaum die hetzelfde 20 jaar geleden zei?

Even voor de gein de originele discussie opgezocht: hiero.

Tanenbaum:

LINUX is a monolithic style system. This is a giant step back into the 1970s. That is like taking an existing, working C program and rewriting it in BASIC. To me, writing a monolithic system in 1991 is a truly poor idea.

Linus zelf:

True, linux is monolithic, and I agree that microkernels are nicer. With a less argumentative subject, I'd probably have agreed with most of what you said. From a theoretical (and aesthetical) standpoint linux looses.

mwa.

Tsjonge, dat je hier nog weer mee aan komt. Linux werkt al heel lang met modules.
Je kunt een compacte kernel bouwen met daarin alleen wat je per se nodig hebt en de rest kun je in modules compileren.
De meeste distro's werken ook zo, alle drivers voor netwerkkaarten worden meegeleverd als modules en niet in de kernel gepropt.

Vziw is Linux nog steeds monolitisch, of in ieder geval monolitischer dan Tanenbaum's eigen systeem. Daar doet het concept van modules niets aan af. De drivers worden inderdaad in modules gestopt, maar dingen als file systems, memory management, TCP/IP stack zitten allemaal direct in de kernel, en dat is bij microkernels niet zo.

Wat Linus zegt is: het zou mooi zijn als het gemodulariseerder zou zijn geweest, maar dat is het nou eenmaal niet, en nu werkt het ook best wel goed.

@Ertepeller: modulair zeker, omdat er een Virtual File System tussen zit. Maar de code van de file systems zitten normaal gesproken ook in kernelspace, om performanceredenen. ZFS is een fs dat nu wel in userspace draait, maar waarvan ze gaan proberen die in kernelspace te krijgen. Vziw draaien btrfs, ext2/3/4 gewoon in kernelspace.

[Reactie gewijzigd door bartcramer op 19 maart 2012 14:09]

Sterker nog (en dat zegt Linus ook, elders), het werkt nu goed omdat het niet mooi is. Micro-kernels hebben robuuste interne intefaces, waardoor een memory manager can crashen zonder het systeem plat te leggen. De prijs die je daarvoor betaalt is dat de interface niet snel is. En aangezien ongeveer elke operatie op een computer wel memory nodig heeft, en de meesten ook nog files, zijn al die operaties langzaam.

De "oplossing" die hiervoor het meest populair is, is bewijzen dat een bepaalde module een interface niet kan misbruiken. Maar als je daarmee begint, dan is het microkernel concept snel achterhaald. Waarom moet je de memory-manager achter een robuuste interface afschermen, als hij wiskundig bewezen correct is? Dan kan die gewoon in de kernel zelf, met alle performance voordelen van dien.

[Reactie gewijzigd door MSalters op 19 maart 2012 14:05]

Je kunt ook je filesystems via modules ondersteunen. Alleen doe je dat vaak niet voor de filesystems die toch altijd nodig hebt omdat dit geen winst geeft en omdat het langzamer is.
Het is bijvoorbeeld wel heel handig om ondersteuning voor NTFS, VFAT of HFS+ als module op te nemen. Deze heb je normaal niet nofig om te werken met Linux maar wel als je Windows- of Mac-gerelateerde media wilt gebruiken.

Ook de filesystems die je "altijd" (welke dan? Je zult wel doelen op libata, ext2/3/4, fat e.d) nodig hebt, kun je in modules onderbrengen. In de kernel zelf zit geen enkel filesystem meegecompileerd (bij Debian tenminste niet).

Hoe je dan toch je filesystems/usb/cd/dvd kunt aanspreken bij het opstarten? Daar heb je initrd voor. Alle kernel-drivers/modules zitten daar in. Het init-scriptje van initrd "vindt" (dmv udev) alle aanwezige hardware en importeert alle benodigde modules. Dan is het ook mogelijk de root-partitie te mounten en de "echte" init (meestal /sbin/init) op te starten. Geen enkele noodzaak dus om veel/altijd gebruikte filesystemen in te bakken.

Wat betreft performance maakt het volgens mij geen enkel verschil of filesystem-modules geimporteerd worden of al van tevoren meegebakken zijn.

maar dingen als file systems

Ook al lang modulair hoor.

Android is de succesvolste Linux distro ooit, het is logisch dat de optimalisatie voor Android dan ook steeds belangrijker wordt als het gaat om de toekomstige development van de Linux kernel. Uiteindelijk is een kernel er voor het OS, niet andersom.

Waarom denk je dat verbeteringen voor Android ten koste gaan van andere zaken? De Linux-kernel is zeer modulair. Wat je niet nodig hebt gebruik je ook niet. Je hebt er toch geen last van dat er 10.000 printer-drivers worden voorgeinstalleerd door Windows.

In principe is er wel wat voor te zeggen dat een 'algemeen' systeem het altijd zal verliezen van een systeem dat is geoptimaliseerd voor een stuk hardware, maar in praktijk verandert de hardware-markt nogal snel. Wat nu een desktop-computer is zit over 5 jaar in je telefoon. Als je je systeem gaat optimaliseren voor hedendaagse hardware dan weet je dat je over 3 jaar een groot probleem hebt.

In praktijk is het voor Linux vaak een voordeel dat het op zo veel verschillende systemen draait. Veel bugs komen te voorschijn door de subtiele verschillen tussen verschillende hardware.

Ik zit er niet op te wachten dat er vanallerlij Android zooi geladen word terwijl ik het niet gebruik.

Dan compileer je toch zelf je kernels? Zo te horen heb je er genoeg verstand van.

Dan kan je hetzelfde zeggen van Chromium, of geen CUPS en WebKit willen gebruiken omdat het op naam van Apple staat. Het feit is nu eenmaal dat veel partijen bijdragen aan (de) Linux(kernel), en daar maakt Google ook deel van uit. En ik kan ook niet zeggen dat ik daar nu zo bang voor ben. Dat hun online-diensten niet de meest privacyongevoelige zijn, zie ik ook wel in, maar om te zeggen dat hun toevoegingen aan de Linux-kernel nu echt je mail gaan filteren op steekwoorden, lijkt me toch behoorlijk paranoïde.

Dan krijg ik eerlijk gezegd meer de kriebels van hoe Mono zich al in veel distributies als standaardonderdeel heeft weten te voegen. Dingen als Banshee, Gnome-Do, Docky etc. zijn er volledig afhankelijk van, en de grote distro's als Ubuntu en Mint leveren dat zo standaard mee.

Webkit is al een tijdje geen Apple project meer, maar wordt tegenwoordig grotendeels door Google developers geschreven.

Wat Mono betreft, wat heeft Novell je ooit misdaan?

[Reactie gewijzigd door Dreamvoid op 19 maart 2012 12:39]

Dat Google het grootste deel schrijft van de code wil niet zeggen dat het geen Apple-project meer is, Webkit is en blijft van Apple.

Webkit is een open source project, het is van niemand. Apple is 1 van de contribuerende partijen, maar Webkit is net zo min "van Apple" als dat Mozilla "van Netscape" is of de Linux kernel "van Linus Torvalds".

[Reactie gewijzigd door Dreamvoid op 19 maart 2012 13:36]

Software die van niemand is kom je amper tegen in de open source wereld. Dat is code met een publiek domein licentie. Nagenoeg alle code is van iemand omdat die geclaimed is middels de copyright wetgeving.

Verschillende projecten gaan op verschillende manieren met dit vraagstuk omtrent eigendom om. Maar het is een illusie om te denken dat bv. webkit van niemand is...

[Reactie gewijzigd door Bulkzooi op 19 maart 2012 16:20]

Goed, op copyright basis is het een optelsom van alles uit de KHTML dagen, wat Apple code dat er na de fork aan toegevoegd is, en daarna ook nog ladingen code van Google, Nokia, Intel, Qualcomm, RIM, etc etc etc. Het punt blijft, uiteindelijk is Webkit niet van 1 bedrijf, net zo min als de Linux kernel van 1 bedrijf is.

[Reactie gewijzigd door Dreamvoid op 19 maart 2012 17:03]

Klopt, maar dat is een heel ander punt dan waar ik op reageerde ;-) : Dat open source projecten van niemand zijn.

Het leuke van veel open source licenties is dat ondanks de eigendomsrechten wel iedereen toegang krijgt. In tegenstelling tot de ouderwetse eigendomsrechten die juist bedoeld zijn om mensen uit te sluiten (of te laten betalen voor gebruik).

Hier is altijd veel verwarring over. Echter, open source code heeft wel degelijk eigenaren.

[Reactie gewijzigd door Bulkzooi op 19 maart 2012 17:12]

De code word echt wel ge-peer reviewed anders kom de code er gewoon niet in.
Wees maar niet bang. In dit geval is het een goede ontwikkeling dat commerciële ontwikkelaars tijd en geld besteden aan open source.
Dit kom Linux alleen maar ten goede.
Je kunt nu bijvoorbeeld je eigen android linux kernel bakken.
Voor zover ik kan opmaken uit dit bericht.

Linux wordt nu ook al grotendeels geschreven door commerciele ontwikkelaars als IBM, Red Hat, Novell, Intel, Oracle en (jaja) Microsoft.

[Reactie gewijzigd door Dreamvoid op 19 maart 2012 12:01]

Dit doet Microsoft overigens enkel en alleen om gevirtualiseerde Windows-systemen vloeiender te laten draaien op Linux-hosts; heus niet omdat ze zo veel sympathie voor hun concurrent hebben.

Andersom, die Hyper-V code is toegevoegd om Linux clients beter te laten draaien op Windows hosts.

Natuurlijk doet MS dat puur voor de centen, maar goed dat doen al die andere spelers ook.

Die code is voor iedereen te checken aangezien open-source. Gewoon onmogelijk om hier backdoors in te stoppen of iets dergelijks. Overigens zijn het voornamelijk drivers om wat dingen aan te sturen en een console die werkt door berichten op het RAM geheugen op te slaan.

Het zijn allemaal redelijk losstaande dingen en ook nog eens fully open source dus door iedereen te onderhouden als nodig.

Het zou wel een unique selling pointvoor Ubuntu zijn als ze de mogelijkheid bieden om .apk bestanden te installeren en te draaien.

Volgens mij heeft het niets te maken met het cross-platform kunnen draaien van applicaties. Er kan nu (theoretisch) een kernel voor Android gemaakt worden vanuit de source van de Linux-kernel.

Maar omdat de processor wel compleet anders is betekent dit ook dat applicaties voor deze processor gecompileerd moeten worden. Dit kan niet zomaar voor iedere Linux-distributie. Verder is het natuurlijk de vraag of alles in 1x goed gaat bij het compileren en of er geen distributie specifieke aanpassingen gedaan moeten worden.

Klopt, je hebt een emulator nodig
Al lijkt me dat niet echt een probleem gezien een pc veel meer power heeft dan een smartphone. En met een beetje geluk wordt dan de dev-emulator een stuk beter

Het emuleren van de volledige ARM architectuur is een enorme performance hit.
En ik denk niet dat dit op korte termijn de snelheid van de native ARM devices zal evenaren. Ook al is de PC hardware veel krachtiger.

Tevens kan je in principe alle Android apps prima onder x86 draaien zolang ze maar geen gebruik maken van native code. Dat is nu juist het leuke van de Java VM (Dalvik).

Zeker gezien Intel druk bezig is het x86 platform te pushen naar mobiele devices en dus ontwikkelaars dwingt om ook hun native code voor x86 te compileren of niet te gebruiken. Hoe sneller het spul hoe minder reden om dichter bij bare metal te programmeren. Uiteindelijk is emuleren gewoon niet meer nodig.
(Android draait inmiddels al op de x86 architectuur)

Tweakers.net vond het niet nieuwswaardig; www.ubuntu.com/android - maar kijk er toch maar even

Dat is dus Ubuntu draaien op een device waar primair android op draait.

Android software apps draaien binnen een Ubuntu omgeving is iets heel anders.

Overigens moet je dan sowieso (uitgaande van ubuntu/intel niet ubuntu/amd) een emulatielaag draaien.

En jij leest Tweakers niet vaak genoeg ?

nieuws: Canonical onthult Ubuntu for Android-project

nieuws: Canonical onthult Ubuntu for Android-project
Blijkbaar wel.

Ik heb geen zin de link op te zoeken, maar hier is gewoon een nieuwsitem over geweest. Daarnaast is dit niet relevant voor Android Apps onder Linux draaien. Hier draai je Linux als Android App.

Edit
Slowpoke...

[Reactie gewijzigd door TijmenK op 19 maart 2012 11:13]

Dat vond Tweakers.net wel
nieuws: Canonical onthult Ubuntu for Android-project

Pagina paar uur niet refreshed

[Reactie gewijzigd door agoNITE op 19 maart 2012 12:53]

Kunnen we dus Android applicaties in Linux gaan draaien? Dat is wel leuk.

Zo ver is het nog niet, dit zijn slechts kernel aanpassingen. Daarvoor zou de java implementatie van android ook geport moeten worden.oeten kunnen uitbrengen, meldt Kernelnewsbies. Sinds december 2009 werden aanpassingen die Android-ontwikkelaars deden aan de Linux-kernel niet meer in de offic

Lijkt mij een goede stap voor Linux, wanneer er Android apps in de toekomst kunnen worden gebruikt zal dit betekenen dat heel veel dingen die je eerst niet met linux kon (of niet goed werkte) nu ineens wel kunt doen. Ook betekend dit misschien dat er meer games voor Linux worden ontwikkeld omdat er veel ontwikkelaars voor android zijn en deze nu misschien wel het licht zien.

Ik vind het een goede stap en hoop dat Linux hiermee wat marktaandeel kan winnen. Ik ben zelf een Windows gebruiker maar ik vind dat het wel eens tijd wordt voor andere partijen om ook eens wat meer marktaandeel te krijgen.

Dit heeft weinig te maken met het draaien van Android applicaties op non-Android distributies, dit zijn kerneloptimalisaties (met name rond scheduling/power saving).

[Reactie gewijzigd door Dreamvoid op 19 maart 2012 11:45]

Ik zie niet in waarom Linux nou zoveel beter wordt met Android apps-support. Ik bedoel, het lijkt me een mooie feature, ik zou zeker een aantal apps erop zetten, maar je hebt met standaard Ubuntu echt wel meer mogelijkheden dan met Android. Android apps min of meer native draaien op je PC is zeker een unique selling point (kan ik leuk even tussendoor als ik werk een Wordfeudje naar iemand spelen), maar het is niet alsof het echt belangrijke dingen zal toevoegen. Misschien als GUIs ook support krijgen voor Android Widgets, dat het dan leuk is je agenda widget op je PC te hebben, maar dat lijkt me al vrij geavanceerd en zie ik niet snel gebeuren, en dat lijkt me toch de grootste toegevoegde waarde die je zal krijgen. Voor office toepassingen, browsen, videos spelen of noem maar iets geks ga je geen Android apps gebruiken als je een volledig voor PC/laptop geschikte versie kan draaien, lijkt me.

Het gaat ook niet zozeer om de grote hoeveelheid fart apps die je misschien wel ondersteund krijgt. Maar met name om dat je dan ook extra mensen aantrekt om linux eens te proberen.

"Hé, die applicatie die ik op mijn telefoon heb kan ook op dat besturingssysteem!"

@ Dreamvoid: er wordt toch echt duidelijk gezegd
"De samenvoeging van de Android-code met de Linux-kernel moet het voor Linux-distro's gemakkelijker maken om Android-apps te draaien". Ik neem aan dat er linux distro's zijn die hier gebruik van gaan maken anders is het nogal zinloos om zoiets toe te voegen, het heeft er dus wel degelijk mee te maken.

Ik vindt het best, zolang het voor desktop-gebruikers maar optioneel is, d.w.z. ze laten het standaard weg of je kunt kiezen bij de installatie of evt. nadien dat je het met het compileren van een custom-kernel kunt weghalen.

Het gaat hier wel om kernel-code hè, niet om delen van de GUI. Dat er een tweak van Android in je kernel zit die bijvoorbeeld voordelig is voor power management, of Java-code efficiënter kan benutten, lijkt me niet zo'n probleem voor desktop-gebruikers.

Dit staat allemaal compleet los van alles dat er onder de X11-server gebeurt.

In Linux 3.3 zijn nog meer aanpassingen gedaan aan onder meer geheugenbeheer, virtualisatie en geheugenbeheer.

Hier klopt de zin volgens mij niet helemaal...

ot: Ik kijk er naar uit welke gevolgen dit zal hebben voor de linux kernel. Toch denk ik dat de veranderingen, naast het booten van apps, niet direct visueel zichtbaar zullen zijn. Maar ik denk dat de community over een klein tijdje wel wat klaar hebben liggen.

Ik heb niet naar de patches gekeken maar ik denk niet dat je hier apps mee kan draaien. Daar heb je de virtuele machine voor nodig die Google gebruikt voor Android. Ik ga er van uit deze patches gaan over hardware-ondersteuning voor allerlei mobiele hardware.