Nachrichten

1221

OS-Design / Re: Shared IRQs bei Micro-Kernel-OS

« am: 21. October 2009, 21:28 »

Hallo,

Explizites Designziel war es nicht, als ich das letzte Mal nachgeschaut habe.

Schon klar. Aus meiner Berufspraxis muss ich aber ganz ehrlich sagen das es besser ist sich erst mal mit mehreren Kollegen zusammen setzt und alle möglichen Lösungen diskutiert bis man sich auf die beste Lösung geeinigt hat, unter Berücksichtigung aller relevanten Erfordernisse zu dehnen natürlich auch eine bestimmte Deadline gehören kann die mit einer ordentlichen/besseren Lösung nicht haltbar ist. In privaten Projekten sollten aber Deadlines nicht so wichtig sein so das man auch manches etwas besser machen kann.
Wenn ich über die letzten 10 Jahre die Qualität meiner Projekte analysiere dann komme ich ganz klar zu dem Ergebnis das meine privaten Hobby-Projekte durchweg besserer Qualität sind, woran der Termindruck im Berufsleben natürlich einem erheblichen Anteil hat.

Dann wird eben gequeuet. Und weiter? Ist doch nicht schlimm?

Ist natürlich nicht schlimm. Auf SW-Ebene sollte das keine ernsten Probleme bereiten, trotzdem betrachte ich das als Fehler im Device der natürlich behoben werden sollte.

Für mein Projekt bedeutet dass das ich auf jeden Fall erst mal shared IRQs und die alten level triggered Signale verbieten werde und falls ich doch mal in die Not komme das zu unterstützen kann ich dann ein extra Device implementieren das diese alten IRQ-Signale entgegen nimmt und sie per MSI an den richtigen IRQ-Controller weiterleitet. Der zugehörige Treiber verteilt dann die IRQs auf alle angemeldeten Device-Treiber und liefert am Schluss das EOI an das extra Device. Ist zwar ne blöde Lösung aber ich denke sie wird nur die USB-Controller treffen alles andere kann üblicherweise MSI.


Grüße
Erik

1222

OS-Design / Re: Shared IRQs bei Micro-Kernel-OS

« am: 21. October 2009, 11:21 »

Hallo,

tyndur kann im Moment keine Interrupts sharen.

Dann unterstützt Ihr wohl auch noch nicht allzu viele Hardware-Komponenten? Insbesondere die vielen Onboard-Controller (x-mal USB 1/USB 2/(S)ATA usw.) moderner Mainboards leben ja exzessiv vom IRQ-Sharing.

dass in typischer tyndur-Manier die einfachste Möglichkeit gewählt wird

Ist das Desing-Ziel? Da habe ich wirklich etwas Ehrfurcht wie weit Ihr damit gekommen seit. 

Ohne EOI kriegst du ja auch keine anderen Interrupts mehr. Ihn nicht sofort zu senden, wäre also nicht so schlau.

ACK
Daher möchte ich auf meiner Plattform jeden IRQ individuell behandeln und das zugehörige EOI sofort senden (in Hardware) sobald der generische IRQ-Handler vom OS losläuft, dann könnte nämlich sofort der nächste IRQ auf einer anderen CPU abgearbeitet werden (der generische IRQ-Handler vom OS soll "reentrant" sein).
Doof währe nur wenn ein Device wiederholt MSI-Messages sendet und der IRQ-Controller mehrmals den IRQ-Handler vom OS aufruft bevor der eigentliche IRQ-Signal-Handler vom Device-Treiber dran kommt, der stünde dann mehrmals in der Signal-Handler-Queue (aber so schlimm ist das bestimmt nicht).


Grüße
Erik

1223

OS-Design / Re: Shared IRQs bei Micro-Kernel-OS

« am: 20. October 2009, 19:38 »

Hallo,

Okay, das läuft also unter Kombination von "im Kernel" und "alle Treiber benachrichtigen".

