Discussie Vireo II

maarten70

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. ;)
 

maarten70

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.
 

maarten70

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.
 

maarten70

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?
 

maarten70

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.
 

maarten70

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.
 
Bovenaan Onderaan