Beiträge anzeigen

1

tyndur / Re:0.3 - Ideen und Ziele

« am: 09. November 2013, 12:09 »

Zitat von: Svenska am 07. March 2011, 12:37

Sinnvoll wäre, wenn man Images möchte, ungefähr folgende Reihenfolge:

(a) Zielpartition erstellen
(b) Partitionsimage (nicht Festplattenimage!) da reinkopieren
(c) Dateisystem an reale Partitionsgröße anpassen (z.B. resize2fs)
(d) Postinstall

Die zweite Möglichkeit ist ein Release als Tarball:

(a) Zielpartition erzeugen
(b) Dateisystem erzeugen
(c) Tarball entpacken
(d) Postinstall

Zum Postinstall gehört alles, was ein System benutzbar macht: Hostname, Netzwerkeinstellungen, Bootmanager (bevorzugt in die Partition, dann macht man einen bereits vorhandenen Systembootmanager nicht kaputt), Tastaturbelegung, Sprache, Hardwarekonfiguration (soweit nötig), so notwendigen Krempel halt, den man nicht allgemein machen kann.

Gruß,
Svenska

Das läuft unter Berücksichtigung der Tatsache, das man seine Partitionstabelle mit tyundur ändern möchte. Ich persönlich würde lieber:
(a) 1) Zielpartition mit irgendeinem System erstellen und im Installer auswählen.
2) (Alternativ) Partition mit dem Installer erstellen.
(b) ... (wie gehabt).

2

OS-Design / Higher Half

« am: 30. October 2013, 22:34 »

Ich würde gerne einen High Half Kernel schreiben. Wie krieg ich dann hin, dass die Addressen dann entsprechend Angepasst werden? Ich meine jetzt nicht, wie setzte ich das Paging auf, sonderen allgemein. Weil wenn ich im Link file andere Angeben mache denkt der Bootloader er müsste den Code wirklich an die hohen Addressen laden.

3

Lowlevel-Coding / Re: Befehl zum Graphikspeicherrefreshen

« am: 27. October 2013, 17:25 »

Hab den Fehler jetzt übrigens lokalisiert, da ich unter Windows arbeite (ich weiß das ist ungünstig) und mir fbc nur pe ausspuckt musste ld das korregieren und hat den call Befehl falsch konfiguriert, so das der jetzt nicht am Anfang von clsc() sondern so 72 bytes weiter hinten irgendwo in der nop folge auftrifft.

4

Lowlevel-Coding / Re: Befehl zum Graphikspeicherrefreshen

« am: 27. October 2013, 16:09 »

Ja steht drin. Es scheint was damit zu tun haben, dass ich mehre Dateien zusammen bastle. Weil wenn ich clsc() in die Hauptdatei schreibe gibt es da kein Problem.

Add: Hab jetzt mal das extern C bei den anderen Dateinen rausgemacht. löst aber nicht das Problem.

5

Lowlevel-Coding / Re: Befehl zum Graphikspeicherrefreshen

« am: 27. October 2013, 15:13 »

$ objdump -x kernel kernel: file format elf32-i386 kernel architecture: i386, flags 0x00000112: EXEC_P, HAS_SYMS, D_PAGED start address 0x0010000c Program Header: LOAD off 0x00001000 vaddr 0x00100000 paddr 0x00100000 align 2**12 filesz 0x000005f4 memsz 0x000005f4 flags r-x LOAD off 0x00002000 vaddr 0x00101000 paddr 0x00101000 align 2**12 filesz 0x00000070 memsz 0x00003000 flags rw- Sections: Idx Name Size VMA LMA File off Algn 0 .text 000005f4 00100000 00100000 00001000 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 0000002c 00101000 00101000 00002000 2**2 CONTENTS, ALLOC, LOAD, DATA 2 .drectve 00000040 0010102c 0010102c 0000202c 2**2 CONTENTS, ALLOC, LOAD, DATA 3 .ctors 00000004 0010106c 0010106c 0000206c 2**2 CONTENTS, ALLOC, LOAD, DATA 4 .bss 00002000 00102000 00102000 00002070 2**2 ALLOC SYMBOL TABLE: 00100000 l d .text 00000000 .text 00101000 l d .data 00000000 .data 0010102c l d .drectve 00000000 .drectve 0010106c l d .ctors 00000000 .ctors 00102000 l d .bss 00000000 .bss 00104000 l .bss 00000000 kernel_stack 00100020 l .text 00000000 _stop 001002d4 g .text 00000000 _printHex 001003b4 g .text 00000000 _printDec 00100584 g .text 00000000 _init 001000f4 g .text 00000000 _putChr 0010000c g .text 00000000 _start 00100074 g .text 00000000 _scrolldown 00100234 g .text 00000000 _kprintf 00100024 g .text 00000000 _clsc 001001d4 g .text 00000000 _setcolor

