Thema: CommFS?

[T0ast3r]

Nun stellt sich schon bald die Frage, welches FS wir nehmen.
Nehmen wir FAT, ein anderes, oder ein eigenes.
Wenn ein eigenes Fs gemacht werden soll, würd ich mich selbst verständlicherweise auch beteiligen.
Schreibt mir eure Meinung!

[stultus]

Fat32 wär ganz gut, oder ReiserFS (oder ext3), das kann alles von linux gelesen werden. eigenes würd ich nicht machen, zu kompliziert bzw. fehlende kompatiblität

[DDR-RAM]

Ich würd möglichst für alle bekannte entsprechende Treiber bauen, allerdings wird FAT12 für FDD und FAT32 für HDD wohl fürs erste reichen.

MfG
DDR-RAM

[Jidder]

Ich stimme DDR-RAM zu.

Meiner Meinung nach ist ein eigenes Dateisystem überflüssig. Es ist zwar für den Anfang einfacher ein eigenes FS zu implementieren, weil man sich alles selbst ausdenken kann und sich nicht an irgendwelche Datenblätter halten muss, aber wenn es ein "richtiges" OS werden soll bringt das eh nix, weil es inkompatibel ist und somit im praktischen Einsatz unbrauchbar. Der Lerneffekt ist bei einem bereits verbreiteten Dateisystem außerdem viel höher. Es gibt heutzutage dutzende Standards in allen Bereichen und das Problem bzw. die Aufgabe beim Programmieren eines Betriebssystems ist mMn unter anderem das Auswählen und Implementieren bereits vorhandener Spezifikationen.

[mastermesh]

Das erste, was wir brauchen werden, ist ein FAT12-Treiber (der jetzige Kernel wird von einer FAT12-Diskette geladen). Danach können wir weiterschauen.

Ein eigenes FS halte ich nicht für sinnvoll, vor allem, weil man dieses auch noch als stage1_5 in GRUB implementieren müsste.

[DarkThing]

Vielleicht sollte man auch Fat12 16 und 32 in einem Treiber zusammen erstellen. Das geht ganz gut wenn man einmal weiß was das Laufwerk für ein FS hat. So spart man sich ne Menge Code der eh gleich bleiben würde.

@Eigenes FS: Ich find auch das sollte man lassen. Bis man ein eigenes FS wirklich gut geplant hat, hat man ein schon fertiges zur Hälfte fertig implementiert.

[maumo]

Denkt ihr nicht VFat währe sinnvoller als Fat32? Windows nutzt das ja auch oder?

[Svenska]

Fuer den Anfang wäre ein FAT12-Treiber alleine ausreichend, dieser kann
dann später durch einen Fat-Treiber mit allen Schikanen usw ersetzt
werden (VFAT, LFNs und so Zeugs).
Wenn man jetzt erstmal nen Fat12 Treiber schreibt, hat man wenigstens
ersteinmal einen Ueberblick, wie Treiber im Allgemeinen implantiert
werden muessen und wo welche Sachen wie eingetragen werden
muessen. Fuer mich wäre der erste Treiber keine Produktions-, sondern
eher eine Planungssache.

Ersetzen kann man es immernoch, aber im jetzigen Stadium
FAT16/32/VFAT zu implementieren, halte ich noch fuer uebertrieben, da ja
nur eine Diskette zur Anwendung kommt.

Wichtig wird das dann, wenn HD-Treiber soweit sind bzw. der Kernel in der
Lage ist, Hardware durch Treiber anzusprechen.

Svenska

[T0ast3r]

OK dann machen wir kein eigenes.
Jetzt stellt sich aber die Frage, von welchem FS alles geladen wird.
Da der Bl Kernel wies aussieht von FAT12 geladen werden, würde ich sagen, dass wir FAT12 als hauptFS nehmen.
Für die anderen FSs würde ich einen Treiber integrieren, damit das System auch kompatibel ist.
Falls eben die grad beschriebene Info euch gut erscheint, kann ich ja schon mal einen Treiber basteln, der versucht ein FS zu erkennen, wenn es kein FAT12 ist und auch die Dateien lädt und so.

