Discussie Vireo II

m44rtn

Gevestigd lid
Zoals aangegeven in het voorgaande topic Vireo kernel, wilde ik beginnen aan een nieuwe, verbeterde Vireo kernel. Hier wil ik graag in dit nieuwe topic dieper op in gaan. Verder wil ik ook graag vragen beantwoorden, en naar feedback luisteren. Voor feedback hoef je niks te weten over programmeren en alle feedback is welkom: kwaliteit van de documentatie bij Vireo, de doelen van Vireo, wat jullie zelf graag zouden willen zien, etc. Zelfs feedback over de updates op dit forum mag je hier kwijt.

De Vireo kernel bestaat sinds deze maand uit twee smaken: de oude Vireo I en de nieuwe Vireo II. Ik wil in deze post weer even kort herhalen wat er nou aan de hand was met Vireo I en daarnaast ook nog wat extra informatie geven over waar je het nu kan vinden en wat ermee gaat gebeuren. De rest van deze post ga ik besteden aan Vireo II en hoe ik daar verder mee wil gaan.

Vireo I: in het kort
De eerste kernel, Vireo I, bestaat sinds 2015. Ik heb met die kernel leren programmeren, wat betekent dat er veel problemen mee zijn. Als je net begint met houtbewerken zal je eerste bijzet tafeltje ook niet de mooiste zijn. Dit principe zie je terug in Vireo I.

Een aantal problemen met Vireo I was dat er niet van tevoren gepland werd wat ik nou van de kernel wilde, of hoe het ging werken. Ik had ook geen documentatie geschreven voor mijn code, wat soms betekende dat ik niet meer goed wist hoe het werkte of wat het verwachte. Door al deze dingen was ik meer bezig met onderhoud van de kernel dan nieuwe dingen schrijven, en het is ook gewoon niet fijn om in een rommelige kernel te werken en dat je soms niet eens meer weet wat je zelf gemaakt hebt.

Vireo I: Hoe nu verder?
Vireo I is niet meer ondersteund en er zal niet meer actief aan gewerkt worden. De code en binaries zijn nog wel verkrijgbaar op GitHub, alleen ergens anders (master branch op GitHub is niet meer de default branch). Dit betekent verder niet zoveel. Zelf zou je het kunnen downloaden en aanpassen, kunnen verbeteren of er iets nieuws mee maken. Je kan het ook een keer uitproberen in een virtuele machine, ook al zal het niet zo heel erg interessant zijn.

Vireo I kon al best veel, alleen was er niet iets voor gebruikers zodat ze het konden gebruiken.

Vireo II: Wat is het?
Vireo II is een verbeterde versie van Vireo I, die zal bestaan uit (op)nieuw gechreven code en ge-re- of ge-upcyclede code. Er zijn ook wat verbeteringen op de achtergrond die het voor mij makkelijker maken om het te maken.

Vireo II: Status update
Vireo II kan ook gevonden worden op GitHub: m44rtn/vireo-kernel. Er is voor Vireo II documentatie: de vireo_kernel_refman.html (Engels), de refman tot nu toe kan je vinden op GitHub. In de bijlage kan je ook de refman vinden tot nu toe. De kernel kan weer simpele text mode dingen op het scherm doen, met een resolutie van 80x25x2. Die resolutie is standaard en wordt geinitialiseerd door de BIOS. Met text mode kan je alleen maar tekst laten zien. Afbeelding:



Vireo II stopt ook met de versie nummers die Vireo I gebruikte (zoals de release.major.minor.build en major.minor.build nummers). In plaats daarvan zal er alleen een build nummer zijn bij Vireo II.


Vireo II: Hoe nu verder?
Ik ga me bezig houden met alles wat in Vireo I zat weer in Vireo II te proppen. Ik kan me voorstellen dat dit saai is, aangezien jullie het al een keer gezien hebben. Daarom zal ik gedurende die tijd minder updates plaatsen, en misschien af en toe een keertje een progress report. Wanneer alles er weer in zit, ga ik kijken hoe ik de updates verder ga brengen (of dat weer eens per maand is, op de 23ste, of op een andere manier zoals met elke nieuwe interessante toevoeging). Misschien hebben jullie hier ideeen over?