steht wirklich nix interessantes drin. Es sei denn ich muss aufpassen, das der den Kernel als ROM betrachtet.

6

Lowlevel-Coding / Re: Befehl zum Graphikspeicherrefreshen

« am: 27. October 2013, 14:48 »

Jo ohne das clsc() Sieht man noch den BIOS Text, aber das Hallo Welt drübergeschrieben.

Liegt das vielleicht daran, das ich qemu -kernel nutzte?

7

Lowlevel-Coding / Re: Befehl zum Graphikspeicherrefreshen

« am: 27. October 2013, 14:32 »

zu zString) Das funktioniert alles wenn man die clsc() Funktion auslässt.

zum Stack) Hoffe ich. Allerdings ist der init Funktion noch die _start() Funktion vorgeschaltet. Dies hab ich aus http://www.lowlevel.eu/wiki/Teil_4_-_Hello_World übernommen und sie wird auch aufgerufen.

8

Lowlevel-Coding / Re: Befehl zum Graphikspeicherrefreshen

« am: 27. October 2013, 14:17 »

Hab ja nix zu verheimlichen. Ist aber in FreeBASIC. Aber man kanns warscheinlich trotzdem lesen:

Das Hauptprogramm Init.bas

Code: [Auswählen]

' Das selbe wie init.c nur jetzt in Freebasic
#include "console.bi"

extern "C"
	sub init() export
		clsc()
		
		const hwStg = "Hallo world"
		dim as integer i = 0
		dim as byte ptr video = VIDEOPTR
		dim as byte ptr hw = @hwStg
		' ZStrings haben ein Nullbyte als Abschluss
		' Ein paar Probeaufrufe
		video[0] = &h25
		
		video[344] = &h60
		while hw[i] <> 0
			' Zeichen i in den Videospeicher kopieren
			video[i*2] = hw[i]
			' 0x07 = Hellgrau auf Schwarz
			video[i*2+1] = &h07
			i += 1
			'putchr(hw[i],&h07)
		wend
		'setcolor(2,0)
		'kprintf("HelloWelt")
		'kprintf("HexTest:%i", &h80000000)
		'kprintf("NowInHex: %X", &h80000000)
	end sub
end extern

Und die Textausgabe in console.bas

Code: [Auswählen]

#include "console.bi"

' Der Screen befindet lässt sich linear mit Offsets ab 0xB8000 ansprechen.
' 0x07 = 0000 0111

extern "C"
	dim shared as byte bgcolor  = &h07  	    ' Hintergrund: 0x07 = Hellgrau auf Schwarz
    dim shared as integer spos = 0              ' Prosition auf dem Bildschirm
	
	declare sub scrolldown()
	'declare function putChr(char as ubyte, colorS as ubyte) as integer
	declare function printHex(i as integer, location as byte ptr) as integer
	declare function printDec(i as integer, location as byte ptr) as integer

	sub clsc() export
		dim as integer i
		dim as integer ptr p = VIDEOPTR
		for i = 0 to 20*25*2 - 1
			p[i] = &h07400723					' Clean up space.
			'putChr(&h23,&h07)
			'putChr(&h40,&h07)
		next i
		spos = 0								' Reset virtual cursor
	end sub
....

9