Ja, nur das "alle" erstmal auf möglichst klein getrimmt wird und der eigentliche (nachgelagerte) Handler etwas später kommt. Von der Latenz her denke ich das eine Message zu einem schlafenden Handler-Thread in einem Micro-Kernel-OS nicht schlechter ist als das Zeugs von Windows. In Linux soll man das, meines Wissens nach, ähnlich machen aber es wird wohl nicht so strickt durchgesetzt. Man merkt dem Linux-Kernel auch in diesem Zusammenhang an das er oft in verschiedene Richtungen gewachsen ist.
Aber genau das (vor allem "im Kernel") geht bei einem echten Micro-Kernel nicht und daher möchte ich wissen wie ihr das nun gelöst habt, z.B. bei tyndur oder lightOS.

Hm, den EOI will man vermutlich so früh wie möglich schicken.

Ich hab noch mal nachgesehen, in den Windows-Driver-Design-Rules steht das der vorgelagerte IRQ-Handler den Zustand vom Device abspeichern soll (in einer passenden Datenstruktur auf die auch der DPC-Handler zugreifen kann) und dann das Interrupt-Signal im Device abschalten muss. Ich gehe davon aus das EOI am Ende vom generischen IRQ-Handler von Windows kommt. Abgearbeitet wird der Event vom Device dann vom DPC-Handler der sich die nötigen Infos aus der Datenstruktur holt. Dabei muss man aufpassen das der kleine IRQ-Handler nichts überschreibt was der große DPC-Handler eventuell braucht da der DPC-Handler ja durch den IRQ-Handler unterbrochen werden kann. Also ich persönlich empfinde dieses Konzept recht umständlich (mit shared und level triggered IRQs gehts eben nicht besser) und will daher auf meiner Plattform was grundlegend anderes (hoffentlich auch besseres). In der PCI-Spec wird ja auch ausdrücklich MSI bzw. MSI-X empfohlen und von dessen Vorteilen geschwärmt.


Grüße
Erik

1224

OS-Design / Re: Shared IRQs bei Micro-Kernel-OS

« am: 20. October 2009, 08:53 »

Hallo,


In Windows und Linux soll/muss der Device-Treiber einen kleinen IRQ-Handler registrieren der prüft ob tatsächlich die eigene Hardware den Interrupt ausgelöst hat und das zurückmeldet. In den Design-Rules steht das dieser Handler wirklich nur ganz kurz die CPU belasten darf da er ja wirklich vom echten IRQ-Handler des OS aufgerufen wird. Der IRQ-Handler vom OS trägt jede positive Antwort, was durchaus mehrere pro IRQ sein können, in eine Liste ein die dann später in einem anderen Kontext abgearbeitet wird, unter Windows heißt das "Deferred-Procedure-Call". Das hat den Vorteil das der eigentliche IRQ-Handler vom Device-Treiber dann auch einige OS-Funktionen nutzen kann und sogar, um auf etwas zu warten, kurz pausieren kann. Unter Linux macht man das üblicherweise mit Kernel-Threads die dann vom kleinen vorgelagerten IRQ-Handler aufgeweckt werden. Das alles erfordert natürlich einen Monolithischen Kernel und wie das dann mit dem EOI funktioniert weis ich jetzt im Moment auch nicht mehr so genau (ist schon etwas her wo ich das letzte mal Treiber programmiert hatte).

Daher die Frage wie ihr das mit Micro-Kernel macht.


Grüße
Erik

1225

OS-Design / Re: Kleine Designfragen

« am: 20. October 2009, 08:35 »

Hallo,


Der Vorschlag von PorkChicken ist IMHO gar nicht so praxisfern. Windows macht das, meines Wissens nach, so ähnlich aber dort gibt es zusätzlich eine kleine "Fährnis-Police" um Prozesse mit niedriger Priorität nicht ganz verhungern zu lassen.

