När Intel och dess dotterbolag Windriver föreslog för Linxustiftelsen att adoptera dess operativsystem Zephyr, kunde det bocka av de grundläggande kraven:

• Det hade en bra öppenkodsli­cens, Apache 2.0, som är kom­patibel med Linux

• Det hade ett litet fotavtryck – ner till 2 kbyte för ”Hello World” och ner till 8 kbyte för en mer realistisk tillämpning

• Det hade ett aktivt community. Eller, nja, här kan man kan­ske sätta ett litet frågetecken med tanke på att Zephyr bara hade existerat som öppen käll­kod i tre månader när det adop­terades.

Man kan faktiskt sätta ytterli­gare ett frågetecken efter ”aktivt community”. I likhet andra öp­penkodsprojekt med företag i ryggen, får det kritik för att vara toppstyrt och kommunicera då­ligt mot mindre företag och hob­byister.

Motsvarande kritik finns i Linuxvärlden, allteftersom det kommersialiserats. En vik­tig skillnad är dock att de högsta hönsen i Linux är företagsobero­ende. De kan säga nej, medan Zephyrs representanter inte kan förväntas gå emot instruktioner från sina respektive företag.

• Operativsystemet skulle inte vara för starkt knutet till en viss arkitektur. Check. Tre av de fyra kort som stöddes från start var visserligen Intelkort, men idag finns en rik flora av Arm­kort. Också Arc, Xtensa, Risc­-V och Nios II finns representerat.

• Det skulle stödja säkerhet. Här framhävs att Zephyrär statiskt konfigurerat – ingen ny kod kan laddas medan operativsystemet körs. Detta mins­kar den yta som måste försva­ras mot angrepp. Om det finns skadlig kod i Zephyr så kan den bara ha stoppats dit vid kom­pileringen. Den statiska konfi­gureringen gör det som bonus enklare att ge Zephyr realtids­egenskaper.

• Operativsystemet skulle ha en rik funktionalitet. Det skulle vara ett stort steg upp från ”bare metal” – att köra system helt utan operativsystem. Zephyr bjuder på avbrottshantering och kan köra parallella program i trådar, som kan kommunicera med varandra. Det går att välja mel­lan olika regeluppsättningar för hur tiden ska fördelas mellan trådar med olika prioritet. Det finns dynamisk minne och det finns strömstyrning.

Det putsas fortfarande ordent­ligt på Zephyr. Och det är inte bara smärre ansiktslyftningar det handlar om, utan i flera fall omgörningar från grunden.

Detta kanske till och var något som lockade med Zephyr när det valdes – att det fanns grund­läggande saker kvar att göra. Att det var ett renoveringsobjekt – en oslipad diamant som kunde skräddarsys från grunden för det relativt nya tillämpningsområdet IoT.

Denna artikel har tidigare publicerats i magasinet Elektronik­tidningen. För dig som jobbar i den svenska elektronik­branschen är Elektronik­tidningen gratis att prenumerera på – våra annonsörer betalar kostnaden. Här ansöker du om prenumeration (länk).

Zephyr ska upprustas till en one­-stop­-shop för IoT. Om du vill bygga en IoT­tillämpning ska du inte behöva söka efter komponenter på andra håll. ”Om du använder Zephyr ska du få all kommunikation du behö­ver på köpet, och vi lovar att hålla koden uppdaterad och trimmad” – det är budskapet. Du ska kunna fokusera på din app och låta Zephyr ta hand om resten.

Bluetooth Mesh är ett bra ex­empel. Det fick stöd i au­gusti i fjol bara en månad efter att standarden släpptes, genom Intels försorg

Windriver började slipa på Zephyr redan innan det adop­terades. På biblioteksfronten genom att addera några av de grundläggande nätverksstack­arna och ett kryptobibliotek kallat Tinycrypt. På kärnfronten genom att skapa en ren modell för komponenter. Den innebär att det går att ladda bara exakt de delar av operativsystemet som ett visst projekt behöver.

En grundläggande föränd­ring som pågår är att stuva om Zephyrs nuvarande dubbla operativsys­temskärnor till en enda.

Dina tillämpningar kan idag köras dels i en mikrokärna, och dels i den nanokärna där bland annat mikrokärnan körs. Att de två blir en – med bibehållna gränssnitt för bakåtkompatibilitet – tar bort några dubblade funktionaliteter och spar ett par kilobyte minne.

En annan fundamental lucka var avsaknaden av minnesskydd. Detta adderades så sent som i mars.

Att låta alla program dela på samma minne kan möjligen vara acceptabelt i välorganise­rade avgränsade projekt. Men när komponenter, blandas från olika håll, som kommer att ske i Zephyr, är minnesskydd ett minimalt säkerhetskrav.

Dessutom är minnesskydd en ovärderlig buggfälla, särskilt med tanke på att tillämpningar i Zephyr typiskt skrivs i programspråket C, som är ett språk där det är lätt för programmeraren att välja ickerobusta lösningar och att göra misstag.

Fortfarande handlar det bara om ett enkelt minnesskydd som utnyttjar den typ av MPU som finns i exempelvis Cortex M. Men ett projekt för dynamiskt minnesskydd för MMU­-utrusta­de processorer har också startat.

Firmwareupdatering under drift över Bluetooth LE var en annan funktionalitet som kom på plats i mars, liksom stöd för Precision Time Protocol som gör det möj­ligt för noder i ett system att ar­beta tidssynkroniserat.

En kommande säkerhetsupp­gradering, som ingen mindre USA:s spionorganisation NSA bidrar med, är ASLR (address space layout randomization) som innebär att objekt placeras ut på slumpmässigt valda adres­ser, för att en angripare inte ska kunna veta på förhand var i min­net målet för attacken befinner sig.

NSA har tidigare utvecklat verktyg som söker – och också har hit­tat – säkerhetshål och buggar i Zephyrs kärna.

Zephyr stöder idag bland annat Ipv4, IPv6, Bluetooth LE, Wifi, 802.15.4, NFC och 6lowpan. Google Thread fick stöd i mars.
Komponenter plockas från olika håll. Till exempel lånades den första versionen av TCP/IP-stacken från svensken Adam Dunkels öppna operativsyste­m Contiki.

Och, i Linux anda, i den ut­sträckning det är något du sak­nar så är det din klåda att klia och du är välkommen att bidra med din egen implementation.