En août 2020, j’ai entrepris de marcher le long de la Haute Route Pyrénéenne (HRP), depuis Cauterets en direction de Banyuls-sur-Mer, la Méditerranée. J’ai documenté le voyage au jour le jour, dont le résumé est fait ici.

Avant le covid, le plan était de randonner le Kungsleden en Suède ; plan tombé à l’eau au profit d’une alternative locale, plus technique et finalement plus ambitieuse. C’était ma première randonnée en solo, et de loin la plus longue, et j’en garde des souvenirs géniaux - ce moi d’août était facilement le meilleur de 2020 pour moi. Pas un seul réveil difficile, pas une seule journée ordinaire. Jour après jour, j’ai pris note de mes journées, ce qui a donné le post ici présent.

La liste de mon équipement est disponible sur lighterpack. En terme de préparation, j’avais mon expérience passée, des traces GPX, et le guide de Tom Martens^{[1]the man can write, believe it} au format ebook.

Journal

Day 1: Cauterets to Oulettes de Gaube

Bivouac au pied du Vignemale, face Nord. Pas de difficultés ce matin à la descente du train, ni logistiques ni autres. De Cauterets, le chemin longe une rivière à l’ombre, nombreuses cascades. Cagnard l’après-midi lors de l’ascension vers le refuge de la Oulette de Gaube. Je croise à ce refuge un gars ayant l’air ultralight, à son sac et à sa sawyer mini^{[2]j’apprends qu’elles peuvent se visser sur les bouteilles de Perrier !}. K, parti de Hendaye le 6 juin. Rennais ! Il attendait sa trail family. M, prof de philo, D, vieux à qui j’ai peu parlé (il vient de perdre son portable: coup dur)^{[3]quelqu’un l’a trouvé, il l’a récupéré à Bagnères de Luchon !}, V et P.

Ils tentent le Petit Vignemale demain matin, je m’engage à les suivre, sans promesse sur le reste de la journée: l’étape d’aujourd’hui leur a semblé facile, reposante, alors qu’elle m’a tué. J’avais pour plan de bivouaquer n’importe où avant Gavarnie, faire mes courses le lendemain matin, et potentiellement suivre la HRP. Je crois maintenant que c’est ce que je vais faire. Marcher seul et sans contraintes m’attire plus pour l’instant. Quitte à retrouver ce groupe plus tard. Ces gens sont tellement chill, j’aurais aimé pouvoir discuter correctement avec eux. Ils sont tous plus agés que moi, ont un job, se connaissent depuis quelques semaines ; ils ont leurs codes. Un orage éclate à quelques kilomètres. La pluie s’intensifie.

Day 2: Oulettes de Gaubes to Gavarnie

Gros orage hier soir qui a secoué la tente déjà mal pitchée. It held. La tente de V&P a eu moins de chance, un anneau de cassé^{[4]je les reverrai le lendemain, puis plus}. Ce matin, les grégaires du GR n’étaient plus deter à faire le Petit Vignemale, à cause du vent, entre autres. Je les quitte, gravis la Hourquette d’Ossoue puis le Petit Vignemale. 3 km de haut ! À la descente je retrouve les gens à Baysellance, je n’y reste pas. Ils me rattrapent vite. Premier river crossing pieds trempés. Au barrage d’Ossoue, pause de quelques heures pour moi. Le groupe repart direction Gavarnie, moi je vise le refuge d’avant. La fin de journée est superbe: personne ou presque sur le GR. Au moment de poser ma tente au refuge de la Grange de Holle, M débarque, puis les autres: ils n’ont pas trouvé de place au camping de Gavarnie. Je suis décidé à prendre la HRP le lendemain.

Day 3: Gavarnie to Héas

Extra solide journée, que j’avais pensé courte. Ascension épuisante à la Hourquette d’Alans le matin, après avoir fait des courses à Gavarnie, village au final sympathique. Acheté une serviette et de la bouffe: erreur, oublié le fromage, et la florette passe mal. Après-midi dans le cirque d’Estaube, chaleur écrasante. J’y ai vu une marmotte en mangeant, et un curieux animal que j’aurais dit félin^{[5]sûrement une autre marmotte}.

Lessive avant le lac des Gloriettes, destination de picnic prisée. J’opte pour contourner le lac par le Sud, évitant le bitume pris par la HRP, direction cabane des Groutes. J’apprends alors ce qu’IGN appelle “autre chemin”, et que celui-ci remonte à 2000m… Glorieuse solitude avec magnifique vue. Descente raide à Héas où je pose ma tente au camping attenant à l’auberge de la Munia, les Cairns. Ambiance Comme un Avion, et surtout, une douche ! Boutons aux épaules, je change de haut. Tant pis pour mes bras, je mettrais de la crème solaire^{[6]pas de manches sur celui-ci :/}. Demain objectif Lacs de Barroude, et le lendemain, Parzán.

Day 4: Héas to Lacs de Barroude

Seulement la moitié d’une étape selon Cicerone, effectivement j’arrive tôt. C’est une très bonne chose, les lacs de Barroude sont mon idée du paradis sur Terre. Le mur de Barroude surplombe deux lacs issus d’un glacier. La vallée est verdoyante et accidentée. Des centaines de moutons. Le plus grand des deux lacs possède quelques îlots et deux presqu’îles. À mon arrivée, j’aperçois un randonneur chillant sur la première presqu’île, sorte de volcan miniature. Je m’installe sur la suivante. Baignade, juste une minute, l’eau est fraîche. Je me suis écorché l’orteil gauche :/ Fissuré ? J’ai ici un gros cal douloureux depuis un moment. En venant ici, la Hourquette d’Héas était à couper le souffle. Un trou de deux mètres dans la roche sépare deux vallées, avec un souffle extraordinaire. Comme si tout le vent d’une vallée passait là pour rejoindre l’autre. Le dénivelé ne m’a pas posé de soucis aujourd’hui. Habitude ? Demain, Parzán, journée très facile si mon orteil coopère.

Vraiment pas satisfait de mon système de bouffe. Selon mes estimations, j’ai mangé 1614 kcal aujourd’hui… Avec fromage ça aurait été 2000 kcal, toujours pas ouf.

Day 5: Barroude to Parzán

Passage en Espagne au Port de Barroude ce matin ! Des vieux m’indiquaient des isards sur mon chemin mais nulle trace. Bain près de la grande route - la chaleur me tue. Courses ratées à Parzán: 3600 kcal pour trois jours → j’allais mourrir de faim. Demain je pars à Bielsa chercher un distributeur de billets, plus de bouffe, de quoi me sustenir et payer le repas d’auberge à Viados ou Soula. La montée depuis Parzán a été rude, entre la chaleur, le manque d’eau et l’incertitude sur la proximité d’un spot campable, que je finis par trouver près d’une cascade^{[7]bouchons d’oreil recommandés}. À Parzán, j’ai acheté des limes, qui viennent à bout de mon problème d’orteil.

Parler espagnol me fait perdre 50 points de QI.

Day 6: Parzán to Añes Cruces

Impossible de rejoindre Bielsa: le stop ne marche pas. Provisions++ à Parzán (oréos !) et je remonte cette satané pente. Un vieux me demande un indice: ai-je vu sa femme^{[8] non ! j’ai pas eu le fin mot de l’histoire} ? Le camping près du refuge de Viados est fermé^{[9]et pas moyen de camper au refuge: il est en dessous de 2000m}… Peu importe, j’avais placé cette journée sous le signe de la sueur et de la fatigue. Je push jusqu’à la cabane d’Añes Cruces, dépassant quatre espagnols que je retrouverai là bas. Devant la cabane, des Allemands m’indiquent la présence d’un français à l’intérieur. Un HRPiste UL ! On discute de gear, de plans, du terrain^{[10]”s’il fallait démonter sa tente chaque fois que y’a de l’orage, on aurait pas fini” - une philosophie que j’apprécie vraiment}. Il tente de la faire en 3 semaines mais me dis prendre du retard. 6h30 tous les jours → midi sieste. Beaucoup d’expérience et de détermination, c’est impressionnant. Après une nuit passée près d’une souris dans le mur, à mal dormir sur le sol de la cabane, il me dit s’appeler T, T d’un certain forum de randonnée :)

Day 7: Añes Cruces to Loudenvielle

La route vers le refuge de la Soula en France est magnifique. Je monte au port d’Aigües Tortes par des “sentiers” rocailleux, géniaux. En haut, un désert de scree impressionnant, des grands oiseaux, et une source formant une large mare. La Soula me rappelle S.T.A.L.K.E.R, le refuge est au beau milieu d’une station hydroélectrique. La suite, la partie amazonie d’Océanopolis. On voyait le nuage par dessus depuis la frontière^{[11]il faisait si beau côté espagnol}, je serai encore dedans le lendemain. Dans la forêt descendant à Port de Prats, je croise un groupe de 7 ou 8 marcheurs, qui me trollent (“pas droit de couper”) d’abord, puis qui valident mon plan camping. Cool guys. Je prends une bonne heure d’avance dans la descente et fait la moitié du chemin jusque Loudenvielle avant qu’ils me rattrapent et m’y déposent, m’indiquant le distributeur de billets.

Je rejoins le camping, a priori complet, où à l’accueil, K vient de prendre la dernière place, qu’il me propose de partager. Il l’avait déniché en appelant l’office du tourisme ! Incroyable type, incroyable chance pour moi. Douche, puis bonne discussion avec K. Après cette randonnée, il veut sortir de la société, vivre en nomade ; a été réalisateur, solide cinéphile. Quelqu’un de très très cool. Malchance, il renverse de la superglue sur ses lunettes ce qui le force à faire du stop jusqu’à Bagnères - “À quoi bon marcher ici si on n’y voit rien”. On échange nos numéros pour s’y retrouver.

Day 8: Loudenvielle to Lacs d’Espingo

Je ne repars du camping qu’à 11h, il pleuvait avant. Re-douche. Je croise D, passe le col d’Esquierry puis monte au lac d’Oô, montée interminable et surpeuplée. Lac qui me paraît surcoté, amoindri par sa popularité et le barrage qui s’y construit. On m’indique “eau pas potable” au refuge, et plus haut je trempe ma chaussure en en refaisant. Vers 20h j’approche d’Espingo, et un gars me rattrape. Il s’appelle J, est Australien, vit en France, est chercheur en machine learning et visite les lacs d’Espingo plus ou moins sur un coup de tête. Wow ! Chillax, on trouve un campsite au bord du second lac, derniers arrivés parmis une douzaine de campeurs. La brume couvre tout au dessus de nous, c’est magnifique. Il acheté sa tente pour l’occasion, est en jeans et baskets, mange dans une assiette^{[12]respect, il allait plus vite que moi}, ça change du monde que je croise habituellement. Je filtre, mange puis produit du Lindt: malade, je l’avais senti venir à Oô. J est allé méditer plus loin. Le matin, condensation à bloc.

Day 9: Lacs d’Espingo to Bagnères de Luchon

Grand froid le matin. Couplé à la condensation, je ne sens plus mes mains après avoir rangé ma tente. Au revoir à J et je pars. Peu d’eau avant je ne sais quel col où je sèche ma tente. Après celui-ci, autoroute vers Bagnères. À Superbagnères, station de ski, je traverse un troupeau de vaches. Une femme a la même idée en sens inverse et se fait frapper des cornes d’une mère^{[13]première fois que je vois ça; rien de grave}. J’indique le GR à un père et son fils, perdus. Je me sens comme porteur de l’idéal randonnesque. À Bagnères, glace, ice tea, courses, et je croise K. On boit un godet. Il a réparé ses lunettes et prend un zéro demain. Ne me suivra pas sur la HRP: mal au genou, et donc peu rassuré par la mention “very steep descent”, E grade du guide. Une fois de plus, on se quitte. Au camping, the usual. Beaucoup de route demain avant même de commencer l’étape. Hope for the best.

Day 10: Bagnères to Col de Mulleres

Journée écrasante, physiquement mais aussi moralement. Plus de chemin pour rejoindre la HRP qu’anticipé, pas aidé par mon manque d’expérience en stop. Passé le refuge de Benasque, j’arrive à la Besurta vers 15h, début de l’étape. Ici, un monde fou, venu en bus, qui passe toutes les demi-heures. Chaleur. Passé le trou du Toro et le plateau d’Aigualluts, les touristes sont remplacés par des vaches. L’ascension devient technique, grisante. il est 17h+, je perds un peu mon sang-froid. Pas raisonnable de passer le col à cette heure-ci, d’ailleurs quand l’atteindrai-je ? Camper si tôt quand mes jambes fonctionnent et que l’ascension est si belle ? Je grimpe, repérant les lieux de bivouac possibles. Finalement, je décide que trop c’est trop, que Mulleres sera demain, et je fais demi-tour jusque près d’un étang de glacier, ~2450m. Je pitch ma tente avec des cailloux pour la première fois.

19h30, des espagnols passent ma tente, ils vont grimper le col. Je questionne mon choix de remettre l’ascension à demain, j’aurais finalement pu dormir en cabane. Mon corps me dit que j’ai bien fait. À moins d’un orage cette nuit, mais vu le grand ciel bleu, comment serait-ce posssible ?

20h+: en fait le sol sous ma tente est froid. Dehors, il fait encore chaud. J’ai pas l’expérience d’un espagnol, faut pas que je m’y compare. Maintenant je saurai.

Qu’est-ce que c’est beau. Seul, pas une vache, dans la vallée d’Escaleta. Demain matin sera glacial, et le soleil ne se lèvera pas sur ma tente avant 10h au moins, caché par je ne sais quelle barrière rocheuse adjacente au Tuc de Mulleres. Such is life. Pour l’instant, j’adore être ici. Je m’en veux un peu d’avoir laissé K. Je me promets de le rejoindre au moins une fois, lui payer un godet.

Day 11: Mulleres to Lac deth Cap deth Port

Montée au col longue. Ce que je prends d’abord pour le col est en fait de l’autre côté du Tuc, que je monte - 3010m. Un alpiniste du coin partage son expérience, il connaît tous les sommets à la ronde. Le guide disait du col “extremely steep descent”: very true. La suite est un chaos de pierres infini et une demie forêt jusqu’à Espitau de Vielha où je fais une courte sieste. Je décide de suivre le GR11 jusqu’au refuge de la Restanca, gagnant 3 heures, mais manquant Lac de Mar que le guide assurait des plus beaux. Tant pis. Par SMS, K me dit qu’il va arrêter son chemin à Bagnères, son mal de genou ne passant pas - coup dur.

