Weiterentwicklung von PrettyOS

Erhard Henkes

PrettyOS hat nun einen brauchbaren Stand erreicht, deutlich mehr als ich mir in der Anfangszeit vorstellen konnte. Nun stellt sich die Frage, wie man weiter vorgehen sollte.
Welche Features sollten zugefügt, erweitert werden?
Wie könnte die Community besser kommunizieren und/oder zusammenarbeiten?
Welche Partnerschaften mit anderen OS-Developern sollte man anstreben?
etc.

Lasst euren Ideen und Wünschen freien Lauf.

Kellerautomat

Features:

Multicore Support
Async IO
Kooperatives Multitasking

Code:

Tabs zum Einruecken
C++

Weiteres, so mir noch was einfaellt...

Mr X

Features:
•Multicore Support

Ja, ohne Frage eine interessante Sache. Dazu braucht es zunächst mal APIC-Unterstützung, die noch fehlt (bereits angefangen, wollte aber bislang nicht funktionieren). Wenn Du da Ideen oder gar konkreten Code hast, wie wir das lauffähig kriegen - gerne

•Kooperatives Multitasking

Meinst du damit, die optionale Möglichkeit, Rechenzeit abzugeben, oder tatsächlich eine komplette Abschaffung des präemptiven Schedulers? Letzteres ist eher kontraproduktiv, da gerade die Einführung präemptiven Multitaskings historisch ein Fortschritt in Bezug auf die Reaktionsfähigkeit des Systems darstellte.

•Tabs zum Einruecken

Da hat jeder seine Vorlieben. Ich bevorzuge zwar auch Tabs, aber: Es zu ändern wäre bescheuert, dann käme der nächste, der lieber Leerzeichen mag und will es wieder zurückändern. Wenn man einmal einen Stil gewählt hat, sollte man ihn nicht wieder umwerfen. Mal davon abgesehen, dass solche großflächigen Stiländerungen Funktionen wie svn-blame nutzlos machen (bzw. schwächen).

•C++

Im Userspace bereits möglich - im Kernel m.E. nach auch sinnvoll. Wenn ich von vorne anfangen würde, würde ich C++ nehmen. Allerdings auch wieder die Frage, ob eine nachträgliche Änderung in einem bereits so fortgeschrittenen Stadium sinnvoll ist...

Wie wäre es mit einer GUI?
Oder ist das Projekt dafür noch in einem zu frühen Stadium?

Kellerautomat

Mr X schrieb:

Features:
•Multicore Support

Ja, ohne Frage eine interessante Sache. Dazu braucht es zunächst mal APIC-Unterstützung, die noch fehlt (bereits angefangen, wollte aber bislang nicht funktionieren). Wenn Du da Ideen oder gar konkreten Code hast, wie wir das lauffähig kriegen - gerne

Leider nein.

Mr X schrieb:

•Kooperatives Multitasking

Meinst du damit, die optionale Möglichkeit, Rechenzeit abzugeben, oder tatsächlich eine komplette Abschaffung des präemptiven Schedulers? Letzteres ist eher kontraproduktiv, da gerade die Einführung präemptiven Multitaskings historisch ein Fortschritt in Bezug auf die Reaktionsfähigkeit des Systems darstellte.

Nein. Sowas wie POSIX ucontext.h. http://pubs.opengroup.org/onlinepubs/009695399/basedefs/ucontext.h.html

Mr X schrieb:

•Tabs zum Einruecken

Da hat jeder seine Vorlieben. Ich bevorzuge zwar auch Tabs, aber: Es zu ändern wäre bescheuert, dann käme der nächste, der lieber Leerzeichen mag und will es wieder zurückändern. Wenn man einmal einen Stil gewählt hat, sollte man ihn nicht wieder umwerfen. Mal davon abgesehen, dass solche großflächigen Stiländerungen Funktionen wie svn-blame nutzlos machen (bzw. schwächen).

Das hat mit Vorlieben nichts zu tun. Wer Spaces benutzt, versteht den Unterschied zwischen Ausrichten und Einruecken nicht. Tabs zum Einruecken, Spaces zum Ausrichten.

Mr X schrieb:

•C++

Im Userspace bereits möglich - im Kernel m.E. nach auch sinnvoll. Wenn ich von vorne anfangen würde, würde ich C++ nehmen. Allerdings auch wieder die Frage, ob eine nachträgliche Änderung in einem bereits so fortgeschrittenen Stadium sinnvoll ist...

Habt ihr schon mal versucht, den Kernel durch einen C++ Compiler zu jagen?

Mr X

Habt ihr schon mal versucht, den Kernel durch einen C++ Compiler zu jagen?

Ich habe es ganz am Anfang mal versucht. Hatte endlos viele Type-Cast-Fehlermeldungen zur Folge, die alle nachzurüsten ist eine endlose (und ziemlich nutzlose) Sache - außer man hat explizit das Ziel, zu C++ zu wechseln.