Als er vragen zijn beantwoord ik ze graag, als er feedback is hoor ik het graag. Dit topic heeft niet voor niets de discussie prefix. ;)
 

m44rtn

Gevestigd lid
Bij Vireo II gaat het velen malen sneller, ik kan nu met memory management aan de gang terwijl het in Vireo I iets van 2 a 3 jaar duurde totdat ik daarmee aan de gang kon.

Ik denk dat dit komt omdat ik toen nog niet zo goed kon programmeren, maar ook niet goed wist wat ik deed. Ik denk ook dat het helpt dat Vireo II iets meer geplant wordt. Maar met Vireo I had ik ook mijn tijd verknalt met een shell proberen te maken. Hier een screenshot van de huidige kernel:



En hier van de 'done' lijst in Trello:


En... Zoals je misschien al gezien dat CPUID weer terug is! Diegenen die het topic 'Het besturingssysteem genaamd BirdOS' wel eens gelezen hebben, weten misschien nog wel dat deze in Vireo I aanwezig was (met enkel de vendor naam), maar op een gegeven moment niet meer werkte.

Vireo II kan nu ook de naam van de processor zien, zoals hier Ryzen 5.
 

m44rtn

Gevestigd lid
De kernel kan nu ook de bootloader detecteren. Tenminste, op het huidige moment alleen 'multiboot compliant' bootloaders. Dat zijn bootloaders die voldoen aan de multiboot specificatie gemaakt door GNU.


 

maulem

Gevestigd lid
Ik vroeg me een ding af. Het is toch zo, dat de bootloader de kernel laadt? Waarom zou de kernel dan nog eens de bootloader detecteren? Of is het gefaseerd, zo dat de bootloader de kernel laadt en dat de kernel dat nog moet bevestigen, zo van: hey, daar is de bootloader - hallo, ik ben de kernel.
 

m44rtn

Gevestigd lid
Sommige bootloaders, voordat ze de kernel laden, verzamelen informatie over het systeem. Hieronder valt hoeveel geheugen het systeem heeft, en nog een aantal andere nuttige dingen. Dit doen niet alle bootloaders, maar sommige wel. Omdat elke bootloader dat weer anders doet, kan de manier waarop ze deze informatie geven anders zijn. Door de bootloader te detecteren kan je ervoor zorgen dat je deze informatie goed leest, waardoor je de juiste informatie hebt.

Het is zo dat de kernel zelf ook de hoeveelheid ram kan bepalen, maar dit kost extra tijd. Zelf vind ik dat een kernel zo snel mogelijk moet zijn, dus als ik kan voorkomen dat de kernel het zelf moet detecteren, dan heb ik dat liever. Het controleren van de bootloader is namelijk velen malen sneller dan het bepalen van de hoeveelheid geheugen.

Wanneer we een bootloader detecteren die de informatie niet geeft, moeten we het alsnog zelf doen. Maar dan maakt het niet meer uit want dan is het nodig.
 

maulem

Gevestigd lid
Ik zat me af te vragen hoe de interactie met devices verloopt. Die hebben meestal een vast zgn. base-address, dat is gekoppeld aan een device (/dev/devicenaam) waarnaar je binnen de drivercode bytes kunt wegschrijven/lezen.

Wat ik me afvroeg is hoe interrupts interacteren met de driver. Voor zover ik weet zijn bepaalde geheugenadressen gekoppeld aan een interrupt nummer. Dus dan zou de driver moeten reageren op het optreden van een bepaald interrupt. Scant de driver daartoe dan een bepaald geheugenbereik om te weten te komen of het interrupt is opgetreden? En daarna kan de driver via het device de benodigde informatie lezen en wegschrijven?
 

m44rtn

Gevestigd lid
Hiervoor is het denk ik handig om eerst even een aantal dingen uit te leggen.