Je commence cette étape suivante à 16h. Soleil. Forêt escarpée. Marche facile à l’ombre à partir de 18h+. Arrivé 21h20 j’atteins la Restanca où je suis content de ne pas rester: que des français en grands groupes types dayhikers. Je pousse jusqu’au lac indiqué campable par le guide. Mon arrivée dérange un groupe de quatre ou cinq isards. Leur position me révèle un bon spot de camping, solide nuit.

Day 12: Restanca to Salardú

Beaucoup de touristes autour du refuge de la Restanca, les chemins sont loins d’être calmes. Picnic dans un coin sympa, m’étant trompé de chemin, suivant bêtement ma trace GPX. Deux dames (allemandes ?) m’interpellent, reconnaissant un fellow HRPiste. Elle vont également se ravitailler. On discute, je les dépasse. Ma chaussure droite a un problème: un bout de semelle se décolle. Trois bouts de duct tape tiennent jusqu’à Salardú, où, surprise, il n’y a pas de superglue. Je loge au refuge Juli Soler. La patronne a fait la HRP, parle un bon français. Seul dans une chambre pour quatre, covid oblige. Repas extra complet. Je dors mal though: chaleur, et problème de se rendre à Vielha le lendemain, mission superglue.

Day 13: Salardú to Airoto

Je manque le bus → stop to Vielha. J’attends 9h que le supermarché ouvre → no superglue, je cherche le Casino indiqué, galère et trouve. À 10h, je prends le bus pour Salardú. 10h35, ma chaussure est réparée, on the road again. J’oublie près d’un banc mon buff, il me manque déjà. Passés les premiers Estanys de Baciver surpeuplés, je mange aux Rosaris près des chevaux, regardant ma future montagne, le Tuc de Marimanha. Approche quasi frontale d’une pente raide, ça marche. En haut, je m’aperçois que le tonnerre continue de gronder à l’Ouest, j’accélère. Le col d’Airoto requiert un peu d’escalade inversée, et j’y fait ma première chute: RAS. La section “giant boulders” ne déçoit pas. J’ai trop poussé la descente, je remonte une pente à 80% sur 100m jusqu’au prochain col: je skip le refuge dont j’entends venir des éclats de voix depuis une heure. Je trouve à camper dans la descente du col, avant l’endroit indiqué dans le guide, un tarn plus bas. J’ai peu d’eau mais je suis claqué.

Day 14: Airoto to Alós d’Isil++

Dans la decente, je fais un combat de regard avec un isard. Je fais mon eau/lessive/dej au petit lac plus bas. Sur l’autre rive, quelqu’un y fait également ses affaires. En repartant, je le salue, lui demande s’il fait la HRP - “Oui, c’est la HRP”. Il est Belge, parle français. “Quel guide utilises-tu ?” “Cicerone, en anglais” “C’est moi qui l’ait écrit !” C’est Tom Martens, mon guide en personne ! Il ressemble à mon prof de maths de spé. Passionné et passionnant, me questionne sur mon chemin, mon ravitaillement, mon séjour au refuge de Salardú… Il grimpe les 3K des Pyrénées, écrit un guide sur leur ascension. N’imagine pas un été sans grimper les Pyrénées. Me montre une nouvelle route vers Alós d’Isil trouvée la veille. Me donne sa carte, on se salue. Pas pensé assez tôt à la photo, regrets là dessus. Ma journée est faite dans tous les cas.

Je trouve facilement cette nouvelle route, qui longe un ruisseau, et j’atteins Alós à midi. Joli et vieux village ressemblant à Méranges. En repartant, je discute avec un genre de teneur de mini-expo historique et lui donne ma carte devenue inutile du Val d’Aran, au cas où il croise quelqu’un allant dans l’autre sens. Il me prévient d’un orage pour le soir. En mangeant près de la Noguera, je l’entends déjà, et peu après je sors le kway. Vers 15h peut-être c’est le déluge et la grêle. Je marche dans le ruisseau ayant remplacé les chemins. Mon short est trempé également. Mode automatique. J’ai froids aux mains. J’atteins le petit lac à 2000m+ et plante ma tente. Je mets ce qu’il me reste de sec et m’enquiltifie, ce qui conduit à une sieste sous le restant d’orage. Je mange, trop tôt. Ressors faire de l’eau et laver mon short au passage, en caleçon. Je dors mal. Pas d’orage pourtant.

Day 15: Alós to Tavascan

Je rejoins un vieux HRPiste en montant le col. J’ai mis du temps à me lever: réveillé 8h45. Mes rêves, comme toutes les nuits j’ai l’impression, sont menaçants. Un L4D2 trop difficile, une rando HRP avec G&S&G où mes semelles se sont entièrement décollées… On parle un peu gear^{[14]il a un sac katabatic !}, je le dépasse.

L’estany major est grandiose, une mer intérieure avec houle: vent et pluie pendant 20 minutes. Je passe trois lacs et atteins Enric Pujol, où je me pose pour manger. S’y trouve un HRPiste sur le départ, sympa. En faisant une pause plus tard, un couple me dépasse. Fascinés par le bon état de mes chaussures. Lui a remplacé les siennes, elle va très prochainement devoir le faire. Ils sont partis de Cauterets le même jour que moi^{[15]comme beaucoup de français, ils suivent un autre guide que le mien: je ne les reverrai pas} ! J’atteins le camping de Bordes de Graus à Tavascan, un peu bruyant mais sympa.

Day 16: Tavascan to Certascan

Peu de choix à l’épicerie de Tavascan - joli village. Je prends des conserves pour la première fois, on verra. Reparti en stop, et rapidemment à Noarre. Trop rapidemment peut-être, maintenant que mon sac est très lourd: les tendons de ma cheville gauche/intérieur crissent. Pas mal de monde jusqu’à l’étang précédant le col de Certascan. Je souffre, j’ai vraiment peur que ça dure, ça mettrait fin à ma marche. Je renonce au pic à cause de ça, alors que Tom me l’avait décrit comme facile & worth it. En plus de ça, ma poche de filtrage d’eau s’est fissurée ; en attendant de trouver une bouteille de Perrier^{[16]K m’avait raconté avoir oublié la sienne le premier jour, crevé de soif, le premier groupe de vieux auquel il a demandé en avait une}, plaquer ma bouteille contre le filtre fonctionne tolérablement.

Descente du col, je croise un type, Jamie-looking, avec un gros sac mais ne faisant pas la HRP: il se balade avec un ami^{[17]j’ai envie de l’appeler Fred, malgré l’absence de ressemblance} qu’il dit berger, portant une semaine de bouffe. On discute philosophie de la marche. Vaut-il mieux aller loin et vite, ou pas loin en prenant tout son temps ? Dans tous les cas, j’ai fais un converti à l’ultralight - même sans aller loin, autant pas se casser le dos. Ils campent au troisième lac de Romedo. En arrivant au refuge de Certascan, il photographie une pleine lune^{[18]“des souvenirs pour la vie”}. Je m’y prends un sandwich. K avait raison, pas grand chose dedans. Un peu par erreur, j’ai campé au lac d’avant celui de Jamie & co - tout le coin est paradisiaque. Pour prendre leur noms et leurs ballistos^{[19]ces deux là avaient les meilleurs délires}, j’irai leur dire bonjour demain matin. Fasse Cauchy que ma jambe aille mieux alors.

Day 17: Certascan to Pla de Boet

Petite pluie et vent, très gros vent le matin. Je skip le salut à Fred & Jamie, pas le courage d’être dehors par ce temps sans avancer. D’abord coincé derrière un grand groupe de randonneurs à la semaine dans la descente des lacs de Romedo, je vais ensuite me perdre dans une vallée sans nom où se trouve le Riu de Guiló, au Nord Nord Est quand je devais aller plein Sud… Perdu une heure, une heure et demie dans un relatif mauvais temps. Ma jambe marche ! J’ai des relances, mais dans mes deux jambes alternativement. J’ai dû abuser de la droite en compensant, puis de la gauche… Une fois dans la bonne vallée, gigantesque descente sans croiser âme qui vive, magnifique, sauvage. J’entame mes boîtes. Au fond de la vallée, au pont de Boavi, quelques touristes, familles etc… Disparus en haut de la remontée majeure.

Là commence un orage. Je pousse un peu plus loin que nécessaire mais cette fois ma tente est plantée avant le gros de la tempête. Terrible pitch à 5 sardines. Grêle, vent qui lance ma tente entière dans toutes les directions. La sardine arrière droite paraît prête à lâcher mais tient bon contre tout bon sens. Je finis par sortir le quilt le vent calmé. Après 1h30 de pause, je décampe. Un isard s’enfuit près des lacs de Baborte. Il est tard mais je me sens de continuer. Grande descente avec pas mal de forêt jusque Pla de Boet. 1850m, en dessous de l’altitude légale de camping, pas pensé. Un couple d’espagnols y campe déjà, 21h. Ils devaient grimper le pic d’Estats aujourd’hui mais ont remis au lendemain à cause de la météo - good call. Ils m’aident à monter ma tente.

Day 18: Boet to Refuge de Sorteny, Andorre

Mal dormi, et condensation. Quelques tentes dans l’interminable montée vers Port de Boet, la frontière. Même dans la descente vers la Soucarrane je me sens assez faible. Pas plus mal au jambes que d’habitude, mais pas de puissance derrière. Grosse boîte de tortellinis pour compenser. Port de Rat, difficile alors que le chemin n’a rien d’exceptionnellement dur. Je me trompe d’ailleurs avant de commencer son ascension, je descends trop bas, de ~150m. Coup au moral qui m’aide pas non plus. Paracetamol en haut. Je descends jusqu’à la station de ski d’Arcalis en Andorre où je m’arrête profiter de la wifi, les plans de retrouvaille avec G&S se montent.

En repartant, 16h20, je me sens à 100% voire plus. Objectif Ordino, courses. Pas certain que le bus passe où je suis sur la G3^{[20]connaissant maintenant les marqueurs d’arrêts de bus, il serait passé ^^}, je rejoins El Serrat à grande vitesse. J’attrape de justesse le bus à 20 centimes et me retrouve à Ordino, courses satisfaisantes. Fort attrait pour les hamburgers à l’affiche des restos. Charmante ville qui paraît très moderne, en tout cas très bien modernisée. Reparti en bus to El Serrat, j’atteins le refuge de la Sorteny sans soucis. S’y trouvent des lits libres (gratuits et en métal) ! Je mange comme un ogre près d’un ruisseau et dors, tardivement, pas par faute d’essayer.

Day 19: Sorteny to Refuge de Juclar

“Route-finding is very easy in Andorra” disait Tom, mais je me perds dans la première demi-heure, n’ayant pas suivi à la lettre ses instructions. Tous les chemins sur OSM n’existent pas jusqu’au bout ! Faible encore, mais mieux. Un gars me dépasse portant un sac et un vélo. Il grimpe comme moi jusqu’au col del Meners. De là, un certain nombre de touristes, mais chills. Légère fausse route (équivalente), j’approche la cabane de Coms de Jan par l’autre côté. J’y retrouve les deux HRPistes croisées avant Salardú. Elles sont belges, s’appellent N & K’. On marche ensemble jusqu’à la cabana Sorda où elles s’arrêtent, 15h30.

Les voir m’a redonné la pêche. Après une pause, je repars pour Juclar. Dure marche de 2h30, j’attrape des coups de soleil et une cloque à l’orteil gauche, indolore. Dormir est payant à Juclar, je pensais y trouver des lits libres… Je suis short de 10€ mais la patronne m’offre nuit et souper quand même. Soupe, boeuf, riz, “there’s more if you want” - mon amour pour cette dame est infini.

Day 20: Juclar to L’Hospitalet-Près-l’Andorre

Jolis lacs passé le col d’Albe. Peu de gens par ici, deux trois petits groupes. Ceux là semblent du coin, plantent leurs tentes et pêchent pour certains. Ils ont de la montée à faire depuis L’Hospitalet pourtant. Du GR, du GR, du GR… Cette ville a un style très particulier. Un pipeline qui la traverse, du bitume noir entre les veilles maisons à moitié retapées. Camping peucher though. Les plans sont faits, G&S me rejoignent ici demain soir. Mon zéro day est arrivé !

Day 21: L’Hospitalet-Près-l’Andorre

Direction boulangerie pour le petit dej, espérant croiser les belges, N & K’, malgré l’heure tardive - 10h. Je me trouve un banc face à la mairie et au retour les croise sur la terrace du bar-épicerie. Elles étaient je crois là à l’aller mais je les avais pas reconnues. Elles repartent en Belgique en bus dans 20 minutes ! Finirons une prochaine fois. Elles s’attendaient à croiser au gîte un groupe de trois français, je dis que je leur passerai le bonjour à l’occasion^{[21]finalement jamais croisés; on ne suivait pas le même guide} et les quitte. Lessive, siestes, douche, le bus arrive, 19h. Here they are! Avec des gros sacs, bouffe en conserve. Camping. S a crevé son tapis de sol sans cause probable, réparé avec le kit du xtherm de G.

Day 22: L’Hospitalet-Près-l’Andorre to Étang des Fourrats

Chemin tranquille, Cauterets-sque jusqu’au refuge des Bésines où on s’arrête manger. Après-midi de belle montagne, pleine de lacs, quelques passages rocheux, et une forêt étrangement sparse d’épicéas avant les Fourrats. L’étang est juste devant le Carlit, magnifique. Tom déconnait pas. G discute avec des marmottes ; on sèche nos affaires. Plein de gens campent un peu plus bas que nous.

Day 23: Étang des Fourrats to Saillagouse

Carlit ! Suite à un pari sur ma frilosité jambière, je porte le short rose de S, et pour bien faire, son kway 80s-style. G, et particulièrement S, galèrent dans la montée. Elle est longue, et constante. Au sommet en 45 minutes, j’y trouve un vieux apparemment ici depuis un bon moment. Photos, on discute. Il est de Saint-Brieuc, dans l’association Le Chemin Sauvage qui cherche à créer un chemin en V sur toute la France, évitant les grandes villes. Saint-Brieuc, Carlit, Ardennes, le V. Après 15 minutes, le sommet se charge de monde. Photos de groupe dans les nuages, en tenue, et on redescent l’autre versant. Monde fou, et tout commence à m’agacer. Les gens, leurs chiens, leurs familles, la lenteur de G&S dont je ne réalise pas qu’ils sont crevés. L’atteinte des Bouillouses est misérable, sauf pour S me parlant de sa semaine mario.

