V2-blogger: FreeBSD 8.0 markerer begyndelsen til enden for GCC

FreeBSD-udviklerne har arbejdet på at erstatte open source-compileren GCC med opkomlingen Clang. Med den kommende FreeBSD 8.0 er man tæt på målet, og FreeBSD 9.0 vil formentlig være helt fri af GCC.

Den kommende version 8.0 af operativsystemet FreeBSD er nu gået ind i betafasen og er efter planen klar til endelig udgivelse 31. august.

Den nye version indeholder ifølge den danske FreeBSD-udvikler og Version2-blogger Poul-Henning Kamp primært en masse småforbedringer, men samtidig markerer FreeBSD 8.0 begyndelsen til enden for 'hus-compileren' GCC, der i mange år har været en fast grundpille i FreeBSD.

Hele operativsystemet kan nu stort set oversættes med Apples Clang-compiler, der benytter compiler-infrastrukturen LLVM som back-end, og når FreeBSD runder version 9.0, vil Clang sandsynligvis have overtaget GCC's plads fuldstændigt.

»Det er endnu ikke godt nok til at release FreeBSD 8.0 uden GCC, men det er et klart skud for boven af GCC. FreeBSD 9.0 bliver sandsynligvis Clang-baseret,« skriver Poul-Henning Kamp i en e-mail til Version2.

Som Version2 tidligere har kunnet skrive, har FreeBSD-folkene i en periode arbejdet på at blive helt fri af den gamle og udbredte samling compilere fra GNU-projektet, GCC, for i stedet at bruge Clang.

Clang kan nemlig oversætte operativsystemets kodebase omkring dobbelt så hurtigt som GCC, og derudover kan afviklingen af Clang-oversat FreeBSD-kode i visse tilfælde blive op til 20-30 procent hurtigere.

Samtidig passer den tilhørende softwarelicens bedre ind i FreeBSD's kram.

Jails har fået en overhaling

Ifølge Poul-Henning Kamp følger FreeBSD 8.0 den generelle tendens med, at ulige versioner indeholder nye features, og lige versioner fokuserer på stabiliteten.

»Der er ikke nogen 'big ticket items' i FreeBSD 8.0, men derimod hundredvis af små forbedringer,« skriver Poul-Henning Kamp.

»Hvis du kigger på den foreløbige release note, er det et langt litani af 'Bla has been added', 'Foo now supports' og 'Mumble has been overhauled',« tilføjer han.

Udover Clang-understøttelsen er der dog også et par andre større nyheder, som ifølge Poul-Henning Kamp er værd at fremhæve - selvom han ikke hævder at se lyset i dem alle.

»Det er nu også muligt at have et system, der kun kører IPv6, hvilket i mine øjne en bizar måde at implementere en firewall på, men det kan vi altså nu,« skriver Poul-Henning Kamp.

Samtidig har Poul-Henning Kamps egen virtualiserings- og sikkerhedsmekanisme, Jails, fået en overhaling af, hvad han kalder en 'flok energiske unge mennesker'.

»Nu kan man for eksempel have både IPv6- og IPv4-adresser på samme jail, der er kommet support for SCTP (Stream Control Transmission Protocol, red.), og jails kan nu låses på bestemte CPU'er. Lidt parallelt med det tillader en ny virtualisering af netværksstakken kaldet Vimage, at hvert jail, eller for den sags skyld hver proces, får sin helt egen netværksstack med route-tabel, interfaces osv.,« skriver Poul-Henning Kamp.

Som et sidste punkt nævner Poul-Henning Kamp en helt ny USB-stack:

»Den har fordelen af at være den første USB-stack, der er skrevet efter vi fandt ud af, hvad og hvordan USB bruges. Så der er lagt fokus på det, der betyder noget, og features, der aldrig bruges, er udeladt,« lyder det fra Poul-Henning Kamp.

FreeBSD har lige nu versionsnummeret 7.2 i sin stabile form. Beta 1 af FreeBSD 8.0 blev lagt ud til download og test 7. juli, mens anden beta fulgte 13. juli.

  1. juli kommer tredje betaudgivelse efterfulgt af første release candidate 27. juli, og forløbet sluttes af 17. august med release candidate 2, inden den færdige FreeBSD 8.0 efter planen er klar til download 31. august.
Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (22)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#2 Lars Sommer

Men hvilke? - Jeg kan ikke se nogen smartere, men jeg har heller ikke holdt mig opdateret på området.

Hvis der er et par sprog der er smartere, kræver det jo efterfølgende også at de folk der er dybt inde i FreeBSD-udviklingen, og i C, sætter sig ind i dem.

Her er forresten en spændende længere snak om nyhederne i FreeBSD 8 også: http://ivoras.sharanet.org/freebsd/freebsd8.html

  • 0
  • 0
