Lowlevel
Lowlevel => tyndur => Thema gestartet von: T0ast3r am 08. May 2005, 13:54
-
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!
-
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
-
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
-
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.
-
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.
-
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.
-
Denkt ihr nicht VFat währe sinnvoller als Fat32? Windows nutzt das ja auch oder?
-
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
-
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.
-
FAT12 wird für Festplatten aber ganz schön doof ^^
-
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.
-
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.
-
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.
-
Ok, wusst ich nicht.
@Grub: Kann Grub auch von CDs booten?
-
Wie findet man heraus von was für ein System das er Bootet?
-
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
-
...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.
-
Wichtig ist jetzt vor allem, dass wir einen stabilen und ausgereiften Kernel haben, auf dem man weiter aufbauen kann.
-
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?
-
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.
-
Da ist GRUB ja wirklich SEHR praktisch :)
-
Was ist den nun überhaupt GRUB?
Gib mir mal da bitte eine Erklärung ab.
Ich werde jetzt dann einen Code basteln, der versucht ein FS zu erkennen, denn das ist ja der 1. Schritt.
Nun möcht uich für euch nur noch wissen, für welche FSs ich Treiber basteln soll.
Und übriggens soll ich den Treiber in C oder Ass schreiben?
Ich werd wahrscheinlich einbinden: FAT (12, 16, 32), LowFS :lol: , TBFS *doppelt LOL*, und ein paar andere
-
GRUB ist nen Bootloader.
ASM ist für nen FS-Treiber unnötig, der greift auf nen HDD/FDD/CD/DVD-Treiber zu, braucht also kein asm. Die Schnittstelle ist allerdings nocht nicht definiert. Also kannste noch nix machen.
MfG
DDR-RAM
-
najo, treiberdocs durcharbeiten wär ja schonmal nen ganz guter anfang, der auch ohne interface geht ^^
-
ist dann aber nix mit basteln ;-)
Da stell ich mal wieder ne technische Frage in den Raum:
Wir haben Treiber und Kernmodule, was ist der Unterschied zwischen beiden, also ich bräuchte keinen, aber passt nicht so ganz hier her.
-
Kommt drauf an welche Begriffe du wie definierst.
Wenn
Kernmodul: Festplatte, CD, Floppy, Netzwerk, (Alles was gebraucht wird um Hardware allgemein anzusprechen)
und
Treiber: Dateisysteme, Protokolle (IP, TCP, UDP, ...) (Alles was direkt vom Userprogramm verwendet wird)
ist der unterschied ganz klar: Treiber benötigen bestimmte Kernmodule, von wo soll nen Fat12-Treiber schließlich Daten beziehen wenn das Floppylaufwerk nicht ansprechbar ist?
-
Wenn wir einen Microkernel basteln wollen, so gehört _nichts_ in den
Kernel rein, was irgendwie mit Treibern zu tun hat.
Die Aufgabe des Kernels ist es dann nur, den einzelnen Prozessen
Rechenzeit zuzuweisen und zu klauen, möglichst nach einem einheitlichem
Schema.
Kernel
||
\/
Hardware- (z.B. HDD, FDD, Net, ...)
treiber
||
\/
Software- (z.B. FAT12, Ext2, TCP/IP, IPX, ...)
treiber
Damit das klappt, brauchen wir eine Schnittstelle, mit der wir den Kernel
mit dem Hardwaretreiber verbinden.
@DDR-RAM: Wer lieber Asm statt C++ programmiert, sollte das auch
duerfen. Nicht notwendig ist nicht gleich schlecht :)
Svenska
-
Also, ich man könnte, aufteilen in Kernmodule(z.B. IPC), Hardwaretreiber(z.B. Laufwerke), Softwaretreiber (z.B. Dateisysteme),
mir ging es um den technischen Unterschied, außer das Softtreiber auf Hardwaretreibern aufbauen müssen.
Ich hatte nie vor jemandem ASM/C zu verbieten ;-)
Mache mich nur dafür stark, lieber C++ als C zu verwenden und asm nur wenn notwendig, um die kompatiblität und evtl. Transportablität auf andere System zu maximieren.
MfG
DDR-RAM
-
Hmm CommOS soll ein Lern-OS werden, nicht den Zweck NetBSDs
verfolgen... welches richtige OS ist schon in Cpp geschriebn? *lach*
-
ich persoenlich wuerde fuer jegliche abstraktion von der hardware c++ verwenden..weils einfach die abstraktion schon 'eingebaut' hat.. im sinne der objektorientierten programmierung.
-
Ihr kommt vom Thema ab!
Also: wie soll ich FAT12 erkennen?
Ich hab mir überlegt, dass ich 3 Euinträge aus dem Bootloaderinfoblock vergleiche.
Diese 3 Werte sind:
BytesPerSec: muss 512 sein
NumFATs: muss KLEINER als 13 sein
NumHeads: muss KLEINER als 13 sein
was hält ihr davon?
Ich weiß halt nbicht, woran ich sonst ein FAT12 Formast erkennen sollte.,
-
Daran das irgendwie im Sektor ein String steht der mit FAT anfängt und du dann eine Clusterzahl ausrechnest die <4085 ist oder so ähnlich.
-
Jo!
Das hab ich mir schon auch gedacht!
Aber das blöde ist nur das der Eintrag in dem Normalerweise FAT12 steht nur bedingt ist!
(siehe TJ Fat tutorial, Bottirgendwas)
-
In den allermeisten Fällen ist er aber da, und wenn nicht kannste auf gut Glück mal die CLuster ausrechnen, relativ unwahrscheinlich das was sinnvolles rauskommt wenn's nicht FAT12 ist, da ja doch einige Werte einbezogen werden müssen.
-
Dann soll ich die 3 Einträge zu testen vergessen? *seufz*
-
Ja^^
-
@ Roshl: Das mit den Clustern ist find ich ein blödsinn.
Wenn, dann nur weil an einem Entrag FAT12 steht, ansonsten würde ich sagen das es kein FAT ist.
(Weil der Clustereintrag kann ja vieles sein, vn den anderen FSs)
Naja ich schua dann einfach nach, ob da halt FAT12 steht
-
Also nochmal:
Zuerst schaust du ob der Kennungsstring mit FAT anfängt.!!!
Dann berechnest du die Clustergrösse.
Das ist nunmal das einzige an dem man die verschiedenen FAT-Varianten erkennen kann.
Denn es ist NICHT!!!! Pflicht das dort auch FAT12 steht, es kann sein, dass dort NUR FAT steht, dann bist du wohl aufgeschmissen.
Steht so in JEDER Doku dazu.
-
...und dann geben wir uns die Hand, und haben uns wieder lieb...also ganz ruhig.
-
Sorry aber ich finde wenn man schon eine Doku dazu auf dieser Seite hier hat, sollte mans auch Lesen, und da steht klar drin, das man FAT12 eben nur an den Clustern erkennt und nicht das da FAT12 drin steht. Nur weil ich mit nem Edding "Wurst" auf ein Stück Käse schreibe wird keine Wurst draus. Das ist leider Fakt^^
-
@Roshl: Entweder es steht da gleich FAT12 dort, oder NIX.
Im FAT Tutorial steht in so einem eintrag, dass der Angibt, ob die 3 folgenden Einträge vorhanden sind.
ALSO STEHT DA ENTWEDER FAT12 ODER WAS ANDERES!!! :evil:
-
Das mit den Clustern steht ja eh dort, aber trotzdem.,
-
Dann lies dir mal Microsofts Original genau durch, da steht ausdrücklich, dass FAT12/16/32 ausschliesslich anhand der Clusterzahl unterschieden werden kann und nicht weil dort ein String steht der FAT12, FAT16 oder FAT lautet.
Tut mir Leid aber es ist einfach so.
-
Ja Roshl hat recht ;-)
-
Ja OK kapiert, aber wo sollte FAT stehen?
-
Jeweils die letzten 8 Byte im Header geben den Filesystype an. Der Offset unterscheidet sich aber, bei FAT12/16 ist er gleich FAT32 weiter hinten. Genauen Bytezahlen hab ich auch nicht im Kopf.
Microsoft hat da echt Mist gemacht, es gibt eigentlich gar nichts woran man sicher erkennt, dass das ein FAT-System ist^^
-
OK ds OFFSET steht eh im FAT12 TUtorial von TJ.
Das vom FAT32 such ich mir eh raus..
-
Also ich hab mir nun einen Code einfallen lassen, der überprüft, ob das laufwerk FAT formatiert ist und wenn ja dann wie.
Schreibt mir was s dann übern code zu meckern gibt.
CheckFS: ; Die Funktion um das FS zu überprüfen
; Parameter: DL = Laufwerk
call ReadBootSector ; lese den BootSector
cmp [BootSector + 54], âFâ ; Ist 1. Buchstabe vom Eintrag FileSysType ein âFâ ?
jne Ende ; wenn nein, dann kein FAT
cmp [BootSector + 55], âAâ ; Ist 2. Buchstabe vom Eintrag FileSysType ein âAâ ?
jne Ende ; wenn nein, dann kein FAT
cmp [BootSector + 56], âTâ ; Ist 3. Buchstabe vom Eintrag FileSysType ein âTâ ?
jne Ende ; wenn nein, dann kein FAT
call FAT ; welches FAT ?
Ende:
ret
ReadBootSector: ; Funktion um den Boot Sektor zu laden
; Parameter: DL = Laufwerk (übernommen aus CheckFS)
mov AH, 02h ; Funktionsnummer: 02h
mov AL, 1 ; lese einen Sektor
xor CH, CH ; Cylinder = 0
mov CL, 1 ; Sektor = 1
xor DH, DH ; Head = 0
mov BX, Offset BootSector ; Adesse des Puffers nach BX
Int 13h ; lese nun den BootSector!!!!
ret
FAT: ; Funktion um FAT12 + FAT16 zu erkennen
mov CX, [BootSector + 19] ; TotSec nach AX
sub CX, [BootSector + 14] ; TotSec - ResvdSecCnt
xor DX, DX ; DX = 0 (wichtig für Word Multiplikation)
xor AH, AH ; AH = 0 (wichtig für Word Multiplikation)
mov AL, [BootSector + 16] ; AL = NumFATs => AX = NumFATs
mul word ptr [BootSector + 22] ; NumFATs * FATSize
sub CX, AX ; (TotSec â ResvdSecCnt) â (NumFATs* FATSize)
xor DX, DX ; DX = 0 (wichtig für Word Multiplikation)
mov AX, [BootSector + 17] ; RootEntCnt nach AX
mul word ptr 32 ; RootEntCnt * 32
xor DX, DX ; DX = 0 (wichtig für Word Division)
div 512 ; (RootEntCnt) / 512 = RootDirSectors
sub CX, AX ; TotSec â ResvdSecCnt â NumFATs* FATSize - RootDirSectors
ret
AssignClusterToFAT: ; Funktion, welche den Laufwerken die FAT Version zuweist
; Parameter: CX = Cluster
cmp CX, 4085d ; FAT12 ?
jnl FAT16 ; wenn nein, dann springe zur FAT16 Überprüfung
; [...] Some Code
jmp End
FAT16:
cmp CX, 65525d ; FAT16 ?
jnl FAT32 ; wenn nein, dann ist es FAT32
; [...] Some Code
jmp End
FAT32
; [â¦] Some Code
End:
ret
BootSector db 512 dup (0)
Im Code hab ich mehr auf verständlichkeit wert gelegt, als auf Performace
*hinweis*