Tout est mieux à l’étape qui suit et je retrouve une forme de civilité. Courses limitées à Bolquère, et mon parrain nous prend sur la route vers Eyne: escale chez de la famille à moi, A&G’ - ça fait longtemps que je veux retourner les voir, cette rando est l’occasion de faire d’une pierre deux coups. Repas de soupe, saucisson, salade, oeufs, superbe. Lérot.

Day 24: Saillagouse to Noufonts

Petit déjeuner parfait, pain beurre, confiture, miel, … Courses au marché puis à Spar, pour quatre jours. Rôti, glace à midi, c’est glorieux. Puis il est temps de partir, ~15h, G’ nous dépose à la reprise du chemin. Jolie remontée de la vallée d’Eyne. On suit Tom qui nous décrit les crêtes comme campables, et décidons de poursuivre là dessus. “Yer fond of me lucky charms!”. Coucher de soleil. On descend du col de Noufonts pour camper, bon terrain mais beaucoup de vent, dure nuit.

Day 25: Noufonts to Pla Guillem

De retour sur la crête, on continue vers le pic des Batiments. Tous un peu fatigués aujourd’hui, planté de tente tardif hier soir. Du chemin à faire pourtant, nos plans nous amènent chez de la famille à S d’ici quelques jours. Tom annonçait là “for experienced hikers, the route will be pure fun”, et l’homme ne survend rien: les chemins passent à ras des crètes et sont principalement un dédale de roche en vrac. Un bon monde en haut, et pour la suite de la journée. Pause déjeuner au refuge d’Ull de Ter, il fait sacrément chaud. Passé le port de Mourens qui nous ramène en France, on a droit à de la montagne arrondie, c’est une première.

On s’arrête manger à Rotja, conteneur en métal servant d’abri. Pas les premiers sur place, une dame y est installée ; elle randonne une boucle dans le coin. Il fait froid, on repart, marchant vite. Rattrapés par la nuit. On cherche la cabane de Pla Guillem à la lampe torche - ça nous évite la tente, le vent et les chiens de berger. Trouvée. C’est grand, vide, bien.

Day 26: Pla Guillem to Refuge des Cortalets

Départ compliqué le matin: faute de voir un chemin, navigation à vue qui nous fait couper un temps à travers brousse. S se fait mal à la cheville, on ralenti. On se dit qu’on passera la nuit en refuge, aux Cortalets. On passe les Mariailles, pause à l’ombre avant le Canigou. Chaleur d’un autre genre, on se croirait en Corse. L’escalade de la cheminée vers le sommet est incroyable, de la roche brute, explosée à la dynamite il y a plus de cent ans. Vue sur une mer de nuages. Aux Cortalets, pas de place, malgré nos tentatives de réservations. Repli sur leurs bières, brownies & chocolats.

Day 27: Cortalets to Céret

Grosse journée. Le plan, atteindre Arles-sur-Tech, où de la famille à S nous amènera en escale à Céret, G&S y resteront. Bloqués par des vaches, pause à la maison forestière de l’Estanyol. Le chemin est effectivement forestier, bien à l’ombre, il fait beau. Plus que de la descente jusqu’à Arles, 282 m d’altitude. On en fait même une partie en courant, G&S sont deter comme jamais. Première fois que je vois un chêne liège. Baignade en rivière, eau fraîche.

Arrivés à Arles par un labyrinthe de canaux puis finalement son cimetierre, on est accueillis par H&S’, qui nous amènent à Céret en twingo. Ces anges absolus nous payent le resto ; vengeance sur les Cortalets, également appréciée chaude. H, prof d’anglais, a fait le PCT. J’espère faire de même un de ces jours, je suis sûr maintenant que j’adorerais ça. Leur maison est d’un style monumental, en mode Sunset Boulevard, et ils ont un hamac d’appoint - how cool is that?

Day 28: Arles-sur-Tech to Las Illas

Petit dej, courses, repartir seul fait bizarre. J’en oublie de remercier H&S’, de retour à Arles. Je fais quelques arrangements de retour, tant que j’ai du réseau, puis grimpe. Même style de chemins qu’en arrivant, parfois comme des tobogans de roche. Une pêche d’enfer en première partie de journée. Oeufs durs à midi <3. Je croise mes premiers sangliers, puis deux beaux chevaux, dans une forêt de hêtres étrangement calme. J’ai mal à l’orteil gauche en marchant, ce que j’attribue à la baignade précédente, une glissade quelconque - pas de certitude.

J’atteins Montalba d’Amélie, une communauté perdue dans la montagne, dont je ne verrai que la fontaine. J’y discute avec un couple de GRdistes qui m’avaient dépassé pendant ma pause déjeuner, ils me demandent si le col plus loin se campe - “open spot on a ridge” dit Tom, je n’en sais pas plus^{[22]c’était finalement un superbe spot de bivouac}. “Je vise Las Illas ce soir”, “… Vous courrez ?”. Non, j’espère m’en passer, mais c’est un challenge ^^ Je grimpe le Roc de France par une voie tout à fait innovante^[23]absurde après m’être trompé de chemin. Première vue de la Méditerranée, de ma vie je crois. De là, descente jusque Las Illas avec un bref et presque final passage en Espagne. Tom recommendait un joli spot de gazon, j’y trouve deux GRdistes discutant de la fin du voyage. Triste pensée.

Day 29: Las Illas to La Tagnarède

Un vieux me donne une foultitude d’indices pour naviguer la route type suburbs en zigzags sortant de Las Illas, je ne réussi à en retenir aucun mais arrive tout de même au bon endroit: une route de terre, “surveillée par satellite” - alright. La route est longue, longue, sans distraction. Elle mène finalement au Perthus, par une forêt de chênes lièges. Il fait une chaleur assomante.

Il est midi à Le Perthus, je m’arrête dans ce que je prends pour un bistrot faisant des burgers à emporter ; c’est en fait un vrai restaurant. Que mieux. Un seau de limonade, une bouteille de mayo, que demande le peuple. Je repars après une petite pause sur un banc à examiner mon orteil: on m’a entendu crier dans la montagne à plus d’une occasion, en butant sur un caillou. Je fais gaffe, et ça va. Grosse montée jusqu’au col de l’Ouillat, où je fais une heure de sieste. Je continue jusqu’au soir, tranquillement. J’ai hâte d’atteindre le pic de Sailfort, aperçu au Roc de France.

Day 30: Tagnarède to Banyuls

Pas de déception à Sailfort, c’est vraiment un dernier grand rempart avant la mer. Je me trompe de chemin pour en descendre, me retrouve bêtement coincé sur une face et obligé de faire demi-tour. Pas important, et ça me fait croiser le “Refuge Tomy”, un abri improbable dans un bout de roche. Mais l’eau m’inquiète un peu, j’en bois des litres et des litres. Un peu plus loin, un robinet est juste planté là. Déjeuner, sieste.

En recollant un morceau de semelle, un couple de randonneurs retraités me dépassent. Je les rattrape, on fait le dernier bout de route ensemble vers Banyuls. Lui finit la Trans’pyr complète en sens inverse^{[24]autre façon de dire HRP, de ce que je comprends}, sa femme l’accompagne pour la dernière semaine. Toutes les nuits en refuge, problèmes de dos oblige, mais il marche à un sacré bon rythme. Sa semelle gauche tient à un fil - littéralement.

Photos devant la mairie de Banyuls, on se quitte là. Baignade à la plage, l’eau est chaude comme elle n’a jamais été dans le Finistère. Office du tourisme, camping, pizza sur la plage. Au camping, je retrouve un des GRdistes de Las Illas ; j’ai par pur hasard choisi l’emplacement à côté du sien. Derniers préparatifs pour le train de retour, l’emménagement en coloc trois jours plus tard… Dur de dormir quand c’est la dernière nuit, puis cette chaleur, constante, incomparable.

Postface

Est-ce vraiment une thru-hike, quand il me manque la partie Hendaye-Cauterets ? Hehe je ne sais pas, mais je compte bien compléter ça ! Les Pyrénées sont vraiment superbes, et de ce que j’en entends, le Pays basque est encore bien différent des hautes Pyrénées et des Pyrénées orientales. J’aimerais aussi voir de plus près l’Aneto et tout le massif de la Maladeta, le Pic du Midi d’Ossau, et le plus possible de vallées perdues là dedans. Sachant à quel point ce type d’aventure me plaît, j’ai juste envie de pousser le challenge plus loin.

Dans tous les cas, je dois un grand merci à ceux qui m’ont accueilli sur le chemin, A&G’, H&S’, la patronne de Juclar, puis à tous ceux qui ont marché avec moi, en particulier G&S qui m’ont rejoint pour une semaine superbe, et bien sûr K, à qui je dois clairement une bière :)

Doooom

“Why doom?”, no one asks? Because doom’s awesome, that’s why. Everyone, once in a while, feels like annihilating truckloads of demons with their bare hands or bare chainsaws. Don’t they? Yes, yes they do. I have a slight preference for the more recent Doom games^{[1]not having experienced the firsts when they came out} myself, but first things first, eh.
Doom’s code is surprisingly self-sufficient, requiring mostly just^{[2]this was not trivial :/} a working libc, but being a relatively big program, it’s a perfect stress test for any platform. Running doom is proof of being able to run awesomeness.

Last time I tried porting doom (to be precise, doomgeneric), I admitted defeat, promising myself I’d get back at it with better tools. So, what did it take? Simple things:

• loading a larger file system: /u/TheMonax pointed out a simple fix for a stupidity of mine that limited the size of grub modules I could load, fixed here
• making static variables part of userspace executables, aka PROGBITS: this way, the kernel doesn’t need to guess how much memory the program needs for its globals and statics, it’s all accounted for in the program size^{[3]of course, an ELF loader would be the better fix}; changed in this commit
• support for command line arguments: doom could have run without, but I wanted those anyway, added here
• many file-related functions: chdir, remove, rename, ftell/fseek, fflush, stat… added in various commits all over the place
• string formatting functions: sprintf & co, which I added by porting stb_printf in this commit
• fewer bugs: one caused a buffer overflow in the ext2 driver when reading a file at an offset, fixed (here), another was in strncpy^{[4]egregious, I know}, fixed in this commit…
• working 64-bit arithmetic: simple things like 64-bit division is compiled by gcc as a call to __divdi3(int64_t a, int64_t b), which I had at first implemented as… return a / b, which did not quite work out. gcc provides an implementation in libgcc, but this time I decided I’d rather have the source for those^{[5]probably a bad idea}, and included arith64 there.

Once everything’s there, all that’s left to do is make small adjustments to the Makefile so that doom gets linked with the same linker script and assembly prologue as the other apps, and voilà!

Doom compiles and runs with no hacks at all on our part. All credits to John Carmack :)

That which is not doom but is still cool

Me remembering that porting doom was an option is pretty recent relative to this blog post. Other things were done!

SnowflakeOS now prints stacktraces, with function names if it crashes in the kernel. This has been super useful for all subsequent development, and at little cost, too. All that’s required code-wise is listed in the wiki, and adding symbols to that takes just little more; here’s what’s done in SnowflakeOS:

1. at link time, grab the kernel’s symbol map generated by the linker: ld ... -Map=linker.map
2. declutter it with awk magic: awk '$1 ~ /0x[0-9a-f]{16}/ {print substr($1, 3), $2}' linker.map > symbols.map, yielding lines like “0xabcdef some_func”
3. load it as a grub module, though I’ll change it at some point so that it’s loaded from the file system
4. when traversing stack frames, look up each address in that file and print the corresponding symbol

A contributor wanted to work on a new process scheduler, which would have been near impossible given the spaghetti-like nature of this subsystem then, so I took this opportunity to refactor the process code, which is now scheduler-independent. Schedulers implement a generic interface, basically a sched_next, sched_add and sched_exit functions, and the process switching code deals with those. This design looks sufficient to cover our use-cases, but we’ll have to see how well it accomodates something other than a round robin scheduler.
Making this change was hard. At some point, nothing worked anymore and I had no idea why. I took a deep dive into the whole thing again, like I had for some of the older posts on here, and as soon as I understood it again, it started working. I fixed some bugs in the process, or rather, things that worked by accident. For instance, my clock in the bochs emulator became fast, which it turns out is the normal behavior. No idea what was happening before. There was also this cool bug, in which the code worked in all but -O2+ builds, due to me being dumb and gcc doing god-like work.

We now have a virtual file system! That means we can seamlessly mix different file systems into a single folder hierarchy, by mounting them wherever we want. As it happens, the only file system we have support for is ext2, so this feature was tested with two ext2 images. I also briefly made a fake^{[6]no idea of the terminology here, but think /proc stuff} file system whose files were the open windows of the wm, mounted on /wm, and processes owning windows owned the corresponding file descriptors, so that when they exited, close was called on the window files, automatically closing the windows. I like the idea, but the implementation was a bit too hacky so I didn’t keep it, though I think it’ll resurface later.

This one is big to me: stdout is a thing. Ever wonder what the hell stdout is, how it works? For the longest time this was entirely unclear to me. I still don’t have a definitive answer on linux, but on SnowflakeOS, I’ve found a way to do it that makes sense to me. By default, a process inherits the file descriptors of its parent - as is tradition - including the one referring to stdout. But say, the first process, it doesn’t inherit anything, it has to acquire an stdout. In SnowflakeOS, a process can declare^{[7]through a syscall} itself as being a “terminal”, which gives it this somewhat special file descriptor, stdout: it refers to a file that can handle read/write operations but is entirely in memory, as a circular buffer. The app that declared itself as a terminal is then expected to read from stdout, and do something with it, like draw its content in its window. Child processes^{[8]there’s technically no such thing in SnowflakeOS, but a process does start another} inherit this exact stdout, thus calling fprintf(stdout, "stuff") writes to the circular buffer that the parent terminal is reading from. With one or many terminals, it all works out.

On the UI side, the calc app finally works! It’s been sitting there, its interface done but not connected to anything, but no longer, thanks to @the-grue’s work, who also contributed the new mouse cursor that you can see in the doom video!

Finally, I’ve finally taken some time to read (gnu) make’s documentation^{[9]it’s very well written, fwiw} properly, and I fixed a few remaining issues with files being rebuilt for no reason, most importantly regenerating the ISO, which is one of the longest operation of the build.

That which did not fit in the other categories

I’ve begun working on some documentation for the project, things that would help someone understand the project and contribute, which would be awesome. There’s now a CONTRIBUTING.md that goes through the usual points. It also describes how to setup clang-format, another new addition that I too will abide by. I even used it to format doom’s source, making it a bit more comfortable to debug. There is also a project wiki, two pages now, but more will come with documentation on the various subsystems and how they interact. If a topic you’d like to see covered is missing, I take requests :)

