Linus: Overbevist om at vi får andre sprog i kernen

Illustration: © Sergii Broshevan
Drivere og andre ting, der ikke er centrale i Linux-kernen kan skrives i Rust eller andre sprog, siger Linus Torvalds i et interview.

I et interview med VMware's open source-chef Dirk Hohnde har Linux-bossen Linus Torvalds luftet sine tanker om, hvilke sprog der efter hans mening kan anvendes i styresystemets kerne.

Det skriver The Register.

Indtil videre har C været det eneste valg, og sproget har efterhånden mange år på bagen.

»Er der en risiko for, at vi bliver Cobol-programmører i 2030'erne?« spurgte Dirk Hohnde.

»C er stadig et top 10-sprog,« lød svaret fra Linus Torvalds.

Men han nævnte også at til ting, der ikke er specielt centrale i selve kernen, såsom drivere, ser kerneholdet på at have snitflader til at kunne gøre dette, for eksempel i Rust.

»Jeg er overbevist om, at det vil ske. Måske bliver det ikke lige Rust. Men det vil ske, at vi vil have forskellige modeller til at skrive denne slags ting, og C vil ikke være det eneste sprog.«

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (17)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Torben Mogensen Blogger

Selv om C blev udviklet til at skrive UNIX, så har det nogle svagheder til det formål:

  • Der er for mange tilfælde af udefineret og implementationsafhængig opførsel, så man skal kende den specifikke compiler på den specifikke platform for at være sikker på, at koden gør det man mener. Alternativt, gå ind og kontroller den genererede kode, men det fjerner lidt af ideen med at bruge C i stedet for assembler. C kunne have været et udmærket sprog, hvis man fra starten havde specificeret opførslen præcist og maskinuafhængigt, men det er for sent nu.
  • Typesystemet er for svagt, og der er for mange fejl, der slipper igennem -- specielt når man laver lavniveaukode.
  • Lagerhåndteringen er ikke specielt god.

Det giver blandt andet anledning til sikkerhedshuller som f.eks. bufferoverløb.

Rust kunne være et godt bud, men kunne suppleres med ekstremt simple sprog, der er designet til formel verifikation af koden.

  • 7
  • 1
#2 Palle Simonsen

Hvis man læser artiklen har Linus nogle ret gode betragtninger om C og C++.

En del kan kortes ned til den meget direkte kontrol man har i C - det er åbenbart hvad koden gør (hvis altså man kan læse C). Den primære anke Linus har mod C++ er at for meget gemt væk i abstraktioner der i Linus' optik ikke giver fornøden værdi.

Mht. den maskinafhængig ordlængde på visse typer i C er det noget som enhver C programmør er opmærksom på, når det er relevant. Hvis man ikke ved hvornår det er af betydning bør man lave noget andet.

Typesystemet er mindre dogmatisk end i C++ og langt mindre end i f.eks. Dart eller (sic) Typescript og kan bekvemt overrides når det er nødvendigt, men det kræver en handling.

Lagehåndtering - hmm - joh der har Rust bestemt en fordel :)

I min erfaring er C et stærkt værktøj til en række opgaver i hænderne på en kapabel programmør. Har man middelmådige programmører til sin rådighed bør man lave andre opgaver eller bruge andre sprog.

  • 3
  • 2
#4 Palle Simonsen

(sic) går på Typescript som sådan. Javascript er i sig selv et ret elegant sprog - med et par quirks - Typescript tilfører en langsommere build, source map, som næsten altid kan debugges, OO syntax, java lignende interfaces og et typesystem - heldigvis er der < any> til når transpileren forvirrer sig selv og dine annotationer kun giver fejl-på-fejl.

Javascript er et dynamisk funktionelt sprog, medens de fleste mainstream sprog er statiske OO sprog hvilket vel forklarer hvorfor TS er født.

Så - lidt samme argument som Linus' vedr. C/C++

  • 2
  • 2
#6 Mads Thomsen

Javascript er et dynamisk funktionelt sprog, medens de fleste mainstream sprog er statiske OO sprog hvilket vel forklarer hvorfor TS er født.

Javascript er multi-paradigme. Det er et ret voldsomt stretch at kalde det et funktionelt sprog, bare fordi man kan bruge diverse teknikker fra funktionsprogrammering. Med den logik er Java, C# og python også funktionelle sprog.

  • 4
  • 0
#7 Per Dalgas Jakobsen

Jeg ville ønske at Ada/SPARK fik en langt større udbredelse end det har i dag. Typesikkerhed der virker, tasking som en integreret del af sproget, distribueret processering, veldefineret opførsel, fin interfacing med sprog som C, verifikation, etc... - At vedligeholde og forbedre et +1MSLOC system er faktisk til at håndtere! Største anke mod Ada er som regel udbredelsen. Hvis det blev introduceret i Linux kernen, ville dette givetvis ændre sig.

Man har vel lov at håbe :-)

  • 3
  • 2
#8 Poul-Henning Kamp Blogger

Jeg ville ønske at Ada/SPARK fik en langt større udbredelse end det har i dag.