Erhard Henkes

Wir haben das Thema C vs. C++ in 2009 diskutiert. Ihr könnt die Entwicklung nachlesen in dem "geschichtlichen" Thread, den ich als eine Art Logbuch mitführe. Damals war der Ratschlag eindeutig Richtung C. Ich denke, für Einsteiger ist es etwas leichter les- und bearbeitbar.

wie wäre es, als Lern - OS alles etwas mehr zu dokumentieren?

Letztlich wird das OS immer komplexer, und es werden sich wohl kaum neue Leute finden, weil keiner Lust hat, sich wochenlang erstmal durch den Source zu quälen, um zu verstehen, wie was gelöst wurde.

Erhard Henkes

sadasdd schrieb:

wie wäre es, als Lern - OS alles etwas mehr zu dokumentieren?

Völlig richtig. Es gibt bereits Anfänge, z.B. die Beschreibung von Paging und Heap: http://www.c-plusplus.net/forum/261588-4
(Werte sind nicht mehr aktuell, das müsste man aktualisieren, aber Prinzip gilt noch)
Was wir bisher nicht wollten: Unmengen an Kommentaren im Code, vor allem vor Funktionen.
Ich denke ein Anfang könnte ein Doku-Thread sein, in dem die einzelnen Module in ihrer Wirkungsweise mit Links auf entsprechende Grundlagen, falls vorhanden, beschrieben sind.

Es gibt auch eine Ressourcen-Linkliste für OSDev von mir:
http://henkessoft.de/OS_Dev/OSDEV Ressourcen.html

Erhard Henkes schrieb:

sadasdd schrieb:

wie wäre es, als Lern - OS alles etwas mehr zu dokumentieren?

Völlig richtig. Es gibt bereits Anfänge, z.B. die Beschreibung von Paging und Heap: http://www.c-plusplus.net/forum/261588-4
(Werte sind nicht mehr aktuell, das müsste man aktualisieren, aber Prinzip gilt noch)
Was wir bisher nicht wollten: Unmengen an Kommentaren im Code, vor allem vor Funktionen.
Ich denke ein Anfang könnte ein Doku-Thread sein, in dem die einzelnen Module in ihrer Wirkungsweise mit Links auf entsprechende Grundlagen, falls vorhanden, beschrieben sind.

Es gibt auch eine Ressourcen-Linkliste für OSDev von mir:
http://henkessoft.de/OS_Dev/OSDEV Ressourcen.html

ich kenn es eh, wenn ich entwickle hab ich meist recht wenig lust darüber eine doku zu schreiben. schliesslich kann man die zeit sinnvoller nutzen - z.b. zum programmieren
trotzdem wäre gerade das hier ein thema, wo doku sehr wichtig ist!
wenn jemand etwas implementiert, reicht es ja, ein paar worte darüber zu verlieren - z.b. eben in einem thread hier im forum. dinge wie memory management, prozess management, interrupts, u.ä. sind nämlich nicht unbedingt selbsterklärend. sprich: es reicht nicht, den source durchzulesen, nein, man muss auch die dahinterliegende theorie etwas verstehen. andererseits reicht aber bereits wenig text aus, um viele unklarheiten zu beseitigen.

mein tipp: sucht euch eine zentrale stelle für eure doku! denn teile der doku sind auf deiner HP, andere teile mit dem source mitgeliefert, und teilweise verstecken sich auch gute infos in den untiefen des c++ forums.
macht einen eigenen thread auf, in welchem die entwickler kurz stellung nehmen zu ihren entwicklungen. fragen dürfen dann in einem anderen thread gestellt werden, sodass der doku thread nicht zugespamt wird.

Mr X

mein tipp: sucht euch eine zentrale stelle für eure doku! denn teile der doku sind auf deiner HP, andere teile mit dem source mitgeliefert, und teilweise verstecken sich auch gute infos in den untiefen des c++ forums.
macht einen eigenen thread auf, in welchem die entwickler kurz stellung nehmen zu ihren entwicklungen. fragen dürfen dann in einem anderen thread gestellt werden, sodass der doku thread nicht zugespamt wird.

Ich denke, der richtige Platz für weiterführende Dokumentation ist beim Code, aber nicht im Code (zuviel Text). Also im Repository in /documentation.

Erhard Henkes

Also im Repository in /documentation.

Wie wird das gesehen? Ist das ausreichend zugänglich oder muss es direkt im Forum sein?

Mr X