Die hebben meestal een vast zgn. base-address, dat is gekoppeld aan een device (/dev/devicenaam) waarnaar je binnen de drivercode bytes kunt wegschrijven/lezen.
Laten we hiermee beginnen. Dit base-address is een adres die de kernel zelf verzint voor dat apparaat. Dit werkt voor elke kernel weer anders (NT, Linux, etc).

Voor zover ik weet zijn bepaalde geheugenadressen gekoppeld aan een interrupt nummer.
Bepaalde geheugenadressen zijn gekoppeld aan een interrupt nummer. Dit gebeurt door middel van de Interrupt Descriptor Table (IDT), die je door moet geven aan de cpu voordat je iets met interrupts gaat doen. In de IDT is de index van de table de interrupt (dus bv interrupt 10 wordt opgeslagen op plek 10 in de IDT), met hieraan gekoppeld het adres van de Interrupt Service Routine (ISR). De ISR is de code die uitgevoerd wordt bij een interrupt.

Wanneer een interrupt plaats vindt, stopt de processor met het uitvoeren van zijn huidige taak. Wanneer dit gebeurd is, gaat de processor op zoek naar de ISR door deze in de IDT op te zoeken. Wanneer deze gevonden is, springt de processor naar die code waardoor het uitgevoerd wordt. Wanneer de ISR klaar is gaat de CPU weer door met waar het mee bezig was voor de interrupt. Dit gebeurt minstens honderden keren per seconde.

Ik hoop dat ik dat duidelijk genoeg heb uitgelegd.

(de driver hoeft dus niet zelf op zoek naar of er een interrupt geweest is)

Wat ik me afvroeg is hoe interrupts interacteren met de driver.
De oude Vireo (Vireo I), had hier niet echt iets voor. Vireo I was zo slecht gedesigned dat drivers niet los stonden van de kernel. Dit zorgde voor een soort IKEA kast die je niet meer in elkaar hoeft te zetten: het lukt je niet meer om het mee te nemen in je auto. Ofwel, het was gewoon onhandig en slecht.

Hoewel ik voor Vireo II er nog niet in detail over heb nagedacht, omdat ik nu nog niet zover ben, heb ik al wel enkele ideeën erover.

Er zijn meerdere manieren om dit te doen, sommige veiliger dan de andere. Zo kan je een driver zelf de toegang geven om zelf een ISR in de IDT te plaatsen, maar dit is niet veilig. Ten slotte, als een driver het kan, kan een virus dat ook. Nu kan je daar beveiligingen voor maken, maar dan ben je omslachtig bezig want het had vanaf het begin af aan al veilig kunnen zijn.

Wat mij het handigst lijkt is om een lijst bij te houden van de geladen drivers en wanneer een interrupt gebeurd, de benodigde informatie te verzamelen. Dan kan je in de lijst de juiste driver opzoeken en het alleen de benodigde informatie geven. Dit is veiliger dan dat ze zelf code mogen maken voor de ISR.

Nu zitten hier nog wat beveiliging dingetjes achter die nog niet helemaal uitgewerkt zijn, maar daar mag je zelf dingen over vragen. :)


Eigenlijk, zorg je ervoor dat je als kernel een dictatuur speelt. De kernel zegt wie wat mag en wanneer, hierdoor zorg je dat alles zo veilig en juist mogelijk gebeurd. De kernel laat dus niet de driver zelf zoeken naar hun informatie of dat er een interrupt is geweest; in plaats daarvan mag de driver lekker wachten. Wanneer er iets gebeurd is, zegt de kernel wel tegen de driver 'hey hallo, word eens wakker! Er was een interrupt: hier heb je alle informatie die je nodig hebt.'

Hoe de informatie gegeven wordt, heb ik nog niet echt over nagedacht. Dit kan inderdaad door ze toegang te geven tot een klein stukje geheugen waar je alles in dropt. Wat ook kan is dat je een bepaalde structure (mag je zien als een formulier met alle nodige informatie) maakt, en dan het adres daarvan aan de driver geeft.
 

m44rtn

Gevestigd lid
De website is vanaf vandaag niet meer te zien. De HTML/CSS is nog te zien op m44rtn/feathercode.github.io, en zal daar blijven bestaan als een 'archived' repository.