Lowlevel-Coding / Re: Befehl zum Graphikspeicherrefreshen

« am: 27. October 2013, 14:06 »

Naja ich bin ziemlich am Anfang, also bei der Textausgabe. Wenn ich im Hauptprogramm eine Funktion habe die "Hallo Welt" direckt in den Grafikspeicher schreibt, ohne den Bildschirm zu löschen, so funktioniert das. Wenn ich aber vorher noch eine Clear Screen funktion aufrufe, klappt es plötzlich nicht mehr. (Beide Programme verwenden nicht die gleichen Zeiger uä.)

Also die Cls-funktion klappt. (mit anderen Zeichen als Leerzeichen getestet.)

10

Lowlevel-Coding / Befehl zum Graphikspeicherrefreshen

« am: 27. October 2013, 13:15 »

Muss man im Textmodus dem Computer irgendwie sagen, das man den Graphikspeicher geändert hat, weil bei mir ist es so, das qemu irgentwann einfach aufhört, den Text auszugeben.

11

Softwareentwicklung / Re: Geschwindigkeit verschiedener Syscall Versionen

« am: 26. October 2013, 10:06 »

Jo das Stimmt. Ich hab mal nachgeschaut. Auf der 486 war call (callGate) Aufruf ohne Stackparameter gerade mal 2 Takte schneller als ein Interrupt. Ähnliches gilt für die Rückkehrbefehle, auch hier ist die CallGate nur 3 Takte schneller. Ist schon schade, weil CallGates sahen wirklich gut aus. Wahrscheinlich ist es wirklich am Elegantestes, eine Page für Syscalls anzulegen, auf die dann als Funktionen zurückgegriffen werden kann, und die dann den eigentlichen Ringwechsel durchführen, indem sie Syscall/Sysenter oder was auch immer benutzten. (Dann bräuchte man sich die Rücksprungadresse nicht explizit zu merken.). Aber wie gesagt, das ist sehr eng, wenn man viele Parameter an den Kernel senden will.

12

Softwareentwicklung / Re: Geschwindigkeit verschiedener Syscall Versionen

« am: 26. October 2013, 01:54 »

Naja CallGates haben schon ein paar Vorteile: 1. Deutlich flexibler als sysenter, da sie a) auch auf älteren Systemen und bei flexibeler GDT sowie bei AMD und Intel gleichermaßen laufen. Dadurch kann man sie als Standard-Api verwenden. b) man sich nicht um die Sicherung der Rücksprungadresse kümmern muss (was insbesondere wertvolle Prozessorregister dann spart, wenn man sie nicht auf dem Stack sichern kann.), c) man kann mehre davon haben. d) Man kann Einträge vom User auf den KernelStack kopieren lassen. e) Sie geraten sicherlich in keinen Konflikt mit irgendeiner anderen Api. f) wenn man ganz geschickt ist, kann man im nicht verwendeten Call-Bereich des Aufrufs noch Informationen verpacken, die auch vom Kernel angesteuert werden können.

Gegenüber Interupts, ist der Vorteil, dass sie alles können, was SoftwareInterrupts können, nur schneller. Callgates poppen keine Flags, ob das gut oder schlecht ist sei mal dahingestellt. Der einzige Nachteil ist, das der Opcode halt bei Interrupts immer 2 byte lang ist und bei CallGates im 32 Bit Modus 7 Byte lang ist. (Wobei man hierbei wie gesagt, da auch irgendetwas reinschreiben kann.)

13

Softwareentwicklung / Geschwindigkeit verschiedener Syscall Versionen

« am: 26. October 2013, 00:48 »

Mich würde mal interessieren, wie lange genau so verschiedene Syscallvarianten so brauchen. Also Interrupts, CallGates, Sysenter/Sysexit bzw. Syscall/Sysleave.

Weil für mich sehen Call Gates eigentlich ziemlich cool aus.

14

Lowlevel-Coding / Re: Startgerät beim CDI-Treiber?

« am: 22. October 2013, 22:18 »

