Linus Torvalds: ARM er en rodebunke at udvikle til

Det er sikkert sandt. Men hvad kan der gøres ved det? Så længe Google med deres Android OS (tablets + telefoner), som vel er størst aftager af ARM SOC's ikke har interesse i at ensarte sig, så kan Linux kernel-teamet dælme ikke.

Det betyder, at for alt det er værd, kunne Linus have fået det samme ud af at sige: 'Jeg kan ikke lide det.'

Når Market i Android stiller krav, så måske.

Nize (1) skrev:

Så længe Google med deres Android OS (tablets + telefoner), som vel er størst aftager af ARM SOC's ikke har interesse i at ensarte sig

Hvad mener du med det?

Der er mange forskellige Google-telefoner, men jeg har ikke hørt noget om at de ikke skulle været baseret på standarder.

Og hvis der laves en ny ARM-standard bedre end de gamle, så skal Linux såmen nok komme til at understøtte det, og de nye Android-telefoner vil skifte til de nye chips som de plejer. No problem.

Nize (1) skrev:

Det betyder, at for alt det er værd, kunne Linus have fået det samme ud af at sige: 'Jeg kan ikke lide det.'

Er det ikke præcist det han siger? Plus nogle argumenter, som gør det værd at høre på.

Er Android og Linux ikke den samme kerne?

dalbjerg (3) skrev:

Er Android og Linux ikke den samme kerne?

Kort sagt: jo. Android er et system som bygger oven på Linux.

Og man kan enda køre visse Linux-programmer på en Android-telefon, under rette omstændigheder.

myplacedk (2) skrev:

Der er mange forskellige Google-telefoner, men jeg har ikke hørt noget om at de ikke skulle været baseret på standarder.

Tror han mener at f.eks Nvidias Tegra 2 SOC der bruges i Motorola Xoom, LG Optimus 2x osv, godt nok er en ARM Cortex A9, men at Nvidia har valgt ikke at inkludere NEON.

Det instuktionssæt er der til gengæld på alle de Snapdragon SOCs som f.eks HTC benytter.

Så selvom det er ARM de alle benytter, er der alligevel store forskelle

Idéen med SoC er jo at alt ligges i en chip, og jeg tvivler på at man bare lige kan lave en standard på det. Jeg tror ikke to modeller vil gå hen og blive specielt ens, da der ikke rigtig er plads til det på det lille areal der er at arbejde med. Når nogen laver noget nyt, så kunne jeg forestille mig at det kræver en omstrukturering af hele chippen.

Jeg tror også at der er meget fremtid inden for dette, da det sikkert er enormt energi effektivt at lave det på denne måde.

Oh, så det er reelt ikke ARM han syntes der er problemet men SOC.

kblood (6) skrev:

Idéen med SoC er jo at alt ligges i en chip, og jeg tvivler på at man bare lige kan lave en standard på det. Jeg tror ikke to modeller vil gå hen og blive specielt ens, da der ikke rigtig er plads til det på det lille areal der er at arbejde med. Når nogen laver noget nyt, så kunne jeg forestille mig at det kræver en omstrukturering af hele chippen.

Jeg tror også at der er meget fremtid inden for dette, da det sikkert er enormt energi effektivt at lave det på denne måde.

Du kan sagtens få en standard til en SoC du skal bare gøre det ordenligt...se på hvordan Intel er ved a lave Atom til en SoC til MID's.

PC arkitekturen er da også meget fragmenteret. Og det har da aldrig forhindret Linux i at køre på den. Selvfølgelig betyder en stor fragmentering at nogle hardware konfigurationer er så sjældne at de ikke bliver ordentligt testet.

Det største problem med at understøtte Linux på den fragmenterede PC arkitektur har ikke været det store udvalg af hardware men derimod den manglende dokumentation til nogle stykker hardware. Der er meget udbredte stykker hardware som udviklerne ikke har den nødvendige dokumentation til.

kasperd (9) skrev:

PC arkitekturen er da også meget fragmenteret.

Ikke nær så slemt.

I PC'ens barndom blev reglen "man installerer standard MS-DOS pg Lotus 1-2-3 på maskinen - enten virker det eller producenten går konkurs" slået fast.

Og det lukrerer man stadig på.

http://www.itworld.com/mobile-wireless/175829/arm-...

an indication of the scale of this problem, each new kernel release sees about 70,000 new lines of ARM code, whereas there's roughly 5,000 lines of new x86 code added

arne_v (10) skrev:

an indication of the scale of this problem, each new kernel release sees about 70,000 new lines of ARM code, whereas there's roughly 5,000 lines of new x86 code added

Jeg prøvede at kigge på fordelingen fra patch-3.1-rc3. Der var sammenlagt 698755 nye linier, som var fordelt sådan:

25118 arm
12293 x86
35527 andre
443621 drivers
40664 lydkort drivers
54253 dokumentation
87279 andet

Så ja der blev tilføjet mere end dobbelt så mange nye linier under arch/arm som under arch/x86. Men det er stadigvæk småting i forhold til mængden af kode under drivers.

Hvor meget af koden under drivers er til hardware der kun bruges på x86, og hvor meget af koden er til hardware der kun bruges på arm?

#11

Der er sikkert langt mere driver kode til x86.

Men jeg tror at Linus er ret ligeglad med driver kode.

Producenterne af eksotiske hardware dimser laver drivere til deres dimser. Mange dimser => mange drivere => meget kode.

Men det er rart hvis standard hardware virker med standard OS.

arne_v (12) skrev:

Men jeg tror at Linus er ret ligeglad med driver kode.

Hvis man vil sammenligne hvor komplicerede to platforme er bør man selvfølgelig heller ikke gøre det ved at tælle antallet af linier i driverkoden.

Men det er til gengæld relevant at overveje om de forskellige platforme har lavet samme opdeling mellem hvad der ligger i driverkoden og hvad der liver i platforms koden.

Hvis en driver kan bruges uden modifikationer på begge platforme, så er opdelingen i det tilfælde lavet på samme måde. Men hvis et stykke hardware kun bruges på en platform, så er det lidt mindre klart.

Der kan være hardware der er så essentielt at platformen ikke kan bruges uden, skal drivere til den slags hardware ligge det ene eller andet sted? F.eks. findes der jo forskellige typer interrupt controllere og timere til x86 arkitekturen. Jeg ved ikke om koden til det ligger som drivere eller i arch biblioteket.

Hvis driveren helt klart ikke er en del af arkitekturen, så kan der stadig være forskel på hvor meget kode der ligger i arch biblioteket til at supportere drivere. Det kan være den ene arkitektur har mere kode og dermed gør det nemmere at skrive drivere.

Alt dette betyder blot at mængden af kode i arch biblioteket ikke er det endegyldige mål for hvor besværlig en arkitektur er et udvikle til. Men det er selvfølgelig et kraftigt signal.

Egentlig burde man se både på hvor meget kode der er nu og hvor meget der tilføjes. Koden til x86 har eksisteret længere end koden til arm, dermed burde koden til x86 være tættere på at være komplet.

Det vil sige at hvis de to arkitekturer hver for sig kræver lige meget kode burde man forvente at der ligger mere kode i arch/x86 end i arch/arm, men til gengæld at der tilføjes mere ny kode i arch/arm end arch/x86.