Ich hatte mal ein kooperatives Multithreading implementiert und dort wurde die nächsthöhere Priorität 1,5 mal so oft aufgerufen. Wie lang die "Zeitscheibe" dann ist hat natürlich der Thread selber bestimmt (er musste ja die CPU aktiv abgeben) aber in einem geschlossenen System wo man nicht mit bösen Programmierern rechnen muss ist das OKay. Ich hab für jede Priorität eine eigene Round-Robin-List angelegt und mit einem kleinen Algorithmus, der die Wichtigkeit einer Liste mit der Anzahl der enthaltenen Threads multipliziert hat, ermittelt aus welcher Liste als nächstes jemand dran kommt. Damit bin ich eigentlich ganz gut gefahren.

Wenn man was besseres haben möchte: der Scheduler im Linux-Kernel ist, meines Wissens nach, austauschbar und hat eine definierte Schnittstelle. Es gibt da mehrere unterschiedliche Implementierungen von dehnen man in seinen Linux-Kernel eine einbinden kann. Falls die Schnittstelle nicht zu komplex ist könnte das eine einfache Methode sein um von der harten Arbeit anderer zu profitieren , ein wirklich guter Scheduler ist keine einfache Angelegenheit.


Grüße
Erik

1226

OS-Design / Re: Shared IRQs bei Micro-Kernel-OS

« am: 19. October 2009, 19:31 »

Hallo,

Der Vorschlag hat auch den Hintergrund, dass PCI m.E. mit ACPI relativ eng zusammenarbeiten muss, falls man das mal implementiert.

Ich finde eher ACPI bezieht sich sehr stark auf PCI, für Power-Management u.ä. gibt es ja entsprechende Capabilities im PCI-Config-Space. Wenn ich die ganze Device-Enumeration (und bei PCI-Express auch die Link-Konfiguration) eh komplett selber im OS machen muss (BIOS o.ä. gibt es auf meiner Plattform nicht), schon allein dafür wird es auf jeden Fall einen PCI-Treiber geben müssen, dann ziehe ich aus ACPI, was ich ja zusätzlich selber implementieren müsste, keinen großen Nutzen mehr. Ich nehme an Du beziehst Dich auf die normale PC-Plattform.

Trotz allem habe ich irgendwie Bauchweh bei dem Gedanken daran so umfangreiche Teile (die nicht wirklich was mit OS zu tun haben) in den Kernel zu verlagern, also wenn dann wird es auf einer der beiden Lösungen von taljeth hinauslaufen. Und für die klassischen PCI-Interrupt-Signale werde ich wohl einen zusätzlichen IRQ-Controller basteln müssen der dem richtigen IRQ-Controller dann per MSI meldet und von seinem SW-IRQ-Handler, in einem extra Treiber, das EOI zum richtigen Zeitpunkt bekommt. Mal schauen wie viel Aufwand das eigentlich wird, einen IRQ-Verteilungstreiber an den sich die Device-Treiber von Devices die kein MSI können anmelden sollte nicht so das Ding werden. Seht ihr da irgendwelche Denkfehler in diesem Konzept?

Zumindest wird der PCI-Treiber sinnvoll erstmal über ACPI initialisiert (wenn man in den I/O APIC Modus schaltet).

Was meinst Du damit? Was hat der I/O-APIC damit zu tun? Ich habe die ACPI-Spec noch nicht komplett gelesen, bekommt man vom ACPI eine Datenstruktur mit einer Art Device-Baum mit allen Ressourcen-Infos usw. die das BIOS verteilt hat?

Ein Frage hab ich noch :
Wie löst Ihr das Problem der shared IRQs? Mit einem der beiden Vorschläge von taljeth, einer Variante im Kernel oder gar so wie Windows und Linux das machen?


Grüße
Erik

1227

OS-Design / Re: Konzeption und Anfang

« am: 18. October 2009, 18:29 »

Hallo,

Ich dachte einfach an die Grundlagen, was anders ist als mit "normalem" PCI und wie man es benutzen kann.