Naja bei Linux gibt es dazu glaub Regeln, wobei ich mir da aber auch nicht sicher bin. Bei Windows ist der Bezeichner C: nicht an ein bestimmtes Laufwerk gebunden, sondern wird der Bootpartition zu geordnet. Deshalb wird ja auch dort das Laufwerk mit einer abstrakten Bezeichnung angesprochen.

15

Lowlevel-Coding / Segmentierung im Long Mode

« am: 19. October 2013, 17:08 »

So wie ich weiß kennt der Long Mode ja auch noch den, Compatibility Mode. So weit ich weiß, werden außerdem die Base und Limit Angaben im 64 bit Mode nur noch bei fs,gs unterstützt. Mich würde jetzt mal interessieren, wie das im Compatibility Mode aussieht. Werden da Bases und Limits berücksichtigt.

16

OS-Design / Re: Monotholitisher Kernel oder Microkernel

« am: 07. April 2012, 22:54 »

Das wird ja glaub sorgar erklärt. Der Kernel startet Treiber als eigene Tasks, die dann wahlweise im Ring 0 oder Ring 3 laufen können.
Der Name ist natürlich ein bis NiwohlOS-artig. Aber als Konzept für einen modularen Hybridkernel ist es gar nicht so dumm. Das Rum schieben braucht man eigentlich nicht, starte die Treiber gleich im Richtigen Ring

17

Lyrisches Eck / Re: Wortspiel

« am: 07. April 2012, 22:48 »

...

Der Quellcode quält mich lange.
Die Register registrieren Fehler.
Die Variablen variieren wahrlos.

18

OS-Design / Re: Monotholitisher Kernel oder Microkernel

« am: 29. March 2012, 22:35 »

Zitat von: Svenska am 28. March 2012, 22:10

Ein Link ins Wiki hätte vermutlich auch gereicht...

Hab ich mir im Vorhinein auch gedacht, aber dann irgendwie trotzdem alles noch mal aufgeschrieben.

Was taljeth mit kaputter Kernel meint? Seine eigenen Projekte?

19

OS-Design / Re: Monotholitisher Kernel oder Microkernel

« am: 28. March 2012, 21:21 »

Er hat nicht gefragt, was ihr am besten findet, sondern was welche Vorteile hat. Wie bereits gesagt, ist die Kernelart erst interessant, wenn die Basics (Bildschirmausgabe, einfache Speicherverwaltung und Multitasking sicher laufen).

Ganz Kurz (alle Angaben sind relativ, man kann die Vorteile auch teilweise nur mangelhaft ausschöpfen oder Nachteile verringern).

monolithischer Kernel

pro:
- Einfache Kommunikation zwischen Kernel und Trieben durch simple Funktionsaufrufe.
- sehr schnell, da wenige Ringwechsel.
- Nur eine saubere Schnittstelle für Userspaceprogramme

kontra:
- Eventuell unübersichtlich.
- Fehlerhafter Treiber bringt das System zum Absturz.
- Treiber müssen bei jedem Kernelrease angepasst werden.
- Alle Treiber müssen vertrauenswürdig sein.

Microkernel

pro:
- Modularer Aufbau
- Ein fehlerhafter Treiber bringt nur sich selbst zum Absturz und kann neu gestartet werden
- Saubere Schnittstelle für Treiber, die so auch noch bei der Folgeversion funktionieren können.

kontra:
- Viele Schnittstellen zwischen Modulen und Treibern notwendig
- Langsam, durch die vielen Ringwechsel
- Der Bootloader muss neben dem Kernel auch noch die minimal notwendigen Treiber laden, die dann gestartet werden müssen.
- Kernel verfügt selbst über weniger Möglichkeiten oder muss auf externe Treiber zurückgreifen.

Jetzt musst du deine Schwerpunkte setzten.

20

Lowlevel-Coding / Re: memset();

« am: 27. March 2012, 19:34 »

Das "_t". Steht warscheinlich für types. Alle Datentypen, die irgentwo in der cstdlib auftrauchen, und die nicht zu den "echten" C-Datenypen (char,short,long,int,unsigned,signed,float,double,...) gehören, tragen diese Endung.