[DDR-RAM]

FAT12 wird für Festplatten aber ganz schön doof ^^

[mastermesh]

Ein "Haupt-FS" wirds nicht geben. Der Kernel wird von GRUB geladen und ist von sich aus also nicht an ein FS gebunden. Aber du hast natürlich recht, FAT12 wird das erste sein, was wir implementieren müssen. Du kannst natürlich anfangen, die Funktionen zu basteln, aber das Treiberinterface steht noch nicht fest, deshalb kannst du jetzt noch nicht alles machen.

[DarkThing]

Der Kernel wird von GRUB geladen und ist von sich aus also nicht an ein FS gebunden

Was ist mit Roshls Bootloader?

Ich finde FAT12 ist wichtig und irgendwas modernes für Festplatten also FAT32 oder ReiserFS z.B.

[mastermesh]

Was ist mit Roshls Bootloader? Ich finde FAT12 ist wichtig und irgendwas modernes für Festplatten also FAT32 oder ReiserFS z.B.

Roshls Bootloader wird nicht verwendet werden (Sorry Roshl, nix gegen dich). GRUB hat nunmal einige Vorteile, die nicht von der Hand zu weisen sind: es kann so ziemlich alle wichtigen FS lesen und dadurch, dass er Multiboot-konform ist, erleichtert er uns am Anfang das Coden sehr. Außerdem lässt er sich später einfach auch Festplatte installieren und kann auch alle anderen OSs laden.

[DarkThing]

Ok, wusst ich nicht.

@Grub: Kann Grub auch von CDs booten?

[matthieuriolo]

Wie findet man heraus von was für ein System das er Bootet?

[stultus]

Ich denk mal die meisten Fragen werden in der GRUB Doku beantwortet.

@DarkThing: wenn ich das bissel was ich schnell inner Doku gelesen hab richtig verstanden hab kann Grub auch mit CD's umgehn, siehe http://www.gnu.org/software/grub/manual/html_node/Device-syntax.html#Device%20syntax letzte zeile

[DarkThing]

...mit Link zu ner Doku wie man ne GRUB-CD macht, scheint also zu gehen. Soll das CommOS auch von CDs lesen können? Dann könnte man son Art Knoppix machen. Aber Diskette und Festplatte find ich ist erstmal wichtiger.

[EDIT]
Das hier wird noch auf der Seite zum Thema Grub & CD gesagt:

GRUB supports the no emulation mode in the El Torito specification1. This means that you can use the whole CD-ROM from GRUB and you don't have to make a floppy or hard disk image file, which can cause compatibility problems.

[mastermesh]

Wichtig ist jetzt vor allem, dass wir einen stabilen und ausgereiften Kernel haben, auf dem man weiter aufbauen kann.

[DarkThing]

Das ganze wird ja ein Microkernel. Aber ein Micro muss ja Module laden können, die sinnvollerweise Dateien sind. Das heißt der Kernel muss ohne Module min 1 FS unterstützen. Gibts da schon Pläne, welches das ist?

[mastermesh]

OK, ihr seit aber auch zu wissbegierig    leider sind die Docs noch nicht fertig, deshalb versuche ich mal, den Bootprozess in eigenen Worten zu erklären.

Der Kernel wird wie gesagt von Grub geladen. Dazu lädt Grub noch ein bestimmtes Programm namens "init" und einige lebensnotwendige Treiber (ATA und FATn oder sonstwas).

Der Kernel initialisiert das Memory Management und das Multitasking und ruft danach init auf. Init ist dann für das plattform-spezifische Booten da: d.h., es initialisiert die Treiber, die von Grub geladen wurden und benutzt diese, um während der Hardware-Erkennung weitere Treiber nachzuladen.

Der Sinn des Ganzen ist, dass der Kernel wirklich vollkommen unabhängig von Plattform, Hardware, FS und allem ist.