Dazu gibt es eigentlich nicht viel zu schreiben, wenn das PC-BIOS fertig ist fühlt sich PCI-Express (ebenso wie AGP und Hypertransport) für die SW genau so an wie PCI. Solange Du nicht vorhast die Geräte-Enumeration und -Konfiguration selbst durch zu führen (mal ehrlich wer hier macht das schon) brauchst Du Dich nicht mit der Link-Konfiguration, den erweiterten Bridges und anderen Dingen (die außer den BIOS-Entwicklern niemand interessieren) rumzuschlagen.
Ansonsten sind die Artikel in der Wikipedia gar nicht mal schlecht.


Grüße
Erik

1228

OS-Design / Re: Shared IRQs bei Micro-Kernel-OS

« am: 18. October 2009, 13:17 »

Hallo,

aber sehr mikrokernelig ist der Ansatz nicht.

ACK

Wenn man PCI extern behält, sehe ich nur zwei Lösungen:

Beide Lösungen sind nicht gerade sehr performant, ich möchte schon auf eine möglichst geringe IRQ-Latenz hinarbeiten und auch die Kernel-Funktionen möglichst einfach und schnell halten da diese nicht unterbrochen werden können. Wenn bei der ersten Variante ausgerechnet der richtige Device-Treiber als letztes vom Scheduler aufgerufen wird ist bereits ne menge Zeit vergangen und bei der zweiten Lösung kommt erstmal das langsame abfragen aller in Frage kommenden PCI-Devices im PCI-Handler wofür dieser die Ressource "PCI-Config-Space-Access" allozieren und hinterher wieder freigeben muss. Ich werde aber wohl in jedem Fall eine zusätzliche Ebene einbauen müssen um shared IRQs ordentlich hin zu bekommen oder ich bleibe bei meiner ursprünglichen Idee shared IRQs generell zu verbieten und kann dann eben bestimmte Hardware nicht einsetzen, das betrifft nur leider auch die typischen USB 1 und USB 2 Controller auf die ich eigentlich nur äußerst ungern verzichten würde.

Wann wartet der Interruptcontroller worauf?

Entschuldigt die blöde Frage. Ich hatte ja nicht daran gedacht das der IRQ-Controller das EOI erst nach dem richtigen IRQ-Signal-Handler bekommt, wenn das eigentliche Device seine IRQ-Leitung wieder deaktiviert (ich hoffe das passt für "deassert") haben sollte.
In meiner Plattform möchte ich das eigentlich anders machen. Dort soll der IRQ-Controller per MSI(-X) angetriggert werden, dieser meldet sich dann bei der CPU die holt dann den IRQ ab und führt anschließend den IRQ-Handler aus. Der IRQ wird im IRQ-Controller also quittiert sobald der IRQ-Handler des Kernels losläuft, völlig in Hardware ohne das die SW das selber machen müsste. Da MSI ja nicht level triggered ist sondern auf Messages basiert gibts da keine Probleme und wenn doch mal mehrere Messages kommen bevor die CPU den IRQ abgeholt hat dann ist das auch nicht schlimm. Nur dieses blöde IRQ-Sharing bereitet meiner ansich guten Idee einige Probleme.


Grüße
Erik

1229

Lowlevel-Coding / Re: char nach int umwandeln

« am: 18. October 2009, 12:50 »

Hallo,

Wenn eine Zahl unterhalb 4 eingegeben wird, erscheint überhaupt keine Ausgabe. Bei jeder anderen Zahl erscheint eine wirre Zahlenfolge.

Kann es vielleicht sein das etwas mit der Parameterübergabe beim Funktionsaufruf nicht passt? Ist nur so ne Idee.

... was mich eigentlich noch ratloser macht!

Das ist sehr merkwürdig. Ich schätze da wirst Du nicht drumrum kommen das ganze in kleine Häppchen zu zerlegen und alles einzeln testen bis Du die schuldige Code-Stelle gefunden hast. Hast Du schon mal den Debugger von Bochs probiert? Als erstes solltest Du IMHO probieren das Int-2-String klappt, dafür nimmst Du am besten hartcodierte Int-Werte.

