Thema: Übertreibung(en)

[erik.vikinger]

Hallo,


im Kernel würde ich definitiv nicht auf brk/sbrk setzen, schon weil der Kernel-Space ja über alle Prozesse geshared wird und man dort doch auch etwas zusätzliche Flexibilität beim Einbinden von z.B. MMIO-Adressräumen benötigt. Hier würde ich einen passenden Mapping-Mechanismus bevorzugen.

Für innerhalb des Kernels sollte man sich meiner Meinung nach auch die Mühe machen die Heap-Verwaltung selber zu implementieren (wobei natürlich nichts gegen gute Inspirationsquellen spricht) schon damit man da nicht eine Black-Box drin hat.


Grüße
Erik

[kevin]

Und konsequenterweise in Assembler.

(Wer Ironie findet, darf sie behalten)

[erik.vikinger]

Hallo,

Und konsequenterweise in Assembler.

Gewiss doch.
Auch wenn der Titel dieses Threads etwas anderes suggeriert so ist es doch mit Sicherheit keine Übertreibung das OS-Dev eine der Königsdisziplinen (wenn nicht gar die Königsdisziplin) in der Softwareentwicklung ist. Sowas ist selbstverständlich nur echten Hardcore-SW-Cracks zuzutrauen.


Grüße
Erik


(wer hier Ironie findet, bekommt mehr raus als reingesteckt wurde)

[LittleFox]

Ah, OK, danke für die Info
Dann werde ich versuchen eine mmap emulation zu schreiben
Ein eigenes malloc() kommt vielleicht später - erstmal soll es funktionieren

[erik.vikinger]

Hallo,

**** kommt vielleicht später - erstmal soll es funktionieren

Solche Pläne gehen nur extrem selten gut. Diese erste Schnellschusslösung bleibt dann doch länger drin als geplant (sie funktioniert ja erst mal) fällt einem dann später aber um so kräftiger auf die Füße weil es eben nur eine Schnellschusslösung ist in der z.B. korrektes Fehlerhandling fehlt oder weil sie einfach nicht wirklich zum restlichen System passt.

Klar kann man sich in seinen Kernel fremden Code holen, und klar kann das auch erstmal funktionieren, aber wenn der Code einfach unter anderen Gesichtspunkten als das eigene Projekt entwickelt worden ist wird es mit hoher Wahrscheinlichkeit früher oder später kräftig krachen. Mag sein das es auf den ersten Blick so aussieht als käme man damit schneller zum Ziel, man hat ja eher etwas mit dem man schon mal was machen kann, aber das eigentliche Ziel erreicht man mit diesem Weg meistens erst später weil man um eine passende Lösung oft trotzdem nicht drumherum kommt so das man sich mit der Schnellschusslösung eigentlich nur zusätzliche Zwischenarbeit aufhallst.


Grüße
Erik (der unbedingt mal eine schlechte Angewohnheit los werden muss )

[LittleFox]

Moin,

der unbedingt mal eine schlechte Angewohnheit los werden muss

Ja, das ist wahr

Ich hab momentan einfach keine Lust ein eigenes malloc() zu schreiben. Erstmal will ich ein betriebssystem auf die Reihe bringen - und zwar eins das funktioniert.
Mir ist schon klar das eigener Code immer besser ist, aber wozu gibt es dann frei verfügbare implementationen von wasweißichwas? Für eine Ideenstütze würde die Dokumentation dazu eher taugen, da Code meistens ziemlich unleserlich ist (auch wenn er sauber geschrieben ist. Code schreiben ist leicher als Code lesen).
Wenn du mir ein gutes Tutorial gibst wie man ein eigenes malloc() schreibt (natürlich mit free(), realloc() und co.) lass ich mich gerne überreden gleich ein eigenes malloc() zu schreiben

Grüße,
LittleFox

[kevin]

Ich gehe davon aus, dass ein fertiges malloc() in der Regel besser ist als das, was man selber schreiben würde. Gerade bei letzterem tendieren die meisten zu deinen Schnellschüssen, und im Gegensatz dazu sind die üblichen verfügbaren Implementierungen gut getestet und haben sich bewährt.

Genauso wie ich es nicht einsehe, eigene Stringfunktionen zu bauen. Ich weiß, wie es theoretisch geht, praktisch baue ich aber eh nur zusätzliche Fehler rein und die verfügbaren Implementierungen passen überall rein, ohne mir was aufzuzwingen.

[LittleFox]

Juhuu - endlich jemand der mir zustimmt

[erik.vikinger]

Hallo,

Ich gehe davon aus, dass ein fertiges malloc() in der Regel besser ist als das, was man selber schreiben würde.

Hm, also wenn Du das so siehst dann habe ich dem nichts mehr entgegenzusetzen. Da ist es dann auch völlig unerheblich ob das fremde malloc z.B ins eigene Locking-System passt oder reentrant ist oder .....


Grüße
Erik

[kevin]

Lass mich raten: LF-OS hat kein SMP und IRQs sind im Kernel maskiert. Locking wird also nicht berücksichtigt, egal ob was portiert oder was eigenes geschrieben wird.

[LittleFox]

Das trifft es ganz gut, bis auf das '-' im Namen stimmt alles