Unrelatedly, SnowflakeOS bugs out on real hardware/virtual box (see issue #18). I haven’t given this bug my full attention yet, but I bet it’ll be pretty hard to figure that one out. If anyone reading this has any tips, I’ll take them all!

Doom was a long term goal, so, what next? I’m not out of ideas yet, here are a few to end this post:

• ACPI support: includes a switch to multiboot2
• A hierarchy of processes, fork & friends
• A better desktop
• Hard disk support
• Fixing some of these TODOs…

Hopefully one of those will be done by next post, see you then :)

But first, take a look at that whole new logo, designed by the magnificent sylvain-kern <3 The sign of a new era of prosperity for SnowflakeOS, to be sure.

A disk? Wherefore ſhis demonic inſtrument?

The fact is, we don’t have a disk driver of any kind. Those don’t look fun to me right now, the easiest thing to write would be an ATA PIO driver, which is an old an decrepit standard^{[1]I’ll end up loving it at some point <3}. I deciced I wouldn’t bother for now, having a much faster short-term solution in mind: loading the filesystem as a GRUB module.

This is just a matter of generating the filesystem with mkfs.ext2 and placing it in the modules directory. The kernel then sees it as just another module, so we make an exception for it and feed it into the ext2 driver.

Edit 19/10/2020: while the problem described in the following parapgraph was indeed present in SnowflakeOS at the time of writing, it was in fact trivial to solve, and solved in 7d94942. Thanks /u/TheMonax :)

The thing with modules in SnowflakeOS though is that they can’t exceed a certain size, around 3 MiB. The reason for that is that the physical memory manager stores its bitmap just after the kernel and its modules in memory, and when the PMM runs, the kernel has 4 MiB mapped for itself. If modules grow too large, the bitmap ends up unmapped and fun things happen. And it’s too late then to map more memory: paging code has to be able to allocate physical pages, which requires a valid bitmap, etc…

All in all, our disk shall take the form of a pointer to a large area of memory containing the filesystem. In order to facilitate the transition to a real disk later, I decided to constrain myself to block sized reads and writes, hopefully that’s how they work, modulo their block size.

Ext2 fundamentals

In the beginning, there was the block. The block is the unit of size in an ext2 filesystem: they divide the volume into parts of equal size^{[3]1 KiB per block in my tests}, much like how pages are the unit of division for memory. They’re also a form of addressing, because blocks are numbered, and data is always pointed to in the form of a block number.

Blocks contain the filesystem structures themselves: something called the superblock that contains properties of the filesystem, the allocation bitmaps for blocks themselves, for inodes… Inodes, what are they? They’re a structure somewhere in a specific block, described by an inode number, that describes a file, with a file being either a regular file, a directory, or something more esoteric entirely that could still conceivably be called a file by unix gurus. Inodes structures are of fixed size though; the actual file data is only pointed to by block pointers in the structures. For maximum fun and fragmentation potential, this block pointer isn’t simply a block pointer and a length, no, rather it’s twelve direct block pointers, a pointer to a block containing a list of block pointers, a pointer to a block containing pointers to other blocks containing block pointers, and another level of that on top. Allocating such blocks is the very definition of elegance^{[2]sarcasm, please send help}.

Anyway, the rest is most beautifully described by the online book The Second Extended Filesystem by Dave Poirier, and less beautifully and exhaustively described by the current ext2 code in SnowflakeOS, here.

Let’s take a look at the userspace side of files now, here are the calls a fopen call triggers right now:

1. fopen("/some/path", "r") -> FILE*;
2. ↪ syscall2(SYS_OPEN, path, O_READ) -> fd;
3.  ↪ syscall_open(path, O_READ) -> eax = fd;
4.   ↪ proc_open(path, O_READ) -> fd;
5.    ↪ fs_open(path, O_READ) -> fd;
6.     ↪ ext2_open(path) -> inode;

Quite a few layers to this particular onion, and it’s bound to get worse as abstractions replace hardcoded choices. In particular, a VFS^{[3]Virtual File System} is still missing, though maybe it could live in the fs layer here, in fs.c.

With the basics down, SnowflakeOS can now load its wallpaper from disk instead of hardcoding it in a header file; it’s cleaner but the real improvement is the compilation speed: parsing a 2.3 MiB header file takes time. Also, a file explorer was quickly thrown together, resulting in the design hellspawn pictured above.

Bugs in the machinery

Warning: this part gets technical

As usual, I’ve had a healthy dose of madness-inducing bugs this session. Most of them affected a particularly fundamental part of the OS, the memory side of things. I always have mixed feelings about those: one one hand I’m thankful to have found them, on the other hand, it makes me realise that before fixing them, SnowflakeOS ran basically by pure chance. That should be my tag line honestly, “SnowflakeOS, the only luck-powered OS in existence”.

The first bug appeared with the introduction of ext2 read support. Suddenly, my terminal app started crashing when I removed a printf call from its source. Upon inspection, I found that it crashed because the program code I loaded was, in that case, random garbage^{[4]as opposed to the actual code, which is the regular kind of garbage}. Turned out I was doing something dumb, memcpying the code from the physical address given by GRUB, when I should have been copying it from the kernel memory in higher half. Indeed, I only identity map around 1 MiB at the start of physical memory, but I map a whole 4 MiB large page of it to higher half addresses starting at 0xC0000000. The GRUB module containing my terminal code ended up outside of this identity mapped memory, and so reading from it resulted^{[5]how it didn’t crash is a mystery to me} in random garbage being loaded.
Now, while the terminal still crashed in some cases, it ran under specific conditions^{[6]bugs seem to live in 1e6-dimensional space}. But a character or two got scrambled, much like it did back in the day. Now this one was a quick fix; I’d had my head in memory code for a whole day at that point, and re-reading pmm code I noticed I wasn’t marking module memory as taken, only the kernel’s. What that implies is that the pmm is free to allocate this memory, which in SnowflakeOS’s case it does, when starting other processes or allocating new page tables.

Understandably, crashing under any condition is not reasonable; a bug persisted. Like the previous commit message hinted at, I started investigating malloc code, which seemed to cause the crash. Debugging that code isn’t a very pleasant thought to me; this is the realm of pointer arithmetic, raw memory shaped into blocks by sheer willpower, not stuff to mess with. And I trusted that code, too, so having to debug it was disappointing.
My standard, first-approach mode of debugging with printf was out of question here: adding a printf made the crash disappear in most cases; I resorted once again to the ever-trustful (if slow) bochs^{[7]I have one gigantic complaint about it though: bringing up the stack or page tables makes it freeze entirely now, and it didn’t use to be the case. I haven’t gone through the motions of finding out if a change in my code is at fault or if it’s really bochs though. But really, why would it crash? It can give me a linear dump of my stack, why would it crash displaying it slightly differently?}. How peculiar, my static, global variable to the last allocated block was initialised to a non-zero, random-looking value, which caused the initialisation code to be skipped, leading to a segfault when traversing the block list.
It was my understanding that static variables lived in the program code I was generating, for instance, I thought that if I’d added a static array of size 4 KiB, my executable would grow by that much. I knew that wasn’t the case for “standard” executable files in ELF format for instance, but for some reason I’d assumed that flat binaries worked like that, for my convenience. They don’t! To explain the rest of this bug, let me quote myself, in this commit:

Alright, I learned something today:

• flat binaries can use addresses past their size to store static variables,
• there’s no way to tell how much memory a flat binary expects to have for static variables.

The bug was very much related to the aforementionned cool facts. It so happened that my terminal program was 0x2ff1 bytes long, juuust short of three pages, and it placed the global, static variable used_memory at address 0x3000. But when loading the program, I allocated three pages for it, so that program’s malloc memory pool ended up starting at… 0x3000 exactly. On malloc(n), used_memory was increased by n, thus the first block’s next member got assigned n instead of staying null. What does the next allocation check? If the previous block has a successor. Guess what? it does, it’s located at… n. And so, the allocator returned an address corresponding to garbage at the beginning of the program’s code… Ah, the marvels of osdev.

A real, proper fix would require an executable format a bit less primitive than raw binaries, but I haven’t gotten to that point yet. What I did was to allocate one more page than needed by the code, and memset it all to zero to ensure proper initialisation. I really need to get going on an ELF parser, I doubt that a real-world program would be satisfied by a page worth of static variables.

The troubles weren’t over yet though, as a very similar bug happened shortly after fixing that last one: after adding strncmp to my libc, my terminal stopped working again. Adding a function to my libc has one effect: increasing program size, and therefore the total space occupied by GRUB modules. This time though, everything appeared to be in order. No memory corruption, but a crash while mapping pages in malloc’s initialisation. This crash happened at a specific iteration of the loop in charge of mapping a span of pages; it made no sense, the code was correct, dammit. As explained in this commit, I figured it out after taking a day off. Paging code being correct, the physical memory manager had to be at fault^{[9]everything’s obvious in retrospect}. From there, it was a quick fix: I noticed an odd looking calculation:

void pmm_deinit_region(uintptr_t addr, uint32_t size) {
    uint32_t base_block = addr/PMM_BLOCK_SIZE;
    uint32_t num = size/PMM_BLOCK_SIZE;
    ...;

It’s not obvious unless you’ve been bitten by it before, but the issue is on the third line. When you have thirteen eggs, and twelve eggs per box, you need two boxes. Yet, 13 / 12 == 1. But if by chance your number of eggs was a multiple of 12, you would’ve had no bug, which I guess was the case until now. Anyway, I already had a function to deal with that in sys.h:

/* When you can't divide a person in half.
 */
static uint32_t divide_up(uint32_t n, uint32_t d) {
    if (n % d == 0) {
        return n / d;
    }

    return 1 + n / d;
}

The same mistake appeared a few times in my pmm code, a sign of its age really. This fixed, everything was back in order. All of this was a real test of patience, though very much necessary to keep the project going, and very useful for me to get back into the lower level details of memory management.

Clang & UBSan

Having spent a good deal of time tracking down bugs, I thought it good to prioritize setting up a few tools to catch them more easily, or even prevent them. Setting up ubsan in particular had been on my todo list for a while: it’s a compiler tool that pimps up your code to catch undefined behaviors at runtime, and for some reason I thought it was a clang-exclusivity, so I set out to make my Makefile compiler-agnostic and clang-proof.

Clang

First thing I did was replacing CC with clang, and check the results. The results were mostly linker errors. Surprisingly, clang seems to call out to the system’s gcc for a lot of things^{[10]which I’ve forgotten}, and it uses the system’s ld too. Anyway, I basically had to do four things:

• Use ld for compilation phases instead of CC: clang calls ld there, but with somewhat crap arguments, it’s far simpler to call ld directly and have control over them,
• Call as directly, not CC: while clang can compile GNU assembly, it wasn’t keen on doing so with the specific options I wanted to give it,
• Remove -lgcc from LDFLAGS: I don’t remember why it was there in the first place,
• Add -target i386-pc-none-eabi -m32 -mno-mmx -mno-sse -mno-sse2 to CFLAGS: the first two are to tell clang to cross-compile, the last three prevent it from assuming too much about our instruction set^{[11]it used SSE instructions to compile printf…}.

Somewhere in the conversion process I learned that gcc also had ubsan support… No matter! Clang support brings something very very welcome: the possibility to test and develop SnowflakeOS without having to compile a cross-compiler^{[12]To be honest, I’ve never tried to compile SnowflakeOS with my system’s gcc}.

Using clang is now as simple as uncommenting the relevant lines in the main Makefile!

UBSan

Enabling usbsan, on linux for instance, is as simple as adding -fsanitize=undefined to your compiler flags. When cross-compiling however, you can’t do that, you need to implement its (thankfully compact) runtime. This runtime is just the collection of functions that’ll get called when some type of undefined behavior is detected.
A typical handler looks something like that:

void __ubsan_handle_out_of_bounds(void* data, void* index) {
    ubsan_out_of_bounds_data_t* d = (ubsan_out_of_bounds_data_t*) data;
    printf("[ubsan] out of bounds at index %d\n", (uint32_t) index);
    ub_panic_at(&d->location, "out of bounds");
}

It instantly caught an out of bounds error in my keyboard driver, and the fact that my kernel stacks weren’t aligned to 4 bytes, two pretty cool results. Also, it complained about NULL pointer dereferencing in my process loading code, which is fair enough, so I moved my userspace’s entry point to 0x1000 for good measure^{[13]feeling more and more guilty about not having an ELF loader right now :/}. For what it’s worth, you can get the structures and prototypes of whatever’s missing from gcc’s source here.

Apart from that…

Paint

I pushed some UI code I’d written at the beginning of summer to github, and rewrote the paint clone with it; this is close to the entirety of its code:

ui_app_t paint = ui_app_new(win, fd ? icon : NULL);

vbox_t* vbox = vbox_new();
ui_set_root(paint, (widget_t*) vbox);

hbox_t* menu = hbox_new();
menu->widget.flags &= ~UI_EXPAND_VERTICAL;
menu->widget.bounds.h = 20;
vbox_add(vbox, (widget_t*) menu);

canvas = canvas_new();
vbox_add(vbox, (widget_t*) canvas);

for (uint32_t i = 0; i < sizeof(colors)/sizeof(colors[0]); i++) {
    color_button_t* cbutton = color_button_new(colors[i], &canvas->color);
    hbox_add(menu, (widget_t*) cbutton);
}

button_t* button = button_new("Clear");
button->on_click = on_clear_clicked;
hbox_add(menu, (widget_t*) button);

while (running) {
    ui_handle_input(paint, snow_get_event());
    ui_draw(paint);
    snow_render_window(win);
}

Doom, a reality check

So, now that I had a some form of file support (who needs more than read/write anyway?), I thought trying a doom port was in my reach. I got it to compile easily enough, I got it to link pretty quickly too, I even managed to get it to run without crashing, but this is when I realized I didn’t have the drive space to even store one .iwad file Doom requires. Anyway, the executable loops doing nothing at all, not even opening a window.

It was quite cool to confront my libc with a real-world use of a libc. I’m missing all of the sprintf family of functions, many file operations like rename, remove, fseek… but overall, it could be worse. Something that’s getting pressing here is disk space. GRUB modules limit me to 4 MiB, my lack of png decoding makes just the background 2.3 MiB large, it’s getting cramped in there. A disk driver will have to be attempted sooner rather than later.

Osdev work just never ends. It’s the software version of gardening.

On that note…

I’ll see you next time, hopefully talking about ELF loading and disk drivers and as many bugs as possible :)

But wait, you scream, last time you didn’t have moving windows, a mouse pointer, or the ability to get input from userspace, how come now we’re implementing a terminal?
Right, right, let’s get it over with.

