Maestro-skjermbilde
Rust har fått nok popularitet i en slik grad at det har blitt en av de som er valgt til å integreres som sekundærspråk i Linux, så vel som i andre operativsystemer, slik er tilfellet med Android, som allerede har en del av koden i Rust, Windows som også har gitt godkjenningen bl.a.
Rust har vist seg å være et robust språk og har skapt slik tillit Noen operativsystemer har til og med blitt laget med dette programmeringsspråket, og for å nevne noen har vi: Redoks, Vi har også kjerner skrevet fra bunnen av som f.eks Kerla eller kjernen som brukes i satellitt som Kina nylig har skutt opp.
Grunnen til å nevne dette er at jeg nylig kom over en nyhet som fanget min oppmerksomhet, og det er at Det ble presentert et prosjekt der en kjerne skrevet i Rust utvikles og som er delvis kompatibel med Linux.
Navnet på dette prosjektet er "Lærer" og som nevnt, er en Unix-lignende kjerne skrevet i Rust som implementerer et undersett av systemanrop fra Linux-kjernen tilstrekkelig til å skape standard arbeidsmiljøer. Som sådan er ikke «Maestro»-prosjektet noe nytt, siden utvikleren nevner at prosjektet ble født i 2018, men på den tiden ble det skrevet i C og på grunn av de ulike fordelene og egenskapene til Rust ble prosjektet skrevet om fra null.
PÃ¥ prosjektsiden Ã…rsakene til endringen er beskrevet:
I det øyeblikket bestemte jeg meg for å bytte til Rust (mitt første prosjekt på dette språket), som representerte flere fordeler:
- Start prosjektet på nytt fra begynnelsen ved å bruke erfaringer fra tidligere feil.
- Vær litt mer nyskapende enn å bare skrive en Linux-lignende kjerne i C. Tross alt, bruk Linux på den tiden.
- Bruk sikkerheten til Rust-språket for å dra nytte av noen kjerneprogrammeringsvansker. Ved å bruke Rust-skrivesystemet kan du overføre noe av ansvaret for minnesikkerhet fra programmereren til kompilatoren.
I kjerneutvikling er feilsøking veldig vanskelig av flere grunner:
- Dokumentasjon er ofte vanskelig å finne og BIOS-implementeringer kan være buggy (oftere enn du tror).
- Ved oppstart har kjernen full tilgang til minne og kan skrive der den ikke skal (for eksempel sin egen kode).
- Det er ikke lett å feilsøke minnelekkasjer. Verktøy som valgrind kan ikke brukes.
- gdb kan brukes med QEMU og VMWare, men kjernen kan oppføre seg annerledes når den kjøres på en annen emulator eller virtuell maskin. Det kan også hende at disse emulatorene ikke støtter gdb (f.eks. VirtualBox).
- Noen funksjoner mangler fra gdb-støtte i QEMU eller VMWare, og gdb kan til og med krasje noen ganger
I forhold til kjennetegn ved prosjektet, skiller det seg ut at kjernen er monolitisk og støttes foreløpig kun på x86-systemer i 32-bits modus. Kjernekodebasen dekker omtrent 49 tusen linjer, og kan kjøres både på ekte maskinvare og i virtualiserte miljøer, som QEMU eller VirtualBox.
I den nåværende utviklingen av «Maestro», 31 % er implementert (135 av 437) av Linux-systemanrop. Dette er nok til å laste et konsollmiljø basert på Bash og Musl standard C-bibliotek. I tillegg kan det Maestro-baserte miljøet kjøre noen verktøy fra GNU coreutils-pakken og grunnleggende innpakning fra ethvert Unix-system. For tiden jobbes det med å implementere en nettverksstack og det jobbes også med å utvikle en
Blant de Maestros tilgjengelige funksjoner skiller seg ut følgende::
- Kontrollere for PS/2-tastatur og terminal med tekstmodus og delvis støtte for ANSI-sekvenser.
- Minneallokeringssystem med støtte for virtuelt minne.
- Oppgaveplanlegger basert på round-robin-algoritmen med støtte for POSIX-signaler.
- Definisjon av PCI-enheter.
- IDE/PATA-kontroller.
- Ext2 filsystem.
- Støtte for virtuelle filsystemer /tmp og /proc.
- Evne til å montere FS-, MBR- og GPT-diskpartisjoner.
- initramfs-støtte.
- RTC-kontroller for timer og presis tid.
- Støtte for lasting av kjernemoduler.
- Evne til å kjøre kjørbare filer i ELF-format.
For interessert i å lære litt mer om prosjektet, kan du sjekke detaljene I den følgende lenken. Når det gjelder de som er interessert i prosjektkoden, bør de vite at det er det distribuert under MIT-lisensen.