#4 Torben Mogensen Blogger

Man bør nok droppe ideen om, at alting skal kodes i det samme sprog. Mulige sprog kunne være Cyclone [http://en.wikipedia.org/wiki/Cyclone_(programming_language)] til lavniveaukode (drivere, event handling, resource management osv.), SML, OCaml og Haskell til højereniveaukode. Linspire bruger f.eks. OCaml og Hakell som hovedsprog til OS udvikling (se http://urchin.earth.li/pipermail/debian-haskell/2006-May/000169.html).

  • 0
  • 0
#5 Jacob Sparre Andersen

Når man bruger LLVM, kan man i princippet bruge ethvert sprog, der oversætter til LLVM, så det er måske på tide at migrere væk fra C og hen til en samling af mere moderne sprog.

Og hvor er forskellen til GCC i det? Du kan for eksempel skrive kernemoduler til Linux i Ada (med visse begrænsninger), hvis du skulle have den slags lyster.

/Jacob

  • 0
  • 0
#6 Poul-Henning Kamp Blogger

Vis mig et bedre sprog end C til at skrive en kerne i, og jeg skal være den første der skifter.

Bemærk at vi taler kerner til produktion i firmaer der lever af at få programmer til at køre, ikke kernel som i "Min teori holder fint, så længe jeg ikke prøver at implementere alle de svære ting i en kerne".

Personligt håber jeg på at vi får en opgradering af C, f.eks med linkede lister, big/little endian og padding specifikation af structs og preprocessor support for maskingeneredede data.

Eventuelt, kunne man lave en helt simpel klassefacilitet, så structs får member functions, men glem alt om multiple-inheritance og alt det crap.

Og nej, C++ er ikke svaret, det siger Bjarne selv :-)

Poul-Henning

  • 0
  • 0
#7 NA NA

Vis mig et bedre sprog end C til at skrive en kerne i, og jeg skal være den første der skifter.

Hvad var det lige der var galt med D eller Cyclon som Torben nævnte ? Umiddelbart virker det som sprog som ligger meget tæt op af C bare med nogle ekstra features.

  • 0
  • 0
#8 Michael Rasmussen

Vis mig et bedre sprog end C til at skrive en kerne i, og jeg skal være den første der skifter

Er sandhenden ikke den, at den måde vi designer, og definerer, kerner i dag, er en funktion af mulighederne i C? Det er vel heller ikke tilfældigt, at Ritchie (og Thompson) skabte C med henblik på at implementerer Unix.

  • 0
  • 0
#10 Anonym

Vis mig et bedre sprog end C til at skrive en kerne i, og jeg skal være den første der skifter.

Bemærk at vi taler kerner til produktion i firmaer der lever af at få programmer til at køre, ikke kernel som i "Min teori holder fint, så længe jeg ikke prøver at implementere alle de svære ting i en kerne".

Jeg tror jeg har skrevet det før men: HP3000 seriens MPE/iX var lavet i modcal (=modificeret pascal), hvor 'mod' delen gav adgang til noget low-level kodning.

Stratus (som også blev solgt som IBM/Olivetti), var også lavet i pascal, OS'et var(er) VOS.

Da vi besøgte fabrikken kørte de med 68030 på hoved CPU'erne, 68020 på intermidiate CPU'er, og 68010 i peripherals.

Alle niveauer var også lavet i pascal.

Her er der tale om nogle af de mest stabile systemer, og ikke noget 'hjemmehøker'.

At C er blevet sp udbredt tror jeg nærmere hænger sammen med, at den var gratis, hvorimod vi f.eks. skulle betalte 75.000,- for en Pascal compiler.

  • 0
  • 0
#11 Jørgen Henningsen

Mulige sprog kunne være Cyclone

Ok Torben, du har overbevist mig. Lad os slagte "C". Men her kommer så udfordringen fra det virkelige liv: Jeg sidder lige nu og koder lavniveau funktioner til en LPC2368. Jeg bruger GCC(Yagato), Freertos og eclipse. Hvad er mine alternativer til C/C++ og hvordan får jeg dem testet i praksis?

  • 0
  • 0
#12 Poul-Henning Kamp Blogger

Stig skriver:

HP3000 seriens MPE/iX var lavet i modcal (=modificeret pascal), hvor 'mod' delen gav adgang til noget low-level kodning.

Stratus (som også blev solgt som IBM/Olivetti), var også lavet i pascal, OS'et var(er) VOS.

Jeg har ikke sagt at der aldrig har været skrevet kerner i andet end C.

Jeg påpeger blot at de ikke er konkurrencedygtige og derfor ikke er at finde på markedet mere.

C vinder fordi det er istand til at udtrykke vores abstraktioner til anvendelse på den hardware vi har at køre på.