Probiere mal

Code: [Auswählen]

d = *str - '0';gegen

Code: [Auswählen]

d = ((int)(*strr)) & 0x0F;und

Code: [Auswählen]

key[i++] = ((char)rest) + '0';gegen

Code: [Auswählen]

key[i++] = (char)(rest - 0x30);zu ersetzen, eventuell hast Du ein Problem mit dem Zeichensatz.
Ansonsten solltest Du eine Fehlermeldung einbauen wenn 'rest' nicht im Wertebereich 0...9 ist. So in der Art :

Code: [Auswählen]

if ( (rest < 0) || (rest > 9) ) { printf("Error!!"); }
Viel mehr fällt mir momentan auch nicht ein.


Viel Spaß
Erik

1230

Lowlevel-Coding / Re: char nach int umwandeln

« am: 18. October 2009, 10:31 »

Hallo,

aber irgendwie funzts net

Kannst Du das etwas konkreter ausdrücken?
Baue den Code einfach mal in ein normales Programm auf deinem Entwicklungsrechner ein und nimm einen Debugger, vielleicht findest Du dann den Fehler.


Grüße
Erik

1231

OS-Design / Re: Shared IRQs bei Micro-Kernel-OS

« am: 18. October 2009, 10:26 »

Hallo,

Ich würde den PCI-Bustreiber in den Kernel verschieben

Ich bin mir nicht sicher ob das eine gute Idee ist, es klingt eher nach einer Krückenlösung aber machbar sollte es sein.

das müsste irgendwo im Configspace der Devices stehen

Ja, ich glaube auch. Zugriffe auf den Config-Space sind aber recht langsam und müssen immer Atomar ausgeführt werden, es können also nicht mehrere CPUs gleichzeitig diesen einen generischen IRQ-Handler ausführen selbst wenn verschiedene IRQs betroffen sind.


Ein weiteres Problem sehe ich noch:
Wenn Device A einen IRQ auslöst und dieser im IRQ-Controller durch den IRQ-Handler abgehackt ist wartet der IRQ-Controller bis das IRQ-Signal wieder verschwindet. Wenn während dessen Device B, das leider am selben IRQ hängt, ebenfalls einen IRQ signalisiert sieht der IRQ-Controller das nicht das die beiden Signale ja verodert werden.
Wie kommt man aus so einem Deadlock wieder raus?
Mit MSI(-X) gibt es solche Probleme prinzipbedingt erst gar nicht.


Grüße
Erik

1232

OS-Design / Re: Konzeption und Anfang

« am: 18. October 2009, 10:02 »

Hallo,

... kannst du ja vielleicht bei Gelegenheit einen Wikiartikel dazu schreiben?

Kannst Du mal schreiben was Du in so einem Artikel alles drin haben möchtest.

falls du dich mit CDI anfreunden kannst, ...

Das kann ich momentan noch nicht sagen, aber wenn ja dann bekommst Du gerne etwas Code ab.


Grüße
Erik

1233

OS-Design / Shared IRQs bei Micro-Kernel-OS

« am: 18. October 2009, 09:47 »

Hallo,


ich wüste gerne wie man in einem Micro-Kernel-OS mit shared IRQs umgeht.
Wenn ich das richtig verstehe sind in einem Micro-Kernel-OS die Device-Treiber auch nur ganz normale User-Space-Applicationen die den IRQ per RPC oder einem anderen Inter-Process-Comunication-Mechanismus erhalten müssen da sie ja nicht im Kernel-Space laufen. Ich wollte das so implementieren das ein User-Space-Treiber einen Signal-Handler registriert und diesen Signal-Empfänger nicht für andere Programme freigibt sondern einem IRQ zuweißt. Im Kernel gibt es dann einen (nicht mehrere) generischen IRQ-Handler der nachschaut für welchen IRQ er gerade aufgerufen wurde und dann für den entsprechenden Signal-Handler eine Nachricht generiert. Wenn nun aber mehrere physische Geräte sich einen IRQ teilen dann müsste man ja bei jedem IRQ an mehrere Signal-Handler eine entsprechende Nachricht schicken.