Um das noch etwas weiter zu begründen: Ich halte es für grundfalsch, ein Forum zum Informations-Ablageplatz zu machen, weil es dafür ungeeignet ist. Beiträge verschwinden in der Versenkung oder gehen in einer Fülle von Antworten unter, das liegt in der Natur der Sache. Außerdem kann nur ein Moderator oder man selbst an eigenen Beiträgen rumeditieren, was höchst problematisch ist, da Unsinn so oft auf lange Zeit erhalten bleibt. Ein Forum ist eben eine Diskussionsplatform.

TyRoXx

Erhard Henkes schrieb:

Wie könnte die Community besser kommunizieren und/oder zusammenarbeiten?

Git(hub)

user/user_tools/userlib_cpp.cpp

#if (__GNUC__ >= 4 && __GNUC_MINOR__ >= 7)

Juhu, bei GCC 5.0 kracht es plötzlich.
Es müsste natürlich so heißen:

#if (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 7))

Hat es eigentlich irgendeinen Nutzen, dass viele Dateien mit der Lizenz oben und unten zugemüllt sind?

Kellerautomat schrieb:

Mr X schrieb:

•Tabs zum Einruecken

Da hat jeder seine Vorlieben. Ich bevorzuge zwar auch Tabs, aber: Es zu ändern wäre bescheuert, dann käme der nächste, der lieber Leerzeichen mag und will es wieder zurückändern. Wenn man einmal einen Stil gewählt hat, sollte man ihn nicht wieder umwerfen. Mal davon abgesehen, dass solche großflächigen Stiländerungen Funktionen wie svn-blame nutzlos machen (bzw. schwächen).

Das hat mit Vorlieben nichts zu tun. Wer Spaces benutzt, versteht den Unterschied zwischen Ausrichten und Einruecken nicht. Tabs zum Einruecken, Spaces zum Ausrichten.

Spaces zum Einrücken sollten verboten werden. Allerdings könnte man dann nicht mehr über die kreativen Begründungen lachen.

Alle Achtung übrigens für das Projekt.
Es ist wirklich interessant in einem überschaubaren Betriebssystem zu lesen.
Ich musste auch nur eine Anpassung vornehmen ( size_t für operator new ) zum Kompilieren.

Wie könnte ich denn Änderungen einbringen ohne sofort ein "Mitglied" werden zu müssen?

Erhard Henkes

Wie könnte ich denn Änderungen einbringen ohne sofort ein "Mitglied" werden zu müssen?

Das geht unkompliziert. Änderungsvorschläge an MrX (patch oder anders) senden, er ist regelmäßig im IRC chat zu finden.

Erhard Henkes schrieb:

Wie könnte ich denn Änderungen einbringen ohne sofort ein "Mitglied" werden zu müssen?

Das geht unkompliziert. Änderungsvorschläge an MrX (patch oder anders) senden, er ist regelmäßig im IRC chat zu finden.

Ok. Wie wäre es, wenn man erstmal diese Coderegeln abschafft? Ob ich jetzt Tabs oder Spaces, oder bei jeder geschweiften Klammer auf { eine neue Zeile anfange, ist dem Compiler egal.

Mit solchen Coding-Vorschriften hab ich bisher keine guten Erfahrungen gemacht.

cooky451

Nein, Projekte sollten einen einheitlich Codestil einbehalten.

cooky451 schrieb:

Nein, Projekte sollten einen einheitlich Codestil einbehalten.

du meinst wohl sowas:

char *char_pointer;
if( char_pointer == 0)
{
    // ...
}

mhh?

Mr X

Ok. Wie wäre es, wenn man erstmal diese Coderegeln abschafft? Ob ich jetzt Tabs oder Spaces, oder bei jeder geschweiften Klammer auf { eine neue Zeile anfange, ist dem Compiler egal.

Uns ist es aber nicht egal, und wir wollen unseren eigenen Code noch verstehen können. Und eine einheitliche Formatierung unterstützt bei menschlichen Lesern das Verständnis. Stell dir mal Code vollständig ohne Einrückungen vor...

Und mal generell: Mir ist völlig unverständlich, wieso hier ständig irgendwelche Metadiskussionen über Codestil oder Sprachstandards (Siehe anderer Thread) geführt werden müssen. Die Styleguide ist so festgelegt, wie sie ist, und ohne praktischen Grund werden wir die nicht grundlegend ändern (und abschaffen übrigens auch nicht).

Erhard Henkes

@Subjective-C: Ja, was soll man da sagen? Klar ist Freiheit und Individualität eine feine Sache. Bei einem gemeinsamen Projekt ergeben klare Regeln jedoch Sinn, ansonsten haben wir ständig überflüssige Diskussionen und Korrekturen von A nach B während des Projektes, und keiner hat recht. Hier besitzen leider Praktikabilität und Frieden im Team höhere Priorität als die individuelle Gestaltungsfreiheit. Aus dem gleichen Grund gibt es wohl auch Werkrichtlinien, Haus- und Schulordnungen. Hier werden wir nicht nachgeben.