Linux-brukere fikk en sjelden mulighet til å høre direkte fra hackere i kjernen av Linux-kjernen på onsdag på LinuxCon Europa. Les videre for mer om tilstanden i ARM i Linux-kjernen, behovet for nye kernel bidragsytere, og døden av Big Kernel Lock (BKL).

Linus Torvalds og andre kjerneutviklere satte seg ned for et spørsmål og svar sesjon ved første LinuxCon Europa. Lennart Poettering, skaperen av Pulseaudio og systemd, fungerte som moderator for panelet, som besto av Torvalds, Alan Cox, Thomas Gleixner, og Paul McKenney. De fire tok forberedt på spørsmål fra Poettering, samt å svare på improvisert publikum medlems spørsmål på hvert emne fra versjonsnumre for fremtiden til kjernen prosjektet selv.

De paneldeltakere presenterte seg først. Torvalds, selvfølgelig, er leder av prosjektet. Cox arbeider primært i system-on-chip i disse dager (selv om han har hatt andre roller i det siste). Gleixner opprettholder sanntidsoppdateringer. McKenney fungerer på lese-copy-oppdateringen (RCU) mekanisme. Sammen står de for bare en liten brøkdel av kjernen samfunnet, men av sine roller og erfaring tilby ivrige innsikt i helsen til kjernen, helsen til kjernen samfunnet, og de retninger det er på vei.

Poettering åpnet med å spørre gruppen om en ofte sitert kommentar av Torvalds at å bryte userspace kompatibilitet var noe som måtte unngås for enhver pris. En fin følelse, Poettering sa, men en som høres hyklersk med tanke på hvor ofte kjernen teamet virkelig bryte kompatibilitet med sine utgivelser – . noen ganger selv med trivielle endringer som overgangen fra 2.6.x versjonsnumrene til 3,0 som skjedde tidligere i år

Torvalds påpekt at ethvert program som antok at kjernen versjonsnummer vil alltid starte med en " 2 " ble brutt allerede, men at kjernen laget hadde også lagt til en " kompatibilitet " modus som ville rapportere versjonsnummeret som 2.6.40 hvis buggy programmer trengte det. Det innkapslet kjernen lagets tilnærming. Legge til noe nytt, men gjør alt for å være sikker på at den gamle måten å gjøre ting fortsatte å jobbe

Torvalds la til at han pleide å holde gamle binærfiler rundt – inkludert de aller første skall skrevet for Linux, som pleide APIer som ble avskrevet i løpet av måneder – å teste mot hverandre nye kjernen utgivelsen, bare for å være sikker på at gamle koden fortsatte å kjøre. API stabilitet er viktig, sa han, men det renner ut av ikke bryte brukeropplevelsen. " Nei prosjektet er viktigere enn brukerne av det prosjektet, " han oppsummert.

Deretter Poettering spurte om det var en aldrende problem med kjernen kjernen utvikling team, og bemerker at gjennomsnittsalderen av delsystemet vedlikehold vokste. Torvalds sa nei, men at det noen ganger virket som det rett og slett fordi det tar tid for en ny bidragsyter til " graduate " fra å opprettholde en enkelt sjåfør å administrere et sett, og til slutt til å håndtere en hel delsystem. De andre ble enige; Cox la til at det var rikelig med " friskt blod " i prosjektet, faktisk mer enn nok, men det var et større problem i kjønnsforskjellene – et problem at ingen syntes i stand til å fikse, til tross for år med å prøve. Mesteparten av den kvinnelige kjerne bidragsytere i dag verket til kommersielle leverandører, sa han; med svært få delta på grunn av sin egen hobby interesse. Torvalds la til at en annen grunn til at det ofte virker som kjernen publikum er raskt aldrende er hvordan latterlig unge de var da de begynte – Han var bare 20 selv, og flere andre viktige bidragsytere var fremdeles tenåringer