Communicating with the wm

If you recall this post, our keyboard and mouse drivers were in pretty fine shape, useless though they were then. We’ll use them right away to register callbacks, set to fire when a key is pressed, or released, and when something happens to the mouse:

void init_wm() {
    ...;
    mouse_set_callback(wm_mouse_callback);
    kbd_set_callback(wm_kbd_callback);
}

Let’s talk about how we handle mouse events first. We want clicks to push windows to the front, we want mouse drags to move windows, and we want some of these events to reach the affected window. I say some, because of a choice made in the wm: windows can be dragged from anywhere in their rectangle, and they can’t opt out. Therefore there can’t be drag events within windows, the cursor doesn’t move relative to the dragged window anyway.
All of that takes some code, about ninety lines total. It ain’t thrilling, so I won’t force it upon your eyes, dear reader, but it’s right here if needed.

A point more worthy of being highlighted is how exactly the wm tells a window “you’ve been clicked here”, or “the mouse moved from here to there”. In most (all?) other OS, the wm is in userspace and uses IPC and some bespoke protocol to speak with its clients.
In SnowflakeOS, clients poll the wm using a system call, snow_get_event, which is really a call to syscall2(SYS_WM, WM_CMD_EVENT, wm_event_t* event)^{[1]all wm commands go through the SYS_WM syscall}. The structure returned, wm_event_t, is a copy of the kernel-side, per-window wm_event_t object, and contains approximately the following fields:

typedef struct {
    uint32_t mask; // describes valid fields
    wm_mouse_event_t mouse;
    wm_kbd_event_t kbd;
} wm_event_t;

where mouse and kbd are defined in somewhat obvious ways in uapi_wm.h^{[2]thanks to Protura’s dev for suggesting this way of sharing kernel headers!}. So, clients poll the wm for this structure, and that’s the client side of it. The kernel, wm side of it is pretty straightforward: the mouse and keyboard callbacks fill mask and other fields as needed, for instance in the keyboard handler:

void wm_kbd_callback(kbd_event_t event) {
    if (windows->count) {
        wm_window_t* win = list_last(windows);

        win->event.mask |= WM_EVENT_KBD;
        win->event.kbd.keycode = event.keycode;
        win->event.kbd.pressed = event.pressed;
        win->event.kbd.repr = event.repr;
    }
}

and events are cleared once they’ve been queried:

void wm_get_event(uint32_t win_id, wm_event_t* event) {
    wm_window_t* win = wm_get_window(win_id);

    if (!win) {
        return;
    }

    *event = win->event;
    memset(&win->event, 0, sizeof(wm_event_t));
}

I’m sure some of you are wondering where event queues fit in there. I’ve heard of them, but I don’t practice^{[3]I’ll make a queue in the keyboard driver for sure}. What do I do if two keys are pressed, and the event structure hasn’t been retrieved in between? I drop a keypress.

Just take your time when writing stuff, it’s the zen of SnowflakeOS.

A terminal

Here’s something I haven’t done in a long time, if ever: writing C apps. There’s a very real difference between kernel code and application code, I think. And I suck at writing actual C programs. C feels much less friendly to me in this space, I guess in large part because I don’t know what I’m doing. For instance I’ve felt the need to make my own string object and related functions. C’s basic string handling functions are notoriously terrible though, I’m surprised it’s the first time I felt the need to replace them.

Anyway, what does a terminal do? Usually, it runs a single program, the shell, and it handles printing its output nice and tidy, which includes handling escape sequences (we had those, a long time ago), line wrapping, sometimes mouse handling I guess. I actually don’t known much more than that. SnowflakeOS has an exec system call^{[4]this is new too! not much work. this one is an actual link btw.}, but no concept of child process, forks, etc… so we can’t have that traditional terminal-shell separation just yet. For the same reason, external processes won’t be able to print to the terminal, only builtin commands. Well whatever^{[5]though this will be fixed}, we just want a fancy way to start paint ;)

The terminal follows the same basic structure of every graphical app ever: handle input, redraw, loop. Let’s take a look at input handling:

while (running) {
    wm_event_t event = snow_get_event(win);
    ...;
    // Skip kbd handling & redrawing in this case
    if (!(key_pressed || focus_changed)) {
        continue;
    }

    ...;

    switch (event.kbd.keycode) {
        case KBD_ENTER:
        case KBD_KP_ENTER:
            str_append(text_buf, input_buf->buf);
            str_append(text_buf, "\n");
            interpret_cmd(text_buf, input_buf);
            input_buf->buf[0] = '\0';
            input_buf->len = 0;
            str_append(text_buf, prompt);
            break;
        case KBD_BACKSPACE:
            if (input_buf->len) {
                input_buf->buf[input_buf->len - 1] = '\0';
                input_buf->len -= 1;
            }
            break;
        default:
            if (key.keycode < KBD_KP_ENTER) {
                char str[2] = "\0\0";
                str[0] = key.repr;
                str_append(input_buf, str);
            }
            break;
    }
}

That’s pretty ugly switch, let me explain. I chose to have two text buffers to represent the text displayed on the terminal. One, input_buf, contains the current line of user input, and it can be edited, and the other, text_buf, contains all the rest. It makes sense then that pressing enter would append the input to the static buffer, interpret that input, and clear it. Currently the terminal handles editing through backspace, no arrow keys yet. Other keys aren’t special (we just require they be printable), and are just appended to the input buffer.
My str_t type makes things a bit ugly there, I haven’t taken the time to make enough utility functions. It’s useful because str_t has no length limit as str_append reallocates if needed, which happens when text_buf grows.

The next step is to interpret the input we got, which is done here:

void interpret_cmd(str_t* text_buf, str_t* input_buf) {
    char* cmd = input_buf->buf;

    if (!strcmp(cmd, "")) {
        return;
    } else if (!strcmp(cmd, "uname")) {
        str_append(text_buf, "SnowflakeOS 0.5\n");
    } else if (!strcmp(cmd, "ls")) {
        str_append(text_buf, "No.");
    } else if (!strcmp(cmd, "dmesg")) {
        char klog[2048];
        sys_info_t info;
        info.kernel_log = klog;
        syscall2(SYS_INFO, SYS_INFO_LOG, (uintptr_t) &info);
        str_append(text_buf, klog);
    } else if (!strcmp(cmd, "exit")) {
        running = false;
    } else {
        int32_t ret = syscall1(SYS_EXEC, (uintptr_t) cmd);

        if (ret != 0) {
            str_append(text_buf, "invalid command: ");
            str_append(text_buf, cmd);
            str_append(text_buf, "\n");
        }
    }
}

Spot the funky dmesg here! The API to get the kernel log is dreadful, but now I can actually debug things from within QEMU:

Finally, we get to redrawing the terminal. We have the tools to draw text, we have the text, let’s do this.

void redraw(str_t* text_buf, const str_t* input_buf) {
    /* Title bar, background... */
    ...;

    /* Text content */

    // Temporarily concatenate the input and a cursor
    str_append(text_buf, input_buf->buf);

    if (cursor) {
        str_append(text_buf, "_");
    }

    char* text_view = text_buf->buf;
    char* line_buf = malloc(max_col + 1);
    uint32_t n_lines = count_lines(text_buf);
    uint32_t y = 22; // below the title bar

    // Scroll the view as needed
    if (n_lines > max_line) {
        for (uint32_t i = 0; i < n_lines - max_line; i++) {
            text_view = scroll_view(text_view);
        }
    }

    // Draw line by line, wrapping text
    while (text_view < &text_buf->buf[text_buf->len]) {
        char* lf = strchrnul(text_view, '\n');
        uint32_t line_len = (uint32_t) (lf - text_view);

        if (line_len <= max_col) {
            strncpy(line_buf, text_view, line_len);
            line_buf[line_len] = '\0';
            text_view += line_len + 1; // +1 discards linefeed
        } else {
            strncpy(line_buf, text_view, max_col);
            line_buf[max_col] = '\0';
            text_view += max_col;
        }

        snow_draw_string(win->fb, line_buf, margin, y, text_color);

        y += char_height;
    }

    // De-concatenate the input
    text_buf->buf[text_buf->len - input_buf->len] = '\0';
    text_buf->len -= input_buf->len;

    if (cursor) {
        text_buf->buf[text_buf->len - 1] = '\0';
        text_buf->len -= 1;
    }

    // Update the window
    snow_render_window(win);
}

Let’s break it down. First, we make sure to work with only one text buffer by merging the input with the static text, we don’t care to distinguish those here. We even include a blinking cursor for sanity reasons. Then, we make sure to draw the “bottom” of the buffer by scrolling if needed. If what this means is unclear, try spamming commands in a newly opened terminal, it’ll scroll the view when you reach the bottom. Finally, we draw the text line by line, keeping in mind that a line either ends with a line feed, or by reaching the right side of the window.
If you’re like me and didn’t know about it, strchrnul returns the the address of the trailing null byte in a string if nothing matches the query, instead of returning NULL like the classic strchr would.

All in all, we now have a working terminal.

Paint

Kernel development is an art, or so some think. I enjoy consensus and wanted to address the concerns of naysayers, and with that goal in mind set out to make my kernel art-able. What program then could be better suited to artistic expression than the humble paint?

The code here has even fewer bells and whistles than the terminal, and I won’t dare bore you with it. Get input, if click, toggle drawing, if mouse move and drawing, draw a line, loop. Note that because of window dragging mechanics you can’t keep pressing the mouse to draw, you have to release it. I think it’s not totally senseless UX-wise^{[6]it mostly is though, yes}, as you’re free to focus only on the movement of your hand.

But, but, but, the five cool, old-school buttons on the top left are of some interest. I’ve started making a GUI toolkit, and what you’re really seeing here are three color picker buttons and two normal buttons in a horizontal layout. This code is really a work in progress by any measure, but working on it has been pretty interesting so far. I’m taking a GTK-like approach, because it’s the only C GUI toolkit I’ve ever touched. Thankfully I barely remember any of it, so I’m free to make the same mistakes it did, but also new and cooler ones.

In our paint version, this toolkit is used in a very hackish way, but it gives a general idea of how things will look:

/* Setup the UI */
hbox_t* picker = hbox_new();
// No parent/root widget, so we position it manually
picker->widget.bounds.x = fb_x + 10;
picker->widget.bounds.y = fb_y;

// `color` is defined earlier
hbox_add(picker, (widget_t*) color_button_new(0x000000, &color));
hbox_add(picker, (widget_t*) color_button_new(0x513CBC, &color));
hbox_add(picker, (widget_t*) color_button_new(0xFC0A5A, &color));

button_t* exit_button = button_new("exit");
exit_button->widget.on_click = (widget_clicked_t) on_exit_clicked;
hbox_add(picker, (widget_t*) exit_button);

button_t* clear_button = button_new("clear");
clear_button->widget.on_click = (widget_clicked_t) on_clear_clicked;
hbox_add(picker, (widget_t*) clear_button);

...; // Later, in the program loop

/* Give these lads some input */
if (point_in_rect(pos, picker->widget.bounds)) {
    picker->widget.on_click((widget_t*) picker, pos);
}

Anyway, you can paint stuff now. It’s plenty fast in QEMU, but that could still be easily improved: right now we tell the wm to update the whole window rect^{[7]clipping rules still apply in wm land, of course}, when we could tell it to update only the small square containing the new line we just drew. Another big improvement, and not just to paint, would be to store the mouse’s position as a pair of floats instead of ints, because right now small movements are basically ignored due to rounding errors in the wm’s code. One advantage is that it’s really easy to draw squares right now, but unless a sizeable fraction of users turns out to be rabbid fans of the Suprematist movement, I think it’s worth fixing.

On a final note, I wanted to thank /r/osdev’s users for sharing their progress, in particular skiftOS’s developer, whose beautiful UI and OS reminded me to try a little harder, because the results are clearly worth it.

Wait a minute… this has nothing to do with kernel dev

Guess again! SnowflakeOS’s window manager is in the kernel^[1]. It is quite rude for a system call to take a whole second to return, and sadly this is the situation we found ourselves in.

How did we end up like this?

It’s relatively easy to make a slow window manager, which is what we did. Just redraw all of your windows when you wish to redraw one, hell, redraw your whole desktop when you move the mouse!

Of course, don’t forget to use an off-screen buffer so that you can copy the whole screen buffer twice every chance you get.

To be fair, I don’t write window managers everyday :)

Hello clipping my old friend

The key to performance, always, is to not do things. And indeed, not doing much will be the path to our goal here, through an arcane concept called clipping.

I’d work all night if it meant nothing got done.

• Ron Swanson

Quick overview

Consider this situation, in which a window needs redrawing:

We can only see an L-shaped portion of it, clearly we don’t want to redraw more than that. It’s not easy copying an L-shape from a big array of pixels though, imagine the look of that for loop :)

This is why we’re going to cut up this L into rectangles, like this:

Much better, now this is something we can work with!

This whole “cutting stuff up into rectangles” is very visual, easy for us to do, but it’s not easy to see how to turn it into an algorithm. It’ll be some work, but it’ll pay off!

Implementation

As mentionned a few articles ago, this awesome series of articles will be the basis for SnowflakeOS’s implementation of clipping. Many thanks to the author!

Rectangle splitting

Our basic need is to be able to “split a rectangle by another”: given a rectangle to be split, R, and a rectangle that covers it S (for splitting rectangle), we want to get new rectangles, called clipping rectangles of R, satisfying the following conditions:

• their union must cover the area R \ S,
• they must be disjoint: no two of them should intersect.

In the above image for instance, “redraw me” was split by “doom.exe”, which produced two clipping rectangles, marked 1 and 2.

Clipping rectangles are never unique, but for our purpose they may as well be.

The core idea of the splitting algorithm is to examine each edge of S and check if it cuts through R. If it does, we have created a first clipping rectangle, and we can repeat the operation for the next edges, only now with a smaller rectangle to cut.

Here’s the algorithm:

list_t* rect_split_by(rect_t rect, rect_t split) {
    list_t* list = list_new();
    rect_t* tmp;

    // Split by the left edge
    if (split.left >= rect.left && split.left <= rect.right) {
        tmp = rect_new(rect.top, rect.left, rect.bottom, split.left - 1);
        list_add(list, tmp);
        rect.left = split.left;
    }

    // Split by the top edge
    if (split.top >= rect.top && split.top <= rect.bottom) {
        tmp = rect_new(rect.top, rect.left, split.top - 1, rect.right);
        list_add(list, tmp);
        rect.top = split.top;
    }

    // Split by the right edge
    if (split.right >= rect.left && split.right <= rect.right) {
        tmp = rect_new(rect.top, split.right + 1, rect.bottom, rect.right);
        list_add(list, tmp);
        rect.right = split.right;
    }

    // Split by the bottom edge
    if (split.bottom >= rect.top && split.bottom <= rect.bottom) {
        tmp = rect_new(split.bottom + 1, rect.left, rect.bottom, rect.right);
        list_add(list, tmp);
        rect.bottom = split.bottom;
    }

    return list;
}