Man kan som DEC forsøgte med Alpha, prøve at proppe de værste af abstraktionerne ned i hardwaren, eller man kan vælge sig nogle helt andre abstraktioner(ie: drop POSIX), men ingen af delene er konkurrencedygtigt i markedet.

Poul-Henning

  • 0
  • 0
#13 Torben Mogensen Blogger

Vis mig et bedre sprog end C til at skrive en kerne i, og jeg skal være den første der skifter.

Bemærk at vi taler kerner til produktion i firmaer der lever af at få programmer til at køre, ikke kernel som i "Min teori holder fint, så længe jeg ikke prøver at implementere alle de svære ting i en kerne".

Ethvert højniveausprog med mulighed for at "escape" til usikker lavniveau kode, når behovet opstår, vil være gode alternativer. Hovedproblemet ved C er, at det hele er usikker lavniveaukode.

Der findes højniveausprog (som f.eks. Cyclone), der giver adgang til lavniveauoperationer under sikrede forhold, uden at det sætter væsentlige begrænsninger i, hvad du kan gøre -- i værste fald tilføjes nogle få køretidstests på de steder, hvor statisk analyse ikke kan garantere sikkerhed.

Men givet nogle få interfacefunktioner lavet i assembler, kan du gøre det hele i et højniveausprog. Se f.eks. http://ogi.altocumulus.org/~hallgren/ICFP2005/ eller http://www2.hawaii.edu/~esb/prof/proj/hello/ .

  • 0
  • 0
#14 Jacob Sparre Andersen

Hvis højniveausproget har brug for et køretidsmiljø af en art (hvilket vist ikke er helt usædvanligt), så er sagen ikke helt så enkel.

Hvis man (for eksempel) vil bruge hele Ada, er der for eksempel ingen vej udenom at oversætteren skal sørge for at løse en del køretidsopgaver (den mest indlysende er nok håndteringen af "tasks"). Det hænger dårligt sammen med at skrive et styresystem. Løsningen på det problem er så at implementere sit styresystem (eller sine kernemoduler til Linux) i en delmængde af Ada, der er kendetegnet ved ikke at have brug for et køretidsmiljø fra oversætteren.

Dette betyder ikke at det er en dårlig idé at skrive styresystemer i højniveausprog. Det er bare ikke et vilkårligt højniveausprog der kan bruges til opgaven.

  • 0
  • 0
#15 Poul-Henning Kamp Blogger

@Torben:

Hvornår har du sidst gravet dig rigtig godt ned i en virkelig kerne ?

Fra det øjeblik du foretager et trap eller systemkald, består en kerne stort set udelukkende af det du kalder "usikker lavniveau kode", hele vejen ned til hvor skilpadderne begynder.

Sidst jeg checkede var der ingen sprog på listen over sprog der forstår fremmede addresserum og skiftende aliasering imellem fremmede og lokale addresserum for det nuværende exekveringspunkt ?

Læg mærke til at jeg skrev "ingen": C forstår heller ikke den slags, men i modsætning til alle højniveausprog jeg har kigget på, står C heller ikke i vejen for performance fornuftig håndtering af den slags problemer.

Et af de altoverskyggende problemer for højniveausprog er at de er designet til at køre i den virtuelle maskine POSIX giver en process og derfor gør de antagelser som "der er kun et addresserum - mit! - og jeg kan rode i det som det passer mig".

I en kerne har du et stort antal addresserum som i det foreliggende tilfælde kan eller ikke kan være tilgængelige, compileren kan ikke uden videre give sig til at pille ved ting den har hørt om, de er måske slet ikke tilstede i addresserummet.

Den klassiske akademiske løsning på det problem er at skrive højtravende papers om mikrokerner, implementere en sådan der tager sig af addresserums problematikken, skrive et paper eller to mere når to processer kan tale sammen over pipe(2) og derefter give sig til at lave noget andet.

Men jeg glæder mig til at se din POSIX kerne, skrevet i Cyclone, specielt glæder jeg mig til at se din implementering af ioctl(2) for CD-drev og rename(2) for dit filsystem.

Imellemtiden, kører du og jeg og resten af verden kerner der er skrevet i C, fordi det virker.

Poul-Henning

  • 0
  • 0
#16 Anonym

Jeg har ikke sagt at der aldrig har været skrevet kerner i andet end C.

Jeg påpeger blot at de ikke er konkurrencedygtige og derfor ikke er at finde på markedet mere.

Det siger jeg heller ikke.

Konkurrencedygtige, kan man diskutere, men HP besluttede omkring årtusindeskiftet, af de er [b]hardware[/b]-leverandører.

HW mæssigt, har det været fysisk samme HW[1] om man købte en HP9000(HP-UX) eller en HP3000(MPE/iX).

