Weiterentwicklung von PrettyOS

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.

Mr X schrieb:

Codestil oder Sprachstandards (Siehe anderer Thread)

Was für ein Quatsch.

Als ich hier - berechtigte - Zweifel an C99 angemeldet habe, hat man mich wohl als Troll missverstanden und kommentarlos meine Beiträge gelöscht.

Das war auch bei den anderen Thread so, in dem ich die Stdlib von Pretty OS kritisiert habe.

Anscheinend sind ernstgemeinte Ratschläge hier gänzlich unerwünscht.

Das Problem an eurem "Coding-Style" ist, dass ...

/* Solche Kommentare */ unerwünscht sind. Das ist ein gewaltiger Lapsus.
2. CamelCase und unter_striche wild gemischt werden -> entweder - oder
3. 0 statt NULL. Schon das lässt, wie ich schon mehrmals im Chat und hier im Forum mitgeteilt habe, tief blicken, wie es mit euren C-Kenntnissen steht (ihr verwechselt wohl C mit C++)

Problem Nr. 3 ist wohl das übelste, weil es eben nur C99 konform ist, und gegen alle anderen Standards geht. 0 ist eben nicht NULL.

Vielleicht hättet ihr C vor C++ lernen sollen. So können solche eklatanten Fehler garnicht passieren.

So jetzt ists raus, euer Coding-Style ist in einigen Punkten nicht standardkonform. Das ist eine schlechte Grundlage.

Ach ja: Nein, dieser Beitrag ist kein Troll-Beitrag. Er ist ernstgemeint.
Ihr braucht ihn nicht zu löschen.
Manchmal fühlt man sich hier wie im Kindergarten. Jede Kritik wird beleidigt gelöscht.

Jonas OSDever

coding-style verbessern! schrieb:

Das Problem an eurem "Coding-Style" ist, dass ...

/* Solche Kommentare */ unerwünscht sind. Das ist ein gewaltiger Lapsus.
2. CamelCase und unter_striche wild gemischt werden -> entweder - oder
3. 0 statt NULL. Schon das lässt, wie ich schon mehrmals im Chat und hier im Forum mitgeteilt habe, tief blicken, wie es mit euren C-Kenntnissen steht (ihr verwechselt wohl C mit C++)

Problem Nr. 3 ist wohl das übelste, weil es eben nur C99 konform ist, und gegen alle anderen Standards geht. 0 ist eben nicht NULL.

Zu 1: Ob man nun diese Form der Kommentare bevorzugt oder nicht ist wohl jedem selbst ueberlassen. Die meisten Kommentare sind nunmal einzeilig, und da reicht durchaus ein // - zumindest in C99. Und auch wenn du es nicht magst, benutzen wir C99. Ist halt so. Da nachtraeglich was zu aendern waere sinnlos.

Zu 2: Du verstehst den Sinn dahinter wohl nicht. camelCase ist die allgemeine Bezeichnungsregel fuer die Funktionen und Variablen. Die underscores sind nur fuer "Namespaces" vorgesehen. Alle HDD-Funktionen beispielsweise, die als Interface gedacht sind, beginnen dann halt mit hdd_.

Zu 3: Es kompiliert und fertig. Und es ist auch C89-konform, unabhaengig davon, was dein GCC meckert. 0 ist eine standardkonforme Nullpointer constant, da kannst du drehen und wenden, was du willst. Steht gleichermassen in C89 und C99. Und selbst wenn es nur in C99 stuende, wuerde das nichts aendern. Nur weil du kein C99 magst, heisst das nicht, dass es keine Leute geben kann, die es moegen. Wir - besser gesagt die, die schon eher dabei waren, ich bin ja erst dazugestossen - haben uns/haben sich nunmal fuer C99 entschieden und das wird sich auf absehbare Zeit nicht aendern. Und wenn es sich aendert, dann sicher nicht zu C89 zurueck. Eher noch zu C++.

BTW, deine Beitraege wurden nicht geloescht, oder du meinst nicht die, an die ich denke. Erhard (?) hats nur rausgesplittet, weils mit dem Styleguide weniger zu tun hatte. http://www.c-plusplus.net/forum/315527-full