Not an easy read, for sure. I won’t detail the list_t and rect_t types and associated functions, but you can trust that they do what they say. The list implementation can be found here, and operations on rect_t can be found here.

Some more convenient tools

The previous algorithm solves our previous situation perfectly, but suppose now that two windows cover the one we wish to redraw:

Say we split our window by “doom.exe 2”, and we get two clipping rectangles out of it. One of those is going to intersect with the “doom.exe 3” window, and this is no good, we’d be drawing a hidden part of the window.

What can we do? Well, let’s just split each one of our newly-acquired clipping rectangles by that second window! We’ll get a new list of clipping rectangles for each clipping rectangle intersecting with “doom.exe 3”… What we want is to keep only those new clips, and not the old ones. Well, there’s your algorithm.

To put it another way: given a list of clipping rectangles, and a splitting rectangle R, this algorithm punches an R-shaped hole in the area covered by the clips, while maintaining the two conditions listed previously.

The implementation is a bit easier to reason about this time:

void rect_subtract_clip_rect(list_t* rects, rect_t clip) {
    for (uint32_t i = 0; i < rects->count; i++) {
        rect_t* current = list_get_at(rects, i); // O(n²)

        if (!rect_intersect(*current, clip)) {
            continue;
        }

        rect_t* rect = list_remove_at(rects, i);
        list_t* splits = rect_split_by(*rect, clip);
        uint32_t n_splits = splits->count;

        while (splits->count) {
            list_add_front(rects, list_remove_at(splits, 0));
        }

        kfree(current);
        kfree(splits);

        // Skip the rects we inserted at the front and those already checked
        // Mind the end of loop increment
        i = n_splits + i - 1;
    }
}

The subtility is that we’re both removing and adding rectangles in our list of clips each iteration, so we need to keep a good track of where we are in our loop. The original author just set i = 0 at the end of the loop, which works great of course because the new clips we create never intersect with clip, but it wastes like, 30 clock cycles… :)

The cool thing with this new algorithm is that it superseeds the previous one entirely. Indeed, we don’t need a special case when we want to split a window: just put it in a list, and call the algorithm! Credit to the first one of course, it powers the whole thing.

It’s how you use it

Good, the hard work is done. We can draw stuff efficiently now, we have the technology!

Drawing a window

Consider our window’s rectangle. List all of the windows covering it, and punch a hole in the rectangle for each of them. Draw the areas of the window described by the clipping rectangles obtained. Simple as that!

Translated word for word^[2] in C:

void wm_draw_window(wm_window_t* win, rect_t rect) {
    rect_t win_rect = rect_from_window(win);
    list_t* clip_windows = wm_get_windows_above(win);
    list_t* clip_rects = list_new();

    list_add(clip_rects, rect);

    // Punch a hole for each covering window
    while (clip_windows->count) {
        wm_window_t* cw = list_remove_at(clip_windows, 0);
        rect_t clip = rect_from_window(cw);
        rect_subtract_clip_rect(clip_rects, clip);
    }

    // Draw whatever is left in our clipping rects
    for (uint32_t i = 0; i < clip_rects->count; i++) {
        rect_t* clip = list_get_at(clip_rects, i); // O(n²)

        // Fun edge case
        if (!rect_intersect(*clip, win_rect)) {
            continue;
        }

        wm_partial_draw_window(win, *clip);
    }

    rect_clear_clipped(clip_rects);
    kfree(clip_rects);
    kfree(clip_windows);
}

Notice the wm_partial_draw_window function call: it’s the only function that does any actual pixel work. It’s both mundane and insane (“the land of off-by-ones” you may say), and you can check it out here.

Drawing part of the screen

Imagine you’re closing a window. Then you have to redraw whatever was below that window, and that could be like, several windows. Do we redraw them entirely? Of course not, we can just redraw the parts of them that was covered by the closed window.

This is what led to the second parameter of wm_draw_window, i.e. a rect that says “draw within this area”. It’s used in the following short function that implements the redrawing of an area:

void wm_refresh_partial(rect_t clip) {
    for (uint32_t i = 0; i < windows->count; i++) {
        wm_window_t* win = list_get_at(windows, i); // O(n²)
        rect_t rect = rect_from_window(win);

        if (rect_intersect(clip, rect)) {
            wm_draw_window(win, clip);
        }
    }
}

What happens when a part of the screen you want to redraw isn’t covered by any window? As you may read above, nothing. Thankfully this doesn’t happen^[3], because there’s a huge window that draws the wallpaper… Ahem, I’ll get to it at some point ^^’

As a quick aside, you may have noticed the O(n²) sprinkled here and there in the code. Those are reminders for me to replace the list implementation I used: while really easy to use, iterating such a list automatically has quadratic complexity, which is obviously ridiculous. I doubt that it matters at all until you reach an absurd amount of windows, but it irks me a good bit. I’ll take Linux’s list.h to replace it, it looks just perfect.

Performance

Let’s see if we can get some numbers in here, check that all this work wasn’t in vain.

Our test will be spawning a hundred windows from a single process, plus the wallpaper. We will record the whole thing, and count the frames needed to go from a black screen to the 100^th window.

Before clipping, as of March 14th

It took 172 frames to get from the wallpaper to the last window, or 5.74 seconds.

After clipping

Now, it takes 11 frames, or 0.37 seconds. This is an improvement of about 1500%…

Mission accomplished!

We will for sure get smooth mouse movements and smooth window dragging in the next article now ^[4], until next time!

The basics

I decided to take guidance from this post by Dmitry Soshnikov, implementing in this post only the basics, to get to a point at which I can freely call kmalloc and kfree, without throwing away too much memory. And perhaps malloc and free in userspace later?

There is some terminology to get down before diving into the details:

• memory allocator: a function that a program can call that returns an address to which the program can freely write. Typically, malloc. Different allocators have different qualities, such as performance, minimizing memory fragmentation…
• memory block: a contiguous range of memory addresses, with a few attributes such as whether it’s in use or has been freed, its address and size… These attributes are stored in the block’s header.
• alignment: an address addr is said to be N-aligned if addr % N == 0. It’s important for a kernel allocator to be able to allocate buffers with specific alignments, as we’ll later see.

Our previous allocator: now too simple

Previously, SnowflakeOS used what’s called a bump allocator, i.e. an allocator that keeps track of the last block only, and that always allocates after that last block, with no means of freeing previous blocks individually.

I would’ve liked to keep that design as the implementation is concise and easy to understand, but unfortunately it’s now too simple for my use. Not being able to reuse blocks is the deal breaker here, as the window manager will have to do a lot of small and short-lived allocations, and the goal is to not to run out of memory in five seconds.

The new allocator will have to keep one feature from its predecessor, the ability to hand out addresses with a specific alignment. This is strictly needed, as we need to be able to remap a newly acquired page from our allocator, and pages boundaries are multiples of 4 KiB. See for instance this use case.

The new allocator

We’ll write a first-fit memory allocator that can deliver arbitrarily-aligned addresses. You can find the whole source here, and an updated version for the end of this post here.

First, our blocks are defined by the following struct. The first two members constitute the header:

typedef struct _mem_block_t {
    struct _mem_block_t* next;
    uint32_t size; // We use the last bit as a 'used' flag
    uint8_t data[];
} mem_block_t;

That last member is what’s called a “flexible array member” in C99. It’s an array without a given dimension, i.e. we can manage its size manually by saying “I know that the memory after this struct is mine, let me access it though this member”. Here, it’ll be the pointer returned by our kmalloc function.

And secondly, we use a simple first-fit design, i.e. when allocating something, we first look through our list of blocks and see if there’s a free one that fits our criteria of size and alignment. The global algorithm is as follows:

void* kamalloc(uint32_t size, uint32_t align) {
    size = align_to(size, 8);

    mem_block_t* block = mem_find_block(size, align);

    if (block) {
        block->size |= 1; // Mark it as used
        return block->data;
    } else {
        block = mem_new_block(size, align);
    }

    if ((uintptr_t) block->data > KERNEL_HEAP_BEGIN + KERNEL_HEAP_SIZE) {
        printf("[MEM] The kernel ran out of memory!");
        abort();
    }

    return block->data;
}

And the “first-fit” logic is implemented in mem_find_block here, in no particular magic:

mem_block_t* mem_find_block(uint32_t size, uint32_t align) {
    if (!bottom) {
        return NULL;
    }

    mem_block_t* block = bottom;

    while (block->size < size || block->size & 1 || !mem_is_aligned(block, align)) {
        block = block->next;

        if (!block) {
            return NULL;
        }
    }

    return block;
}

The load-bearing portion of our allocator is in the creation of blocks, in mem_new_block:

mem_block_t* mem_new_block(uint32_t size, uint32_t align) {
    const uint32_t header_size = offsetof(mem_block_t, data);

    // We start the heap right where the first allocation works
    if (!top) {
        uintptr_t addr = align_to(KERNEL_HEAP_BEGIN+header_size, align) - header_size;
        bottom = (mem_block_t*) addr;
        top = bottom;
        top->size = size | 1;
        top->next = NULL;

        return top;
    }

    // I did the math and we always have next_aligned >= next.
    uintptr_t next = (uintptr_t) top + mem_block_size(top);
    uintptr_t next_aligned = align_to(next+header_size, align) - header_size;

    mem_block_t* block = (mem_block_t*) next_aligned;
    block->size = size | 1;
    block->next = NULL;

    // Insert a free block between top and our aligned block, if there's enough
    // space. That block is 8-bytes aligned.
    next = align_to(next+header_size, MIN_ALIGN) - header_size;
    if (next_aligned - next > sizeof(mem_block_t) + MIN_ALIGN) {
        mem_block_t* filler = (mem_block_t*) next;
        filler->size = next_aligned - next - sizeof(mem_block_t);
        top->next = filler;
        top = filler;
    }

    top->next = block;
    top = block;

    return block;
}

Notice that second if: as we want to support arbitrary alignment of the blocks we hand out, we want to prevent space from being wasted in between blocks, so unused blocks will be created to fill the gaps as they appear. For instance, imagine the heap is at 0x40, and a 0x1000-aligned block is requested. Then a gap of about 0x1000-0x40=0xFC0 bytes will be created between the first block and the new one. We’ll create a block there with minimum alignment to fill the gap.

Note that the pages that consitute the memory we’ll be distributing are already mapped in the kernel. That way the kernel can allocate after starting to execute in multiple page directories, without having to mirror the paging changes in each process. This is where the preallocation is done in paging.c:

    // Setup the kernel heap
    heap = KERNEL_HEAP_BEGIN;
    uintptr_t heap_phys = pmm_alloc_pages(KERNEL_HEAP_SIZE/0x1000);
    paging_map_pages(KERNEL_HEAP_BEGIN, heap_phys, KERNEL_HEAP_SIZE/0x1000, PAGE_RW);

Think of the (userspace) children!

Porting the allocator to userspace

Sure, the kernel and its window manager are what will be stressing memory the most for a while, and we could get away with keeping a bump allocator for our userspace malloc. That memory is freed on exit anyway. But where’s the fun in that? Can’t we adapt our code so that it works in both the kernel and in userspace?

Of course we can. We already have a build-level mechanism for that with our C library, which is built twice: once for the kernel with the _KERNEL_ preprocessor symbol defined, and a second time for userspace.

There are two things that we’ll have to adapt for userspace:

1. Our allocated blocks will now live after our program in memory, i.e. at sbrk(0), and not after our kernel executable.
2. Whereas the kernel has its whole memory pool preallocated, that makes no sense for userspace, so we’ll have to call sbrk regularly to ask the kernel for more memory.

To address the first point, I added the following bit of code to the beginning of malloc:

    // If this is the first allocation, setup the block list:
    // it starts with an empty, used block, in order to avoid edge cases.
    if (!top) {
        const uint32_t header_size = offsetof(mem_block_t, data);

#ifdef _KERNEL_
        uintptr_t addr = KERNEL_HEAP_BEGIN;
#else
        uintptr_t addr = (uintptr_t) sbrk(header_size);
#endif
        bottom = (mem_block_t*) addr;
        top = bottom;
        top->size = 1; // That means used, of size 0
        top->next = NULL;
    }

And to address the second point, I added this distinction before calling mem_new_block:

        // We'll have to allocate a new block, so we check if we haven't
        // exceeded the memory we can distribute.
        uintptr_t end = (uintptr_t) top + mem_block_size(top) + header_size, align;
        end = align_to(end, align) + size;
#ifdef _KERNEL_
        // The kernel can't allocate more
        if (end > KERNEL_HEAP_BEGIN + KERNEL_HEAP_SIZE) {
            printf("[MEM] The kernel ran out of memory!");
            abort();
        }
#else
        // But userspace can ask the kernel for more
        uintptr_t brk = (uintptr_t) sbrk(0);
        if (end > brk) {
            sbrk(end - brk);
        }
#endif

        block = mem_new_block(size, align);

Testing it

To test that new malloc, I made a program to open and close windows continually while keeping the number of windows constant, which you can see in action above.

To be somewhat scientific, I counted the number of calls to sbrk. If everything was right, this program would call it a few times, then blocks would be reused ad infinitum.

And it did! With 20 windows, I counted 69 sbrks, and no signs of more coming up even after five minutes of frenetic window respawning.

A point on kernel/userspace interactions

It may not be clear what the code paths are for the userspace version of malloc, so I’ll detail them a bit.

When a program calls malloc, execution stays in userspace, because the allocator is in the C library linked to it, along with everything else. If malloc’s memory pool needs expansion (i.e. there’s no room to add a free block), the sbrk system call is run, and execution jumps in the kernel. That system call maps pages as needed to expand the heap of the program. The process of mapping those pages may itself involve allocating memory for the kernel to create new page tables, but in this case, the kernel calls pmm_alloc_page to get a fresh page of physical memory directly, so kmalloc is never involved.

It would have been pretty neat to have malloc call kmalloc, wouldn’t it? I like the idea of a piece of code calling another compilation of itself, anyway.

This is what putchar does, so at least such cross-source calling goodness is done somewhere. A call to putchar in userspace translates to the putchar system call which calls the kernel version of putchar, which is about two lines above the first call in the source:

int putchar(int c) {
#ifdef _KERNEL_
    term_putchar(c);
    serial_write((char) c);
#else
    asm (
        "mov $3, %%eax\n"
        "mov %[c], %%ecx\n"
        "int $0x30\n" // Syscall
        :: [c] "r" (c)
        : "%eax"
    );
#endif
    return c;
}

Neat.

Miscellaneous bugs crushed since last time

A scrambled ‘w’

When I first tested my new kernel allocator, it seemed to work fine except for one detail. The ‘w’ of “SnowflakeOS” in the top left corner of the background and in the title bar of my window looked all wrong:

And only when compiling without the nice blue background and identity mapping more pages than needed at the beginning of memory. Which I did then, otherwise I perhaps wouldn’t have spotted this bug.

I fixed it in this commit, basically by paying attention to where my GRUB modules (i.e. my programs) were in memory, and protecting that memory. Indeed, those modules were loaded right after my kernel in memory, and guess what I used that area for? The bitmap of my physical memory manager. That’s not a story a James Molloy would tell you^[1].

Now I check exactly where my modules end and place my physical memory manager after that, and I identity map exactly the right number of pages to be able to copy the modules into kernel memory.

Classic windows

The gif at the top of this post looks somewhat okay, but it took some effort. Basically, I wanted a program that spawned N windows then closed the oldest ones and replaced them, in a loop. The first iteration of that popup-spamming program would either spawn +oo windows, or spawn N windows then get stuck in an infinite loop somewhere.

The problem, explained in this commit, was that I had failed to maintain the integrity of my doubly linked list of windows when deleting an element, and the list turned into a circular list when traversed backwards, leading to an infinite loop in wm_count_windows.

Till next time

That’s it for this post, which is already far too long, too late and all over the place.
Thank you for reading till the end!

WM design: simple is too simple

In the last post

Here’s how it worked:

1. The WM held a state: which window had to be drawn next to correctly on top of others
2. Windows had to call the WM in a loop in order not to block others

The rationale was that having the windows call the WM allowed for a single buffer per window. Performance wasn’t great either: framerate was limited by the slowest window, drawing a single frame took as many system calls as there are windows, and each window had to be copied entirely. Plus the final off-screen buffer to framebuffer copy. Last but not least, drawing in a loop when the screen doesn’t even require redrawing is plain dumb.

A slight improvement

Since the last post, I decided I could spare the RAM to build something less outrageous, so now it works like this:

1. When a window calls the WM, its buffer is copied in the kernel
2. All windows are redrawn from their in-kernel buffers
3. The off-screen buffer is copied to the framebuffer

Now the screen is only refreshed as needed, in a single system call, but when it needs to be, it’s still incredibly slow. For a video mode of 1024x768x32, we’re copying at least 6 MiB per refresh. Still sort of outrageous.

Reinventing the wheel from second-hand principles

Doing a bit of searching, I found a magnificent series of blog posts by Joe Marlin^[2] in which he implements a window manager from scratch in C, taking proper design and performance in consideration. Finding information about the algorithms and architecture of window managers is surprisingly difficult, which is why Joe’s posts are of such value.

One of the techniques described that I really want to implement is clipping, to avoid copying so much memory and redrawing things that haven’t changed. There’s also a neat GUI system described there, but I don’t want to have it live in the WM so I’ll make my own way there.

Miscellaneous improvements since last time

Bug hunting

I’ve spent most of my development time on this item, with two outstanding bugs.

The first was a page fault occuring only when optimisations were turned when compiling the kernel. I fixed it in this commit and while the precise instruction causing the fault escaped me, I know it was a result of two things:

• I used ebx to pass arguments in my system calls without saving its value: it’s a callee-saved register in the C calling convention. It was only a matter of time before it caused a bug.
• Even after fixing the above point, not qualifying my inline assembly system calls with volatile left my code crashing. I guess gcc tried something funny during optimisation there.

The second bug was with my background window (shown at the top of this post) being shifted 50 pixels to the right. Specifically, the top row began at the 51th pixel, thus shifting the rest of the image, and drawing 50 pixels past the end of the buffer. The worst is that this bug occured only with -O2 optimisations turned on, and only on bochs, not on QEMU. This made me think it had to be a memory error, caused by me triggering undefined behavior somewhere, as I had reworked my malloc implementation just before^[3].
It turned out to be a lot more mundane: with optimisations on, my scheduler switched from the “background window” program ealier than in other cases, so it opened its window after the other program. Can you guess what my window-placing code does? It shifts new windows 50 pixels to the right of the last one. The first window was placed at x=0, the background at x=50.

I was rooting for a much more interesting resolution for that second bug! That’ll teach me not to make too many assumptions while debugging, and not to be okay with drawing outside buffers. And my window-placing code is now clearly marked as “radioactive garbage”.

Gradual improvements to malloc

I’ve implemented the sbrk^[4] system call as a first step to get a free-able malloc implementation. It’s useful for allocating and deallocating memory after the program’s code. Handling page boudaries make the code somewhat hard to understand. If the program asks for n more bytes, do we need to allocate a new page? several? Same thing for deallocation.

For the first time^[5], I spent some time reading about memory allocators, on this clear and concise site in particular. It’s pretty much a requirement for implementing clipping in my window manager, so that’s what comes next.

Putting programs to sleep

Finally, long-standing useless system call number 2 works, processes can sleep! Well, most of the time, there are still two issues:

• When all processes sleep, one has to run anyway. To avoid this situation, I need to add an “idle” process that does nothing yet never sleeps.
• Sleep doesn’t work on bochs, as it’s a bit more anal than QEMU about the FPU^[6] not being setup. I compute the number of timer ticks to sleep using (ms/1000.0)*TIMER_FREQ, and without initialising the FPU, this always equals 0 on bochs.

Setting up the FPU isn’t entirely trivial as it’s a part of the execution context of a process that isn’t saved on task switch, so it needs special care. It’s on the shortlist though, it’s pretty important.

Background improvements

Notice how the wallpaper doesn’t look like a graphical glitch anymore? I picked a background, converted it to raw RGB values, stuck it in a C header with xxd -i and loaded it in the buffer of my background window. At 14 MiB of header file, it’s outright heavy, but thankfully once compiled it compresses down to around 2 MiB. A PNG parser is somewhere on my todo list :)

The boring part: switching video mode

A prerequisite to doing anything is to get the screen in a state in which we can access individual pixels instead of just characters. The traditional way of doing so is to manually call BIOS functions to get available modes and choose one while the computer is still executing in real mode. In the case of SnowflakeOS, this isn’t practical: the kernel is loaded by GRUB, so it starts executing in protected mode, where we can’t access BIOS functions. There are two ways around that:

• Enable virtual 8086 mode - an emulation of real mode - long enough to set the video mode, then get back to protected mode
• Ask GRUB to set the correct video mode before loading our kernel

The first option is the one most advertised on the osdev wiki, and at first it was the only one I knew about. Switching to virtual 8086 mode is easy enough, it involves faking an interrupt return in order to set the VM bit in the eflags register, kind of how we switched to ring 3 for the first usermode process. I don’t known much about this mode given that I didn’t end up implementing support for it, but there were several issues I could see taking a lot of work to resolve: how does execution get back to the kernel? do I have to implement support for virtual 8086 tasks within my scheduler? do I need to compile the executing code in 16-bit mode? what happens to my kernel stack?… Far too much work that feels like writing boilerplate code. I was very happy to discover an alternative.

The second option is simpler by a long shot. Asking GRUB to set the video mode is as easy as modifying the multiboot header that’s sitting at the very beginning of our kernel binary:

.section .multiboot
    .long MAGIC
    .long FLAGS_PAGE_ALIGN | FLAGS_MEMORY | FLAGS_GRAPHICS
    .long -(MAGIC + FLAGS) # checksum
    .long 0x00000000
    .long 0x00000000
    .long 0x00000000
    .long 0x00000000
    .long 0x00000000
    .long 0    # 0 for a linear framebuffer, 1 for text mode
    .long 1024 # width
    .long 768  # height
    .long 32   # bpp

The downside is that you can’t choose a resolution or bit depth dynamically: if the precise mode you asked for isn’t available, GRUB will choose one for you. That sounds like a fair tradeoff to me.

GRUB gives us a framebuffer described by the following entries in the multiboot structure:

typedef struct {
    uint64_t address;
    uint32_t pitch;
    uint32_t width;
    uint32_t height;
    uint8_t bpp;
    uint8_t type;
    // Technically, the layout of the following fields depends on the value of `type`
    uint8_t red_position, red_mask_size;
    uint8_t green_position, green_mask_size;
    uint8_t blue_position, blue_mask_size;
} __attribute__ ((packed)) fb_info_t;

Some fields are a bit obscure here: pitch is the number of bytes per rows, bpp is the bit depth, type should be 0 (otherwise GRUB gave us text buffer), and the color fields indicate the pixel layout.
I think the reason pitch is given here is that there can be padding bytes between each “line” of pixels, so it may not necessarily equal width*bpp/8, though it does for QEMU and Bochs.

The address field refers to a physical address, so we mustn’t forget to map it after enabling paging. For a 1024x768x32 mode, the framebuffer is 3 MiB large, so it’s not exactly a trivial allocation in the kernel heap, where I chose to map it. An alternative would be to map it on request in processes’ address spaces where addresses are aplenty, but I’d rather not expose it raw to usermode applications.

Rocking that framebuffer

Plotting pixels

Now that we have an address to write to, plotting a pixel is a matter of computing its offset and knowing its format. The address of the pixel at (x, y) is given by

uint32_t* offset = (uint32_t*) (address + y*pitch + x*bpp/8);

Once you’re there, all that remains is implementing some drawing primitives. Rectangles, lines, borders…
Line drawing algorithms are somewhat convoluted, there are several and I ended up implementing Bresenham’s algorithm which is well-detailed on wikipedia.

Getting our text back, the PSF format

The most straightforward way to draw text has to be through bitmap fonts. In a bitmap font, a character is represented by an array of bits, with say each n bits representing a line of pixels in the character. For example, here’s a very crude ‘O’:

0 1 0
1 0 1
0 1 0

It turns out there’s a dead easy format still in wide use: PSF, for PC Screen Font, used by virtual consoles in Linux.

There are two versions of this format:

• PSF1: fixed number of characters, 8 pixels wide, variable character height
• PSF2: variable number of characters, variable character size

Both formats have a short header at the beginning of the file. On my machine, all fonts in /usr/share/kbd/consolefonts seem to be PSF1. In this format, the header looks like this:

typedef struct {
    uint8_t magic[2];
    uint8_t mode;
    uint8_t height;
} font_header_t;

Where magic should equal 0x36, 0x04, mode contains information about the number of characters and unicode support (which I haven’t dealt with), and height is the height of each character in pixels.
The actual font starts right after the header, so the offset of an ASCII character c in the font file, in bytes, is given by

uint32_t offset = sizeof(font_header_t) + c*height;

Drawing a character is then a matter of checking individual bits, line by line, and plotting pixels accordingly.
I extracted the font used in my console with

setfont -o font.psf; xxd -i font.psf > font.h

and used that one. The characters are those shown in the image above, in 8x16 format.

From rectangles to windows: a window manager

Until now we’ve only drawn shapes the the screen. What turns a shape into a window? By my definition, a window manager (WM).

Design

In SnowflakeOS, the window manager handles only two concepts:

• windows: those are rectangular buffers with an (x, y) position, a z-order and a few flags
• focus: who gets user input?

It knows nothing of window decorations, concepts of desktop background, taskbar, or even mouse pointer. Those things will be windows, managed by userspace applications, clients of the WM.
As far as I know, this minimalist approach is somewhat close to how weston works, a window manager for wayland.

The WM needs to communicate with applications wishing to use windows. Usually, the WM is a userspace program, so this is done using a form of inter-process communication. I decided against implementing such a system for now - I tried my hand at a virtual file system, pipes and all, but I felt I didn’t have enough background to properly design anything, or to implement the usual APIs of Unixes.
Thus, I implemented the WM in the kernel, and programs communicate with it through system calls. It’s a pretty crude and non-general way of communicating, but it works for now.

The userspace API

I introduced a library for SnowflakeOS programs, thoughtfully named snow, which wraps system calls in pretty C functions.
It offers a snow_open_window function which allocates a buffer of the window’s size. Drawing functions then write to that buffer, and the program asks for that window to be drawn to screen by calling snow_render_window. There are no GUI functions right now - only mockups - but they’ll sit between those two calls. Closing the window is then done though snow_close_window.

Here’s an example of what can be done right now:

#include <snow.h>
#include <string.h>

int main() {
    window_t* win = snow_open_window("A static window", 300, 150, WM_NORMAL);

    snow_draw_window(win); // Draws the title bar and borders
    snow_draw_string(win->fb, "Lorem Ipsum", 45, 55, 0x00AA1100);
    snow_draw_border(win->fb, 40, 50, strlen("Lorem Ipsum")*8+10, 26, 0x000000);

    while (true) {
        snow_render_window(win);
    }

    snow_close_window(win);

    return 0;
}

Giving this result:

Implementation

Registering a window

This means appending a given buffer to a list of windows to be drawn, and assigning it a z-order and unique id, a window being defined as

typedef struct _wm_window_t {
    struct _wm_window_t* next;
    struct _wm_window_t* prev;
    fb_t fb;
    uint32_t x;
    uint32_t y;
    uint32_t z;
    uint32_t id;
    uint32_t flags;
} wm_window_t;

This is my second use of intrusive lists in SnowflakeOS. I really ought to make a utility library to handle those, as I’ve had to write some very repetitive code in functions such as wm_find_with_id, wm_find_with_flags or wm_find_with_z. The lack of lambdas in C can really be felt in this situation.

Handling z-order

This was less trivial than anticipated! Here’s how I handled it. Z-orders are consecutive natural numbers, with 0 being the least visible window (e.g. a desktop background), and higher numbers being drawn on top of lower numbers.
A newly opened window is assigned the highest z-order. When a window is closed, z-orders are shifted so that there is no gap between 0 and the highest z.
Windows with a flag like WM_FOREGROUND will always stay on top of others, and similarly, those with WM_BACKGROUND fight for the lowest z-order.

I’m making things up as I go, to be honest. I’m sure I’ll figure out the good from the bad in due time :)

Drawing a full frame

Edit: this is a poor implementation, see the next post for a better one.

The goal here is to draw windows in the correct z-order. Keeping in mind that window buffers are in the clients’ address spaces, we have at least two options:

1. at a regular interval, iterate over our windows in correct z-order, switch to their respective address space and copy their buffer to the screen
2. when a client tells the WM that its window can be drawn, check if it’s their turn and if so draw them. Otherwise, lose a frame for that window.

With option 1, I don’t know how to avoid drawing a window to the screen when its buffer may be in a “partially drawn” state, plus the method of switching address spaces is pretty barbaric, and I’m sure very slow.

I went for option 2, which I believe the code can explain quite well:

void wm_render_window(uint32_t win_id) {
    wm_window_t* win = wm_get_window(win_id);

    // If it's not our turn, return
    if (win->z != current_z) {
        return;
    }

    // Render the window to the off-screen buffer
    uint32_t* off = (uint32_t*) (fb.address + win->y*fb.pitch + win->x*fb.bpp/8);

    for (uint32_t i = 0; i < win->fb.height; i++) {
        memcpy(off, (void*) (win->fb.address + i*win->fb.pitch), win->fb.pitch);
        off = (uint32_t*) ((uintptr_t) off + fb.pitch);
    }

    // If all windows are drawn, write to the screen
    if (current_z == wm_get_max_z()) {
        current_z = 0;
        fb_render(fb);
    } else {
        current_z++;
    }
}

Apart from dropping draw calls, this method has the downside that a slow client will slow the whole thing down: the WM will wait for its draw call and drop all others in the mean time.
Good thing SnowflakeOS apps are always lightning fast ;)

The next steps

In no particular order, this is what I want to get to:

• cleaning up the code: these changes brought a lot of mess
• windows need to get keyboard and mouse events
  • a mouse pointer
  • moving windows around
  • porting my “Mandelbrot visualizer” app to SnowflakeOS
• C++ support in userspace
• a GUI system

Long time no C

It’s been a while since the last entry in this blog, but I’m hoping to pick up the pace. I’ve been very busy programming-wise with school projects, but less so now.
One can’t reasonably spend their time writing C#, can they?

Here above you can see keyboard input being written to the screen, and mouse coordinates on the bottom right corner - wait for it.

The PS/2 controller

Source: ps2.c, ps2.h

“PS/2” stands for “Personal System/2” and is the old green or purple round port which fit old keyboards. These ports were linked to the PS/2 “8042” controller, an old chip which, miraculously, still manages to exist in some form in modern computers. Indeed, while PS/2 devices have been replaced by USB ones, the BIOS (most of them anyway) offers an emulation of the 8042 on top of USB. Ideally I’d implement the USB protocol, but this is an OS project, not an USB project, and dealing with PS/2 devices is easy in comparison.

The steps to initialize the PS/2 controller to some base state are numerous and detailed in the relevant section of the wiki page. I’ve implemented them in ps2.c, a ~140 lines function full of hopefully well commented IO. Most of it looks something like this:

// Give the controller a command
ps2_write(PS2_CMD, PS2_WRITE_CONFIG);
// and its associated data byte
ps2_write(PS2_DATA, config);

Where ps2_write(port, byte) is a wrapper around the x86 instruction outb which writes a byte to an IO port. This function also makes sure the controller is ready to receive a byte, and similarly, ps2_read(port) makes sure the controller has sent us a byte.

The outline of the initialization steps is that first, you need to pray that there really is a PS/2 controller to talk to: the correct way to do this is to query the ACPI tables, but hey, QEMU and Bochs are guaranteed to have one. Then, you need to test if there is a second controller (which usually handles the mouse) and run self-tests. The last step is to reset devices plugged into our functionning PS/2 controllers. Finally, we query their identity - keyboard, mice - and start the relevant device drivers.

Implementing the various steps didn’t take me long; but chasing its bugs did. Specifically, a bug that appeared only on QEMU. After initialization of the PS/2 controllers, my keyboard code stopped working. The keyboard simply didn’t send IRQs. And to get the mouse working, at first I needed to disable my keyboard code!
I finally figured it out by looking at the controller’s configuration byte: I was inadvertently setting a bit that disabled the keyboard clock. Somehow Bochs doesn’t care if it’s set when enabling IRQs from devices, it just unsets it, however QEMU doesn’t let it fly.

A PS/2 mouse driver

I’ve had weird crashes implementing this. This happened when I moved my mouse to the left in Bochs!

Source: mouse.c, mouse.h

First, one needs to enable reporting from the mouse, it then starts sending out IRQs on line 12. Each IRQ corresponds to a byte available for reading from the PS/2 controller’s data port, 0x60. The bytes must be treated in packets of three to four depending on the type of mouse we detected, or features we enabled. The bytes are sent in this order:

• flags: direction of the x and y movements, state of mice buttons, others…
• x movement
• y movement

and if there is a fourth byte, it contains scroll wheel movements and the state of buttons four and five of the mouse. Here’s the code receiving the bytes:

void mouse_handle_interrupt(registers_t* regs) {
    UNUSED(regs);

    uint8_t byte = ps2_read(PS2_DATA);

    // Try to stay synchronized by discarding obviously out of place bytes
    if (current_byte == 0 && !(byte & MOUSE_ALWAYS_SET)) {
        return;
    }

    packet[current_byte] = byte;
    current_byte = (current_byte + 1) % bytes_per_packet;

    // We've received a full packet
    if (current_byte == 0) {
        mouse_handle_packet();
    }
}

All we need to do then in mouse_handle_packet is keeping track of the mouse movements, and at a later time, making them available to userspace. Then, and only then, we’ll get a mouse pointer.

A better PS/2 keyboard driver

Source: kbd.c, kbd.h

Now that I was initializing the PS/2 controller instead of letting it do its thing, my driver was working all funky. The reason lies in scan code sets.

First things first, a scan code is one or more bytes sent by the keyboard when a key event happens. For instance, pressing ‘D’ on my keyboard may send 0x23, and releasing it may send 0xF0 followed by 0x23. Some keys - in some scan code sets - send up to 8 bytes!

Now, a scan code set is the map between a physical key and the bytes the keyboard sends, and there are basically 3 of them. The previous example was true for scan code set 2; in scan code set 1, pressing ‘D’ would have caused the keyboard to send 0x20, and releasing it would have given 0xA0.

When I did zero PS/2 controller initialization, my keyboard defaulted to scan code set 1, with a twist: scan code translation, i.e. the controller converting scan codes to old IBM-PC compatible scan codes. This scan code set and weird translation mechanism are too vintage even for SnowflakeOS; it was time to handle scan code set 2.

In this shiny new 1983 scan code set, things are a bit more complicated than with scan code set 1. There are two categories of keys:
There are the simple keys, which send a one-byte scan code when pressed, and 0xF0 followed by that same scan code when released.
Then there are the other keys, which send multibyte scan codes. They can be identified as they send an 0xE0 byte first, followed by a 0xF0 byte in case of a release event, followed by one or more bytes of scan code.

Now keep in mind that we receive bytes one at a time in our interrupt handler, so we need to keep track of previously received bytes until we’ve identified a whole key event, and the difficulty is in the variable length of such packets. Obviously, what we need is some kind of state machine and a buffer to hold our bytes. Here’s the function in kbd.c in charge of updating the state of the driver’s state machine:

bool kbd_process_byte(kbd_context_t* ctx, uint8_t sc, kbd_event_t* event) {
    ctx->scancode[ctx->current++] = sc;
    uint32_t sc_pos = ctx->current - 1;

    switch (ctx->state) {
        case KBD_NORMAL: // Not in the middle of a scancode
            event->pressed = true;

            if (sc == 0xF0) {
                ctx->state = KBD_RELEASE_SHORT;
            } else if (sc == 0xE0 || sc == 0xE1) {
                ctx->state = KBD_CONTINUE;
            } else {
                ctx->current = 0;
                event->key_code = simple_sc_to_kc[sc];
            }

            break;
        case KBD_RELEASE_SHORT: // We received `0xF0` previously
            ctx->state = KBD_NORMAL;
            ctx->current = 0;
            event->key_code = simple_sc_to_kc[sc];
            event->pressed = false;

            break;
        case KBD_CONTINUE: // We received `0xE0` at some point before
            if (sc == 0xF0 && sc_pos == 1) {
                event->pressed = false;
                break;
            }

            if (kbd_is_valid_scancode(&ctx->scancode[1], sc_pos, &event->key_code)) {
                ctx->state = KBD_NORMAL;
                ctx->current = 0;
            }

            break;
    }

    return ctx->state == KBD_NORMAL;
}

It’s quite a big function, and still most of the heavy lifting is done in kbd_is_valid_scancode(bytes, len, &key_code), in charge of identifying valid multibyte scancodes and translating those into key codes. Our kbd_process_byte function indicates that a valid scan code has been received by returning true, and makes the key event available through its event parameter.
If you’re really paying attention, you may notice a possible buffer overflow with ctx->scancode[ctx->current++], but thankfully kbd_is_valid_scancode is guaranteed to return true before that… Hmm, this is a bit too clunky, perhaps I’ll put a proper check back in just in case I ever modify kbd_is_valid_scancode’s interface in the future.

Anyway, SnowflakeOS can now handle a full QWERTY layout. This is a bit dumb as I myself have a French, AZERTY layout; let’s just say I’m being international :)
Ideally I’d move most of the keycode translation stuff to userspace where a keymap could be loaded, and there’d be no more problems.

Context switching

I noticed that issue and at first decided to tackle it my own way, moving the contents of my registers_t structure to the corresponding registers, but it proved a bit difficult. It would have been doable with more thought, but instead I searched the internet for the “usual” way to restore context.

It turns out there’s a very elegant way to do it: instead of using iret everytime, simply switch stack and let the execution get back to the interrupt handler by just letting execution reach the end of the function.
This works because the stack state of every interrupted process is the same when getting to the stack-switching part of execution: what we do is simply pop registers from the next process’s stack, not the one that was last interrupted.
For now the subroutine is implemented in assembly as I mainly copied it from a wiki page but I should be able to turn it into C no problem, contrary to what the page says. Here’s the current code:

proc_switch_process: # void proc_switch_process();
    # Save register state
    push %ebx
    push %esi
    push %edi
    push %ebp

    # current_process->esp = %esp
    mov current_process, %eax
    mov %esp, 24(%eax)

    # %eax = current_process = current_process->next
    mov (%eax), %eax
    mov %eax, current_process

    # Set esp0 to the next process's kernel stack in the TSS
    push %eax
    push 20(%eax) # kernel_stack
    call gdt_set_kernel_stack
    add $4, %esp
    pop %eax

    # Switch to the next process's kernel stack
    mov 24(%eax), %esp

    # Switch page directory
    mov 16(%eax), %ebx # directory
    mov %ebx, %cr3

    # Restore registers from the next process's kernel stack
    pop %ebp
    pop %edi
    pop %esi
    pop %ebx

    ret

That leaves the problem of how to switch to tasks which haven’t been started yet, and thus haven’t had the chance to be interrupted: we can’t switch to their kernel stack to restore the process’s context, there’s nothing there. I haven’t thought this through, but I don’t think we can iret manually a second time, we’d mess up the kernel stack of the currently executing process.
I opted for the solution of setting up that stack manually in proc_run_code. It’s ugly (see for yourselves), but hey, it works. I’ll make something nicer at some point, I haven’t researched how it’s usually done.

Implementing preemptive multitasking, i.e. interrupting and resuming tasks without asking them was then simply a matter of calling proc_switch_context from my timer interrupt handler.

If you look at the commit implementing all this, here, you’ll notice that I’m not calling iret when first entering usermode. And yet the code seemed to work, and it in fact sort of did! By a miracle of chance, the ret instruction for the function proc_enter_usermode popped the pushed eip = 0 from my inline assembly, thereby calling my process code. Of course with a simple ret the execution was still in ring 0, but on subsequent switches, everything was as right as ever.

Ongoing code documentation

Understanding and debugging that new context-switching method took me quite a while and led me to improve my interrupt code. It’s now pretty well documented, see for instance isr.S or gdt.h. I had several misunderstandings in that area of the code, notably differences between ISRs and IRQs, their relation with the IDT and the GDT… Now it’s all good.

Quick explanation. The IDT is a table that stores pointers to interrupt handlers along with details like which code segment to use when switching execution to the handler, etc… ISRs are one type of interrupts, numbered from 0 to 32 and also called “exceptions”, and IRQs are another, numbered from 32 to 47, also called “hardware exceptions”. The GDT describes memory segments referred to in the IDT.
It’s interesting to note that the IDT and GDT have very similar structures, and that both are particularly horrid. For instance, the address of the start of a memory segment is split into three non-contiguous parts in a GDT entry: two of 8 bits and one of 16. Crazy stuff.

Rebuilding the build system

SnowflakeOS $ time make SnowflakeOS.iso
[...]
real 0m1,140s
user 0m0,733s
sys  0m0,347s

With such progess in my userland, I now had to have a straightforward way of building programs. At first I hacked my libc’s Makefile to build C programs and link them with libc. I don’t know exactly what was wrong, but I couldn’t get GCC to compile them to flat binaries. I then looked into making an ELF loader, but it looked difficult to get right. Then I decided it was time to simplify my build system and do things correctly.

I replaced my interdependent shell scripts with a simple Makefile combining all of their functionalities. It would now be pretty easy to automate the whole cross-compiler toolchain building phase in there too.
The build process is still fundamentaly the exact same: first headers are copied to a fakeroot environment, then code is compiled per-project (a project being the kernel, the libc and modules, for now) using the system headers from the fakeroot directory.
There’s a slight problem as this Makefile relies on the order of compilation of projects which isn’t specified very strictly, so running make -j (parallel compilation) will cause errors.

After that, I managed to get module compilation in working order.

Userland programs as GRUB modules

Notice the “Hello, C world” line on here? That’s a usermode process calling my libc’s printf implementation, which itself uses my putchar system call to print characters:

int putchar(int c) {
#ifdef _KERNEL_
    term_putchar(c);
#else
    asm (
        "mov $3, %%eax\n"
        "mov %[c], %%ebx\n"
        "int $0x30\n"
        :
        : [c] "r" (c)
        : "%eax"
    );
#endif
    return c;
}

At the bottom right of the screenshot is the currently executing process. Also, notice how I sneakily increased the version number when writing this article :)

There’s one peculiar thing at play here worth noting: I thought it good to follow the advice from here, to have an assembly prologue to call main in my C programs and to call exit with main’s return value. And to push main’s arguments too, in the future. But I couldn’t get GCC to put my prologue code at the entry point: it always, always places a call to main as the first instruction, then a few nops, and only then my prologue, which of course is more of an epilogue at this point.
It’s enough to call exit, and I guess if I really want my argc and argv I’ll set up the process stack myself, I’ve done that before ;)