Her kommer vi ikke udenom at ISO-C folkene udgør den største trussel imod C som sprog.

Det havde været trivielt at importere gode ideer fra andre sprog.

F.eks kunne man have "stjålet" Ada's glimrende ide med at specificere hvilket range integer variable skal have (Integer range 1..10;) hvilket både ville gøre koden mere selv-dokumenterende og samtidig givet compilere og statiske analyseværktøjer noget at bide i.

Man kunne også have kigget på hvad C i meget stort omfang bliver brugt til frem for andre sprog, og have tilføjet explicit struct layout og endianess og derved gøre C til verdens bedste sprog til data-udveksling og hardware interface:

struct foobar {  
    int32_t > @0;  
    int8_t @11;  
    int64_t > @12;  
}

Endelig kunne man have givet C et simpelt klasse-koncept, i stil med den "C-with-classes" som Bjarne havde lavet i starten af 1980'erne, fordi rigtig meget C-kode er OO kode der må vride sig selv som klejner for at implementere OO i et sprog der ikke har det.

Når den slags indlysende og "gratis" ting netop ikke kommer med i ISO-C, kunne man nemt få det indtryk at dem der vedligeholder ISO-C standarden har et skjult agenda med at skræmme folk bort fra sproget.

  • 8
  • 1
#9 Troels Henriksen

Når den slags indlysende og "gratis" ting netop ikke kommer med i ISO-C, kunne man nemt få det indtryk at dem der vedligeholder ISO-C standarden har et skjult agenda med at skræmme folk bort fra sproget.

Til gengæld har vi fået noget så nyttigt som komplekse tal og type-generiske makroer!

Jeg synes C11 går lidt mere i den rigtige retning, og tilføjer f.eks. en ordentlig hukommelsesmodel og (noget mere tvivlsomt) trådsupport i standardbiblioteket (i praksis bare pthreads), samt reelt nyttige ting som alignment og statiske assertions. Det er stadigvæk for lidt og for sent.

  • 5
  • 0
#12 Torben Mogensen Blogger

F.eks kunne man have "stjålet" Ada's glimrende ide med at specificere hvilket range integer variable skal have (Integer range 1..10;)

Ja, det er en glimrende ide, og Ada har selv "stjålet" denne ide fra Pascal. Ideelt set burde heltal enten angive eksplicitte grænser eller være ubegrænsede. Et sprog kan sagtens understøtte begge slags.

Pascal og Ada påbyder, at det checkes, om et tal, der gemmes i en variabel, ligger i det angivne interval. Det sker som regel på køretid, hvilket nok ikke egner sig til kerneprogrammering. Men man kunne kræve, at der kommer warnings, hvis det ikke kan verificeres på compiletid. For at undgå alt for mange warnings, kan en programmør indsætte assertions, som kan hjælpe analysen og evt. indsætte "jeg ved, hvad jeg gør" klausuler på de steder, hvor compileren ikke kan verificere det. Alt for mange af disse bør dog betragtes som dårlig kodestil, og der bør være et compilerflag, der indsætter køretidstest ved disse, sådan at man under afprøvning kan fange fejl, men i produktionskoden slå disse checks fra af performancehensyn.

  • 0
  • 0
#13 Per Dalgas Jakobsen

Pascal og Ada påbyder, at det checkes, om et tal, der gemmes i en variabel, ligger i det angivne interval. Det sker som regel på køretid, hvilket nok ikke egner sig til kerneprogrammering.

Compilerne er efterhånden så gode at forbavsende mange tjeks sker compile-time. Input "udefra" skal tjekkes (men det bør man jo gøre under alle omstændigheder). Bruger man SPARK Silver level er de tjeks forøvrigt helt unødvendige, for så har du bevist at du har tjekket hvad der bør tjekkes.

Når man nu (så let) har mulighed for at bevise fraværet af run-time exception, bør Kerneprogrammering selvfølgelig inkludere dette.

  • 1
  • 0
#15 Per Dalgas Jakobsen

Kan du give et par eksempler på C-kode, som er implementationsafhængig af compileren?

Du laver sjov, ikk'?!? Men ok, jeg leger med:

Hvad er resultatet af følgende, med din compiler? Hvad burde resultatet være i henhold til standarden?

#include <stdio.h>  
   
void main (void)  
{  
    short int a = 65535;  
    short int b = a >> 1;  
    printf ("%d, %d\n", a, b);  
}

Tag gerne http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf og søg på "implementation-defined".

  • 0
  • 0
#16 Sune Marcher

Kan du give et par eksempler på C-kode, som er implementationsafhængig af compileren?

CVE-2009-1897 i Linux – RedHat har et fint lille writeup. Eller Towards optimization-safe systems: analyzing the impact of undefined behavior.

C og C++ ville sandsynligvis miste en uacceptabel mængde performance, hvis optimizerne ikke måtte udnytte UB (jeg læste engang en god artikel om det, men fik desværre ikke gemt linket) – og reglerne er så subtile at selv yderst dygtige udviklere rammer ved siden af.

  • 0
  • 0
Log ind eller Opret konto for at kommentere