Møtedeltakerne spørsmål fra mikrofoner plassert på kanten av scenen, og flere hadde spørsmål om spesifikke funksjoner. Big Kernel Lock (BKL) , kompleksiteten i ARM treet, og om ikke embedded Linux-utviklere fikk så mye oppmerksomhet som utviklere som arbeider på stasjonære og serverplattformer. Cox mimret om BKL, som han kalte den riktige løsningen for de tidlige dagene av multi-prosessor støtte i Linux, selv om det hadde deretter tatt år å erstatte med mer sofistikerte metoder. Det var alltid en plage, sa han, men det fikk Linux SMP støtte mye raskere enn andre operativsystemer, for eksempel BSDene.

ARM arkitektur var kontroversiell i de siste månedene, etter at Torvalds måtte ty til tøffe snakke med få ARM familie å rydde opp sin kode og standardisere mer. Situasjonen er mye bedre i dag, melder Torvalds. Problemet, sa han, er at mens ARM har en standardisert instruksjonssett for prosessoren, har hver ARM bord i en annen tilnærming til andre viktige ting som tidtakere og avbrudd. Intel hadde aldri møtt en slik overflod av inkompatible standarder for x86 arkitekturen fordi PC-plattformen var så jevn, så det har tatt en stund for ARM å se behovet for å ta en mer aktiv tilnærming mot standardisering. Torvalds sa også at for det meste kjernen teamet er veldig interessert i embedded utvikling; hva blir vanskelig er at de fleste embedded Linux enhetene er designet for å være bygget en gang og aldri oppgradert. Det gjør det vanskeligere å gjøre testing og løpende kernel støtte for innebygde plattformer

Når du blir spurt om utfordringene i Linux-kjernen i løpet av de neste årene, McKenney sitert en rekke forskningstemaer overfor alle operativsystemer. Skalerbarhet, sanntid, og validering, for å nevne noen. Torvalds sa opprettholde den rette balansen mellom kompleksitet og evne til å få ting gjort. Selve mengden av ny maskinvare som kommer ut hvert år er overveldende, sa han; holde opp med det er en praktisk (men ikke teoretisk) utfordring for laget.

Snakker av det praktiske, en publikummer spurte Torvalds hva hans prosessen var når du får en ny pull forespørsel fra en bidragsyter. " jeg klarer ved å stole på folk, " svarte han. Når en pull forespørsel kommer inn, ser han på den personen som sendte den. Avhengig av person, varierer sin prosess. Noen mennesker har tjent nok tillit gjennom årene at han tror på sin dom, mens andre har sine egne gjentakende problemer som mandat ekstra gjennomgang

I alle fall, sier han, Han sørger for at den nye koden kompilerer på sin egen maskin fordi han " hater det " når han kan ikke kompilere for sin egen konfigurasjon. Men for det meste, sa han, er hans rolle ikke lenger å validere enkelte deler av koden, men å organisere andres arbeid. Hvis han kjenner to personer jobber på en lignende del av kjernen, trenger han å være klar over det for å avverge sammenstøt, men han stoler vedlikehold av sine individuelle ledd. At tillit er gitt til den personen, gjentok han; den enkelte tjener det, ikke selskapet som den enkelte kan fungere for.

Panelet rørte på andre områder også, inkludert sikkerhet, cgroups, og subsystem bloat. I hvert fall var kommer over i en paneldebatt som dette er hvordan menneskelige prosessen med å skrive og vedlikeholde kjernen er. Kjernen laget kan gjøre feil, og de har til å rute rundt dem med feilrettinger i senere utgivelser. Prioriteringa er kanskje ikke interessert i et bestemt område i utvikling, men de vil se på og enda integrere de patcher fordi de er viktige for en undergruppe av utviklere eller kernel brukere.

Kjernen kan ha bratte tekniske utfordringer, men like virkelig en trussel mot produktiviteten er utbrenthet blant vedlikeholdere. Det er morsomt å se kjernen teamet morsomhet og kommentere på scenen, men det er også en sunn påminnelse om at fremfor alt annet, er Linux et samarbeidsprosjekt, og ikke bare linjer med kode. Anmeldelser