[1] Siden de (HP) gik fra CISC til RISC.

Jo, MPE'en var lidt dyrere, da den performede bedre en UX, og da prissætningen gik på TPS, så var UX'en ca. 20 % billigere end MPE'en. (MPE performede ca. 20% bedre end UX).

Jeg angriber ikke at *nix versioner har en bedre markedsfordel, ligesom burhøns er foretrukke i forhold til bedre kvalitet.

Kun en observation.

'Burhønseeffekten' kalder jeg det.

Nåh ja, jeg går også ud fra at man foretrækker/foretrak en trabant..... hvis man er ude efter en 'bil'.....

  • 0
  • 0
#17 Poul-Henning Kamp Blogger

Jeg er ikke helt sikker på at jeg kan gennemskue dit indlæg, er det et eller andet nedladent forsøg på at antyde at "alting var bedre i gamle dage" ?

At HP besluttede sig for at blive hardware firma skyldes i stort omfang at de ikke kunne finde ud af at lave et operativsystem kunderne ville køre.

Poul-Henning

  • 0
  • 0
#18 Anonym

er det et eller andet nedladent forsøg på at antyde at "alting var bedre i gamle dage" ?

Nej, det var en bekræftelse af, at det er markedet(=kunderne), der driver udviklingen.

Uanset hvor gode OS'er/systemer man laver, har det ingen værdi, hvis der ikke er aftagere til disse.

Som nævnt var HP3000 og HP9000 serien fysisk samme hardware, så jeg vil gætte på, at beslutningen om at discontinue HP3000 serien hænger sammen med at merværdisalget ikke kunne retfærdiggøre omkostningerne ved at vedligehole OS'et.

Lidt på samme måde med PC'ere. HP, og andre, er formentlig ligeglade med om der ligger Windows eller andet på maskinerne, bare de får solgt dem.

Her skal man også lave en økonomisk afvejning af, om besværet med at præinstallere/supportere f.eks. linux vil skabe det nødvendige mersalg for at dække omkostningerne.

  • 0
  • 0
#19 Anonym

Beslutningen om [b]kun[/b] at være hardwareleverandør havde noget at gøre med ERP-systemer og tilhørende supportorganisation, og ikke OS'et.

  • 0
  • 0
#20 Torben Mogensen Blogger

Hvornår har du sidst gravet dig rigtig godt ned i en virkelig kerne?

Ikke siden det var i PDP-11 assembler, det giver jeg dig.

Men indtil videre har dine argumenter for C primært været, at det er det bedste, fordi det er det, der bliver brugt, og alternativerne ikke duer, fordi der ikke er lavet andet end eksperimentelle operativsystemer med dem. Det er den slags tankegang, der hindrer udvikling. Alt skal starte i det små. Unix var også engang et eksperimentelt operativsystem skrevet i et uprøvet sprog. Hvorfor vil du ikke give chancen til andre sådanne? Har du i det hele taget set på de artikler, jeg linkede til?

  • 0
  • 0
#21 Poul-Henning Kamp Blogger

Det argument holder simpelthen ikke.

Når du påstår at der er programmeringsprog der kan gøre det bedre end C, så er det et helt legitimt argument at sige "show me the code".

Ja, jeg har læst artiklerne, men de gav mig igen grund til at tro at der er et sprog der er bedre end C til at skrive en kerne i: Ingen af dem forholdt sig til det der faktisk er det problematiske i en kerne: multiprogrammering, krydskontext referencer, multiple addresserum og hardwaredikteret datapakning.

Hvis vi skal have et nyt systemprogrammeringsværktøj, så skal sprogdesigneren starte med at angribe de svære problemer, det hjælper os ikke hvis han plukker et par af de lavest hængende æbler og efterlade grizzlybjørnen som hjemmearbejde.

Poul-Henning

PS: Og lige et spring tilbage til compilervalget, var jeg den eneste der fik krydderen galt i halsen over denne her ?

The vulnerability is located in several parts of Linux, including one that implements functions known as net/tun. Although the code correctly checks to make sure the tun variable doesn't point to NULL, the [GCC] compiler removes the lines responsible for that inspection during optimization routines.

  • 0
  • 0
#22 Torben Mogensen Blogger

Ja, jeg har læst artiklerne, men de gav mig igen grund til at tro at der er et sprog der er bedre end C til at skrive en kerne i: Ingen af dem forholdt sig til det der faktisk er det problematiske i en kerne: multiprogrammering, krydskontext referencer, multiple addresserum og hardwaredikteret datapakning.

Men det gør C jo heller ikke, som du indrømmede. Så det er jo ikke noget argument mod at bruge andre sprog, så længe de tillader dig at bruge lavniveaukode, når der er behov, så du kan lave dine egne implementeringer af disse ting.

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