Habe ich da irgendwo einen Denkfehler oder wie löst Ihr dieses Problem?

Eigentlich wollte ich auf meiner Plattform shared IRQs generell verbieten und statt dessen konsequent auf MSI/MSI-X in Zusammenarbeit mit einem ordentlichen IRQ-Controller, der 4096 verschiedene IRQs (zumindest theoretisch, man muss es ja nicht vollständig implementieren) verwalten kann, bauen. Aber leider unterstützt nicht jede PCI/PCI-Express-Hardware MSI/MSI-X so das ich eventuell doch gezwungen bin shared IRQs zu unterstützen.


Grüße
Erik

1234

Lowlevel-Coding / Re: char nach int umwandeln

« am: 18. October 2009, 09:00 »

Hallo,

Code: [Auswählen]

int itostr(char* const str, int zahl)
{
    if (zahl == 0)
      { *str = '0'; return 1; } //bei 0 nur "0" zurückgeben

    int i = 0; //String-Länge

    while (zahl > 0) { //Loop solange bis Zahl 0 ist
        const int rest = zahl % 10;
        zahl = zahl / 10;
        str[i++] = ((char)rest) + '0';
    }

    return i; //Länge des Strings zurückgeben
}Da fehlt auch wieder die Behandlung negativer Zahlen aber ansonsten sollte das funktionieren.


Grüße
Erik

1235

Lowlevel-Coding / Re: char nach int umwandeln

« am: 17. October 2009, 20:11 »

Hallo,


"Standard-C-Funktionen" sind in der Standard-C-Bibliothek. Wenn Du die nicht in Deinen Kernel mit reinlinken möchtest, was auch nicht empfehlenswert ist, dann schau Dich mal beim Linux-Kernel um die haben eine abgespeckte Fassung (sscanf unterstützt z.B. keine Gleitkommazahlen) aus der Du bestimmt alles benötigte herrausfiletieren kannst.


Grüße
Erik

1236

Lowlevel-Coding / Re: char nach int umwandeln

« am: 17. October 2009, 19:59 »

Hallo,


wenn Du ein char[] mit z.B. "123" meinst dann ist 'sscanf()' Dein Freund.


Grüße
Erik

1237

Lowlevel-Coding / Re: Verständnis Frage GDT

« am: 17. October 2009, 19:50 »

Hallo,


also jeder Prozess bekommt einen eigenen virtuellen 4GB Adressraum. Dieser Adressraum ist aber erstmal nur eine Art leere Spielwiese für den Prozess, der muss dann pageweise mit echten physischen Speicher gefüllt werden. In diesen 4GB Adressraum ist immer auch der Kernel eingeblendet wofür üblicherweise 1 bis 2 GB vorgesehen sind manchmal aber auch weniger. Die restlichen 2 bis 3 GB Adressraum gehören dem Prozess selber dort ist aber erst mal noch fast alles leer also noch kein physischer Speicher zugeordnet, nur der Programmcode und die Daten direkt aus dem Executable-File sind vom Executable-Loader des OS bereits vorbereitet. Bei einem kleinen Programm kann es durchaus sein das nur wenige Pages bereits mit physischen Speicher gemappt sind also nicht "leer" sind. Der Prozess kann dann zur Laufzeit weiteren Speicher vom OS pageweise anfordern und dabei auch festlegen an welche virtuelle Adressen die Pages gemappt werden sollen. Das kann man mit einem Buch mit sehr vielen Seiten bei dem die meisten Seiten "nicht benutzbar" sind vergleichen, nur die Seiten die "benutzbar" sind kosten tatsächlich Papier und wenn Du auf die nicht benutzbaren Seiten lesen/schreiben möchtest bekommst Du eins auf die Finger. Die Speicherverwaltung des OS kümmert sich darum das jeder Prozess physische Pages für seinen virtuellen Adressraum bekommt, das klappt natürlich nur so lange noch physischer Speicher verfügbar ist (swappen auf die Festplatte ist eine Stufe komplexer aber das Grundkonzept bleibt). Das funktioniert auch mit mehr als 4 GB physischen Speicher aber dann muss das Paging größere physische Adressen aufnehmen können. Intel hat sowas tatsächlich mit dem Pentium-Pro eingeführt so das ein OS das diesen Trick beherrscht tatsächlich mehrere Programme die zwar jedes weniger als 3 GB Speicher für sich aber in der Summe mehr als 4 GB Speicher brauchen gleichzeitig ausführen kann. Beim swappen werden einfach Pages, auf die momentan keiner zugreift, auf die Platte ausgelagert so das wieder mehr physischer Speicher verfügbar ist.

