• De afgelopen dagen zijn er meerdere fora waarop bestaande accounts worden overgenomen door spammers. De gebruikersnamen en wachtwoorden zijn via een hack of een lek via andere sites buitgemaakt. Via have i been pwned? kan je controleren of jouw gegeven ook zijn buitgemaakt. Wijzig bij twijfel jouw wachtwoord of schakel de twee-staps-verificatie in.

Vireo II

  • Onderwerp starter Verwijderd lid 166773
  • Startdatum
Status
Niet open voor verdere reacties.
V

Verwijderd lid 166773

Gast
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:

6a01b045c8200b7b04d5fe43f6e68af9.png


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

021fe681e627996e3f25065d31416950.png


En hier van de 'done' lijst in Trello:
5faac56094736df45a981502da315174.png


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


90899c123eab29e8c1a62303c3e47293.png
 
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.
 
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.
 
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?
 
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.
 
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.

86baf7ca8038753dc29648699f6750fc.png


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.
 
de helft van memory allocation is klaar, malloc werkt (ofwel geheugen toeschrijven). maar ik moet nog beginnen aan demalloc.
 
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. :)

d974a4ea392498d9e4cafa99c3fca2b0.png
 
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!
 
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.

a2a9ff2bdf79f6838937f56e234f631c.png
 
Build 617! Deze build kan interne meegebouwde drivers vinden. De driver die het vind zelf doet nog vrij weinig (lees: niks). Hoewel functies van een driver wel uitgevoerd kunnen worden, heeft de kernel nog niet echt een systeem die dit handig regelt (waardoor in deze build drivers praktisch gezien niet uitgevoerd kunnen worden).

VirtualBox_BirdOS_06_01_2020_22_34_31.png

Voor zij die details interessant vinden... De kernel onthoud intern PCI apparaten anders dan hij laat zien op het scherm. Terwijl Vireo op het scherm bijvoorbeeld "7111:8086" laat zien (Device en Vendor ID), onthoud Vireo intern het apparaat aan de plek waar het is 'aangesloten' in de machine samen met het generale type (ook wel class genoemd).

Apparaat 7111:8086 is een IDE Controller, die in dit geval is aangesloten op plek 00:00:01 (dit komt neer op het tweede apparaat in de hele PC/Machine). IDE Controllers hebben als class 'Mass Storage Controller', deze heeft als nummer 0x01. Hier kan je meer van deze nummers zien. De kernel zal het apparaat in dit geval dus intern onthouden als apparaat 00000101 (hexadecimaal - dit heeft een decimale waarde van 257).
 
In het kader van Vireo moet werken op echte (wat oudere hardware): Vireo II build 661 werkt op een Fujitsu-Siemens laptop uit ~1999 met een pentium 3 processor (hoeveelheid RAM weet ik niet). Hiervoor hoefde ik niks extra's te doen, dus dat is mooi.

IMG_20200119_143946.jpg
 
Oh, build 661! Haha, oeps... Ik dacht dat ik meer geschreven had. En toen waren we vier maanden verder...

Goed... Er is best veel veranderd in de laatste paar maanden, allereerst: Vireo is de honderdtallen uit! De huidige build (terwijl ik dit schrijf, zal over een uurtje wel weer veranderd zijn) is build 1553.

2850f2a8bdf6970143ab9013b887591a.png


Hardeschijven kunnen gelezen en geschreven worden
Het belangrijkste in deze build is het kunnen lezen en schrijven van en naar IDE hardeschijven. Dit werkt in virtualbox en op de laptop die in post #15 is genoemd. Deze hebben beide dezelfde controller, namelijk de 0x80867111. Dit is een PIIX4 IDE controller van Intel. De build is ook getest met controller 0x8086269E, dit is een ICH6 controller van Intel. PIIX en ICH zijn twee verschillende chipsets op moederborden.