De releases van Vireo zullen gaan via Github Releases, die te vinden zijn bij elke repository bij de releases tab. Vireo is te vinden op m44rtn/vireo-kernel.



Ik vond de website te overdreven, hoewel ik er wel veel van geleerd heb. In de afgelopen 2 tot 3 jaar is de website veel veranderd, maar nooit was ik er volledig tevreden mee. Ik was een paar maanden terug al begonnen met oudere websites van 'FeatherCode' of mij weg te halen, en sinds twee maanden terug stond feathercode.github.io nergens meer beschreven buiten posts van fora (die ik niet meer kon veranderen) om.

De website was ook een tijdelijke plaats om informatie te vinden over de Night Kernel, die een steeds grotere community krijgt. Ik ben samen met de andere leden van dat project bezig een oplossing te vinden voor dat probleem.
 

m44rtn

Gevestigd lid
de helft van memory allocation is klaar, malloc werkt (ofwel geheugen toeschrijven). maar ik moet nog beginnen aan demalloc.
 

m44rtn

Gevestigd lid
Demalloc werkt inmiddels. Ik ben ook begonnen aan paging, wat ik in de vorige kernel niet aan de praat kon krijgen. Nu werkt het wel. Het is nog niet klaar, maar de basis is er.

Paging zorgt voor veiligheid en dat je makkelijker meer RAM kan gebruiken doordat je bijvoorbeeld delen uit het RAM naar de hardeschijf kan schrijven en dus ruimte kan maken voor andere dingen zonder dat je het kwijt bent.

Vireo II wordt beter dan Vireo I ooit geweest is. :)

 

m44rtn

Gevestigd lid
Okay, paging is nu echt zo'n beetje klaar (behalve een aantal kleinere dingen die voor later zijn). Hier is kort uitgelegd wat paging is... (Voor context, waar ik over praat in dit bericht is memory (RAM) en niet je hardeschijf.)

Kort gezegd, paging is een systeem dat ervoor zorgt dat een programma (of proces) alleen een bepaald 'hokje' van 4096 bytes kan zien en daarbinnen dingen kan doen. Bij Vireo I kon ik paging niet aan de praat krijgen. Vireo I was daardoor veel minder veilig omdat elk proces (afgezien van het feit dat er nog geen echte processen op konden draaien) overal bij kon en alles kon overschrijven. Bij Vireo II kan dit niet meer, omdat paging ervoor zorgt dat een proces alleen binnen zijn eigen vakje kan schrijven. Maar het maakt ook een aantal andere dingen net iets makkelijker.

Paging bestaat uit een page directory van 1024 entries (elk 4 bytes). Elke entry binnen die page directory wijst naar een page table die ook 1024 entries heeft. Elke entry binnen een page table wijst naar een fysiek adres dat bij een bepaald virtueel adres hoort. Als je alle entries gebruikt kan je 4 GiB aan geheugen pagen, het volledige verhaal (de page directory en alle 1024 page tables) kost je dan zo'n 4 MiB als je niet oplet (4 * 1024 * 1024 bytes). Maar niet elk systeem heeft 4 GiB RAM, dus het liefst heb je dat je alleen ruimte bewaart voor zoveel page tables als je daadwerkelijk nodig hebt. En ra ra wat de Vireo II doet...

De kernel bepaald eerst hoeveel page tables er nodig zijn en reserveerd ruimte voor ze. en voila.

Op een systeem met 12 MB kost deze techniek je 16 KiB, in plaats van de 4 MiB die het anders had opgenomen. Dat bespaart je dus (grofweg gerekend) zo'n 3,9 MB. Dat is bijna 1/3 van je gehele geheugen dat je bespaart!
 

m44rtn

Gevestigd lid
PCI werkt nu ook. Het werkt op de code van Vireo I, dat nog goed was. Voor zover ik heb kunnen testen werkt dit goed. Dat betekent dat we nadat het allemaal mooi netjes werkt aan drive support kunnen gaan werken. Hier moeten nog wel wat functies toegevoegd worden, maar da's niet zoveel werk.

Dit is build 445.

 

Nieuwste berichten

Bovenaan Onderaan