Ich hoffe ich konnte etwas zur Erleuchtung beitragen.


Grüße
Erik

1238

OS-Design / Re: Konzeption und Anfang

« am: 17. October 2009, 18:54 »

Hallo taljeth,

Schon klar, ich bin auch nicht völlig ahnunglos.

Entschuldige Bitte, ich wollte auf gar keinen Fall als Oberlehrer rüberkommen.

Die übrigen Anmerkungen waren nur so um mal über den Tellerrand zu sehen. In meiner Plattform muss ich wohl auf jeden Fall PCI-Express verwenden, daher habe ich mich damit recht intensiv beschäftigt, aber z.B. das Fehlermanagement werde ich auch nur so weit wie unbedingt nötig unterstützen.


Grüße
Erik

1239

Das Wiki / Re: Umstrukturierung des Forums

« am: 17. October 2009, 17:32 »

Hallo,


Den Name "Anfängerfragen" finde ich auch nicht passend, das ist dem Inhalt gegenüber abwertend. "Allgemeine Programmierung" o.ä. würde ich besser finden.
Ansonsten möchte ich PorkChicken zustimmen das man nicht gleich nen ganzen Sack voll neuer Boards braucht sondern eher dort Abhilfe schaffen sollte wo zu viele Dinge drin sind die eigentlich nicht wirklich hinein gehören. Die beiden Haupt-Boards, "Lowlevel-Coding" und "OS Design", sind IMHO nicht für alles gedacht und trotzdem ist dort, insbesondere bei "Lowlevel-Coding", ein Großteil des Traffics gebündelt. Ein bisschen mehr Gleichverteilung könnte eventuell von Nutzen sein.
Im Punkt der "Anfängerfragen" wiederspreche ich PorkChicken allerdings, es gibt verschiedene Ebenen von solchen Fragen: solche wo noch mit den Tücken der verwendeten Programmiersprache, Tools u.ä. gekämpft wird und solche wo es um Features tief in der verwendeten CPU/Hardware geht. Die erste Gruppe ist momentan in "Lowlevel-Coding" sehr aktiv, es gibt momentan einfach kein passenderes Board, und die andere ist in "Lowlevel-Coding" recht gut Untergebracht. Ich finde wenn man irgendwo das Messer ansetzt dann dort wo es am sinnvollsten ist also am vollsten Board.

Das mit den Beiträgen pro Seite war nur son Gedanke, wenns nicht besser geht dann eben nicht.


Grüße
Erik

1240

Das Wiki / Re: Umstrukturierung des Forums

« am: 17. October 2009, 14:32 »

Hallo taljeth,

wo man so einen "Alle Beiträge"-Link in einem SMF

Leider nicht, ich weis noch nicht mal wovon Du da eigentlich schreibst.
Vielleicht verrät man Dir auf http://www.c-plusplus.de/forum/ wie das geht, dort funktioniert dieses Feature zu meiner vollsten Zufriedenheit.


Grüße
Erik