In principe zou Vireo nu van alle IDE apparaten kunnen lezen. Wel is er een probleem tussen Vireo en een van mijn testcomputers. Maar het is onduidelijk waar het probleem aan ligt. Vireo negeert deze controller nu en gaat gewoon door zonder IDE.

Een groot verschil met Vireo I is dat je dubbel zoveel hardeschijven kan hebben. In Vireo II kan je maximaal 4 IDE hardeschijven hebben, terwijl je in Vireo I er maar twee kon hebben.

Vireo kan partities op de hardeschijf identificeren
Vireo leest wanneer het opstart de MBR. Dit is altijd de eerste sector (ofwel de eerste 512 bytes) van een hardeschijf. Op deze plek staan een aantal dingen, waaronder welke partities bestaan. Zoals in de screenshot te zien is: Vireo detecteert dat er op hardeschijf 0 ('HD0') een enkele partitie staat. Vireo detecteert dat deze begint bij sector 63 (63*512 bytes), dat het een opstartpartitie is (systeempartitie, dit zou C: zijn op Windows), 4193217 sectors bevat (de grootte is dus 4193217*512 bytes) en dat het type 0x0B is (ofwel, bestandsysteem is FAT32).

Dit is iets wat Vireo I nooit heeft gekund.

Vireo is stabieler geworden
Hier valt niet zoveel over te vertellen zonder in details te treden. Dit moet je maar van me aannemen. :)

What's next
FAT32, that's next. Wanneer dat klaar is wil ik gaan beginnen met programma's kunnen opstarten en runnen zodat het bruikbaar kan worden. Wat daarnaa komt is een beetje aankijken.
 
Leuk om na zo'n lange tijd weer eens een update over het project te lezen. Gaaf dat je dit allemaal tegenkomt. De werking ervan kan je op die manier heel goed begrijpen.
 
Ik dacht omdat ik nu op de build zit met hetzelfde nummer als het jaar waarin we leven, hier een afbeelding van huidige Vireo:

654a660be9919853be85a5859d5d7f8d.png



Featuring: het kunnen lezen van een FAT32 bestandssysteem. De code moet nog opgeruimd worden en er moet voor gezorgd worden dat het allemaal dynamisch is (en niet allemaal test waardes enzo, zoals ik nu doe). Maar... de basis is er. Hoe lang het duurt voordat FAT32 read support (en write) klaar is, kan ik niet zeggen. Ik hoop snel.

Uitleg afbeelding: bovenaan ('table:' tot 'buffer:') is informatie dat ik gebruik voor het testen, dit zijn verschillende dingen. Van geheugenadressen tot nummertjes van bepaalde dingen. Daaronder ('.' tot 'VERSION FDI') is een directory, ofwel mapje, op de hardeschijf. De directory in kwestie is 'FDOS', de map waar FreeDOS geinstalleerd wordt. Voor het testen gebruik ik namelijk een virtuele machine waar ik FreeDOS in geinstalleerd heb.
 
't is een poosje terug dat er weer een updatje is geweest. Da's jammer, zeker omdat ik weet dat een aantal van jullie geintereseerd zijn in het eind product.

Ik heb een TIJDELIJKE pauze genomen. Dit is niet omdat ik met Vireo gestopt ben, maar ik was tijdelijk begonnen aan het helpen bij een ander project (de Night Kernel). Ik had een soort van beloofd dat ik ze zou helpen en heb dat eigenlijk nooit echt gedaan. 😅

Wanneer ik dat af heb, kan ik weer verder met Vireo.
 
Ik ben nu bezig met FAT32, waarvan het lezen van bestanden werkt. Voordat ik de volgende update schrijf wil ik in ieder geval het kunnen schrijven van bestanden ook (in ieder geval een soort van) werkend krijgen.

Sneak peek:

1a36769cabceaf1b371b950d3d9eb67d.png



De rare tekens tussendoor die horen daar, aangezien ik nog geen file encodings ondersteun (denk aan UTF-8)
 
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan