Themen

1

OS-Design / Kompilieren von Bedingungen

« am: 11. February 2006, 19:13 »

Ich habe folgendes C Statement (i ist eine Integer Variable):

Code: [Auswählen]

if (i == 5 || (i > 3 && i < 7)) { }
Welchen Parsetree sollte ich daraus erstellen? Ich hatte mir sowas gedacht:

Code: [Auswählen]

IF
OR
EQUALS
i
5
AND
GREATER
i
3
LESS
i
7
Was wäre der beste x86 Code, den man daraus erstellen kann? (Angenommen i befindet sich in einem Register)
Ich finde keinen guten Weg, den Parsetree in x86 Code umzuwandeln. Hat jemand eine Idee? :/

2

OS-Design / Templates/Generic Types für eigene Programmiersprache

« am: 09. February 2006, 16:19 »

Hi, ich arbeite im Moment an einer eigenen (bytecode basierten) Programmiersprache, und ich finde keinen guten Weg, um Templates zu implementieren. Eine Möglichkeit wäre, die Templates vom Compiler einfach durch Einsetzen der richtigen Typen anstatt der Typ-Argumente zu kompilieren. Dann können Shared Libraries (von denen der Source unbekannt ist), von denen der Code unbekannt ist, Templates aber nur eingeschränkt nutzen. C++ basiert ja darauf, wie löst C++ dieses Problem? (oder ist das in C++ auch nicht möglich?) Eine andere Möglichkeit wäre, alle Primitiven Objekte in Wrapperklassen zu stecken (die nicht-primitven Objekte basieren eh alle auf einer Grundklasse) und dann das Template nur für die Grundklasse zu kompilieren. Durch Operator Overloading könnte man alle Typen einheitlich handhaben. Diese Methode würde ich gerne vermeiden, da das sehr lahm wäre, ausserdem wäre sie schwer zu implementieren. (Die Programmiersprache hat sehr viele Primitive und Strukturen, die nicht in andere Typen gecastet werden können, also auch nicht in die Grundklasse)

3

Lowlevel-Coding / Eigene Bytecodebasierte Sprache

« am: 06. January 2006, 20:31 »

Hi,
IMHO gibt es heute keine wirklich gute universelle Bytecode basierte Sprache. Java ist ganz gut, aber es hat keine Structs und keine unsigned Typen. Daher muss man bei der Eingabe/Ausgabe immer zwischen signed und unsigned umwandeln und verbraucht unötig viel Speicherplatz. .NET/C# behebt diese Probleme, jedoch hat es nur eine kleine Standardbibliothek und man muss häufig nativen Code einsetzen, was ich verhindern möchte. Ausserdem ist es intern nicht wirklich gut aufgebaut, .NET baut auf eine Art PE auf. .NET sollte zwar portabel sein, aber große Teile der Bibliotheken funktionieren nur unter Windows und sind proprietär. Hinzukommt, dass alle Sprachen bisher noch Wünsche beim Multithreading und bei der Speicherverwaltung offen lassen.

Deshalb habe ich mich entschlossen ein eigenes Bytecode Format und eine eigene Sprache zu entwickeln, das diese Features ergänzt.

Bei der Syntax hatte ich an eine Art C/C++/Java gedacht, da diese Syntax den meißten bekannt sein sollte.

Ich wollte jetzt mit einem Compiler für eine solche Sprache anfangen (der Compiler wird warscheinlich in Java geschrieben sein), und wollte fragen, ob jemand schon Erfahrungen im Compilerdesign hat. Wenn sich jemand beteiligen möchte, würde ich mich sehr freuen. Ich aber im Moment aber nicht so viel Zeit, da ich hauptsächlich an Legends und meinen Java-JIT Compiler arbeite. Dieser JIT ist ausserdem so flexibel, das meine eigene Sprache später, wenn der Compiler funktioniert, darin eingebettet werden könnte.

Naja, wie gesagt, hat jemand schon Erfahrungen im Compilerbau oder möchte jemand mitmachen?

4

Lowlevel-Coding / PM Switch

« am: 01. January 2006, 23:09 »

Hm, ich habe hier ein kleines Problem mit dem einschalten des PMs. Der folgende Code wird an 0x1000 geladen, und dann an 0x100:0 ausgeführt.
Ich habe Probleme mit dem FAR JMP zum leeren der pipeline. Wie muss des aussehen?

Bochs gibt bei meinen jetztigen Code aus:

Code: [Auswählen]

00007911925e[CPU1 ] jump_protected: gate type 0 unsupported
00007911925e[CPU1 ] exception(): 3rd (13) exception with no resolution, shutdown status is 00h, resetting

Code: [Auswählen]

[bits 16]
[org 0]
aprm_boot:
; zum code springen
jmp aprm_code

; die configtable fängt an 0x8 an
times 8-($-$$) db 0

; die felder hier werden vom kernel eingetragen (dieser code hier bootet die prozessoren in einem SMP system, prozessor0 ist schon im pm und trägt hier die entsprechenden werte ein.)
aprm_config:
; protected mode code entry
dd 0

aprm_code:
; interrupts ausschalten bis wir eine IDT haben usw.
cli

; GDT laden
lgdt [aprm_gdtdesc]

; pm einschalten
mov eax, cr0
or eax, 0x1
mov cr0, eax

; pipeline flushen (kann das nasm auch ohne diese umständliche codierung?)
db 0xEA
dw 0x1000 + aprm_flush
dw 0x8

[bits 32]
aprm_flush:
mov ax, 0x10
mov ds, ax
mov es, ax
mov fs, ax
mov gs, ax

mov ebx, [aprm_config]
jmp ebx

aprm_gdt:
; null descriptor
dd 0
dd 0

; kernel code
dw 0xFFFF
dw 0
db 0
db 0x9A
db 0xCF
db 0

; kernel data
dw 0xFFFF
dw 0
db 0
db 0x92
db 0xCF
db 0

aprm_gdtdesc:
; gdt descriptor
dw aprm_gdtdesc - aprm_gdt - 1
dd aprm_gdt

5

Lowlevel-Coding / SMP testen

« am: 25. December 2005, 19:46 »

Hm, ich wollte mal SMP in meinen Kernel einbauen, habe aber selber keinen Prozessor, der es unterstützt. Gibt es einen Emulator, der mehrere Prozessoren simuliert? Kann ich mit Bochs einen Dualcore Prozessor simulieren?

6

Lowlevel-Coding / FPU sichern

« am: 24. December 2005, 19:58 »

Hi,
wie funktioniert das Task-Switched Bit im CR0?
Wenn ich das richtig verstanden habe, setzte ich das TS-Bit bei jedem Taskswitch, wenn die FPU dann benutzt wird, löscht der Prozessor es, und löst eine Exception aus, wodurch ich dann die FPU-Register sichern kann. Oder muss ich das Bit selbst löschen, wenn die Exception ausgeführt wird?

7

Lowlevel-Coding / DMA

« am: 24. December 2005, 19:46 »

Hm, wie ist das jetzt mit dem DMA? Soweit ich weiß gibt es ja Geräte, bei denen der DMA die Daten nur bis zur 1 MB Grenze kopieren kann. Andere können die Daten bis 16 MB kopieren. Ist das so richtig, oder kann ich mit dem DMA immer auf die ersten 16 MB zugreifen?
Ich überarbeite grad mein Memory Management, und ich wollte dann diese Bereiche für DMA-Buffer reservieren.

8

OS-Design / Spinlocks/Scheduling

« am: 23. December 2005, 23:51 »

Hi,
ich bastel grad an meinen Multitasking rum, und habe da ein Problem: Die Informationen über meine Tasks sind in verschiedenen strukts gespeichert. Ich habe jetzt mehrere Funktionen, die diese structs verändern. (z.B. thread_create(), thread_suspend()) Mein scheduler muss diese structs jedoch auch ändern, um den nächsten Task auszusuchen. Deshalb muss sichergestellt werden, das nur ein Thread die structs ändern kann. Bei einem Ein-Prozessorsystem ist das ja ganz leicht: man kann einfach man schaltet einfach die Interrupts ab, wärend man die Daten ändert. Auf einem Multiprozessorsystem funktioniert das ganze aber nicht mehr, da man die anderen Prozessoren die Daten immernoch ändern könnten. Wenn man jedoch die structs mit einem Spinlock schützt, und ein Interrupt tritt wärend des schedulens auf, wird wieder der scheduler aufgerufen, der das Spinlock nicht mehr locken kann, da es ja schon von einem anderen Thread gelockt ist. Fällt jemandem vieleicht eine Methode ein, wie ich dieses Problem lösen kann?

9

Lowlevel-Coding / Datensegmentregister

« am: 16. December 2005, 13:47 »

Angenommen man ist im PM, hat einen flachen Addressraum und Paging ist aktiviert. Wenn ich jetzt auf eine Page zugreife, auf die nur der Kernel Zugriffsrechte hat, wird dann CS oder das jeweilige Segmentregister benutzt, um festzustellen, ob ich auf eine Speicherstelle zugreifen darf?
Wenn CS dazu benutzt wird, könnte ich ja eigentlich ES, DS, FS, GS und SS immer auf ein Ring3 Segement zeigen lassen, selbst wenn ich in einem Kernelthread bin, und müsste sie nicht alle auf den Stack pushen, sondern könnte sie einfach wieder auf einen gültigen Wert setzen, oder übersehe ich da irgentwas?

10

Lowlevel-Coding / Probleme mit GCC

« am: 14. December 2005, 21:19 »

Hm, ich habe folgenden C-Code:

Code: [Auswählen]

struct Queue {
struct Queue *next;
void *object;
};

typedef struct Queue Queue;

extern inline Queue *queue_insert(Queue *after) {
Queue *nqueue = (Queue *)kalloc(sizeof(Queue));

if(after == 0) {
nqueue->next = nqueue;
}else{
debug_info("test\n");
nqueue->next = after->next;
after->next = nqueue;
}

return nqueue;
}
kalloc() macht das gleiche wie malloc()
debug_info() macht das gleiche wie die libc funktion printf.
Wenn ich jetzt das debug_info() auskommentiere und keinen anderen funktionsaufruf in die else-case einfüge, dann stürtzt mein Kernel ab.
Das Problem liegt offensichtlich an einer GCC Optimierung. Wenn ich -O3 benutze, funktioniert der Code nicht, bei -O1 oder -O2 funktioniert er. Weiß jemand an welcher Optimierung das liegt? Ich würde schon gerne -O3 benutzen^^

11

OS-Design / Entwicklung eines JIT-Compilers

« am: 06. December 2005, 20:52 »

Ich entwickele gerade einen Java Compiler, den ich in den Kernel meines OS einbauen will. Dieser Compiler soll zur Laufzeit Java Code (also classfiles) zu x86 Code kompilieren und linken können. Er sollte selbst auch in Java geschrieben sein, und sich selbst kompilieren können, damit man ihn in nativen Code, wie den OS Kernel einbauen kann.

Vor einigen Wochen habe ich einen einfach Compiler für Java gebastelt, der jedoch nur Java zu NASM Code kompilieren konnte. Der neue Kompiler soll aber direkt zu x86 Code kompilieren können, und diesen linken können. Ausserdem ist er nicht grad gut gecodet^^;.

Hier gibt es meinen alten Compiler zum Download:
http://80.190.252.208/~os/aot.zip

Ich würde mich sehr freuen, falls jemand sich vom Compiler beteiligen könnte. Es werden eigentlich nur Java Kenntnisse, und Motivation erforderlich, um an dem Projekt mitzumachen.
Ich würde mich freuen, wenn sich der eine oder andere findet

12

OS-Design / Compileroptimierung

« am: 21. November 2005, 14:45 »

Ich schreibe im Moment einen Java-JIT-Compiler. Er funktioniert auch soweit ganz gut, erzeugt aber nur relativ zu dem was möglich wäre langsamen Code.

Problem an der ganzen Sache:
Java ist stackbasiert. Das heißt, z.B. die IADD (integer add) instruction pop zwei Parameter vom Stack, addiert sie und pushed das Ergebniss auf den Stack.

Ich wollte beim Compiliervorgang jetzt den Bytecode von Java in ein Code für eine virtuelle Maschine mit unendlich Registern umwandeln. Je nach Optimierungseinstellungen kann dieser Code dann weiter optimiert werden. (Inlining usw.) Dieser Code sollte dann zu x86 Code kompiliert werden.

Hat jemand noch andere Vorschläge für die Optimierung des Compilers?

13

Lowlevel-Coding / Frage zur FPU

« am: 20. November 2005, 18:10 »

Ich habe folgenden Code, der den Rest einer Float Division berechnen soll:

Code: [Auswählen]

fld dword [esp] ;operand 1 vom stack in st0 holen
fld dword [esp + 4] ;operand 2 vom stack in st1 holen
.calc
fprem ;einen teil der berechnung vornehmen
fstsw ax ;statusword nach ax
test ax, 10000000000b ;gucken ob die berechnung fertig ist (bit 10 nicht gesetzt)
jnz .calc ;wenn nicht, dann weiterrechnen
add esp, 4 ;einen operand vom stack popen
fstp dword [esp] ;ergebniss in den stack schreiben
Er funktioniert auch wunderbar, nur wenn ich ihn öfters aufrufe, dann liefert er falsche Ergebnisse, ich nehme an, das liegt daran, das der FPU-Stack überläuft.

EDIT: Scheint daran zu liegen, das der FPU-Stack überläuft, wenn ich noch ein fstp einbaue, funktioniert das ganze, gibts noch eine Möglichkeit, ein FPU-Register zu popen, ohne den Inhalt irgentwo hin zu speichern?

14

Lowlevel-Coding / 64 Bit Integer

« am: 16. November 2005, 15:42 »

Um den Datentyp long von Java in meinem JIT Compiler einzubauen, müsste ich wissen, wie ich signed 64 Bit Integer multipliziren, dividieren und den Modulo berechnen kann.

Addieren und Subtrahieren ist ja kein Problem, das kann man ja einfach so machen:

Addition 5 + 7

Code: [Auswählen]

mov eax, 5 ;low-dword des 64bit ints
mov edx, 0 ;high-dword des 64bit ints

add eax, 7 ;low-dword adden
adc edx, 0 ;high-dword mit carry adden

Subtrahieren geht auch ähnlich.

Multiplizieren macht der GCC so:
Multiplikation 5 * 7

Code: [Auswählen]

; in ecx ist das low-dword (enthält 5)
; in ebx ist das high-dword (enthält 0)
movl %ecx, %eax
movl %ebx, %edx
shldl $3, %eax, %edx
sall $3, %eax
subl %ecx, %eax
sbbl %ebx, %edx
Ich verstehe aber auch nicht wirklich warum.^^;;

15

Lowlevel-Coding / printf() Bug

« am: 02. October 2005, 00:00 »

Auch wenn das nicht gerade LowLevel Code ist, habe ich hier ein kleines Problem mit meinem printf () Code. Ich finde einfach den Fehler nicht, warscheinlich sehe ich einfach den Wald vor lauter Bäumen nicht.

Hier ist mein relevanter Code:

Code: [Auswählen]

// stdarg.h
typedef char *va_list;

#define va_start(AP, LASTARG) (AP = ((char *) &(LASTARG)))
#define va_end(AP)
#define va_arg(AP, TYPE) (AP += 4,  *((TYPE *) (AP)))

//debug.c
void kernelFormatString (char *fmt, va_list args)
{
char buffer[1024];
char *ptr = buffer;

while (*fmt != 0)
{
if (*fmt == '%')
{
fmt++;
if (*fmt == 's') {
char *string = va_arg (args, char *);

while (*string != 0) {
*ptr++ = *string++;
}
}
}else{
*ptr++ = *fmt;
}

fmt++;
}

*ptr = 0;


// debugOut gibt den string aus, debugOut funktioniert aber richtig
debugOut (buffer);
}

void kernelPrint (char *fmt, ...)
{
va_list args;
va_start (args, fmt);

kernelFormatString (fmt, args);

va_end (args);

}

void debugInfo (char *system, char *fmt, ...)
{
va_list args;
va_start (args, fmt);

kernelPrint ("(%s)", system);
kernelFormatString (fmt, args);

va_end (args);

}


Falls ich nun die Funktion so aufrufe:
debugInfo ("kernel", "ein string\n");
erhalte ich eine solche ausgabe:
"(<einige sonderzeichen>) ein string\n"
eigentlich sollte ich aber
"(kernel) ein string\n"
erhalten.
Die Sonderzeichen entstehen warscheinlich daraus, das irgentein Pointer auf eine falsche Stelle zeigt.

16

OS-Design / blubbOS Design

« am: 14. September 2005, 16:24 »

Hallo,
ich wollte hier mal mein OS vorstellen, und bitte um Kritik. Ich würde mich ausserdem über jeden freuen, der sich an dem OS beteiligen möchte, da es ein recht großes Projekt werden sollte, wenn ich alle meine geplanten Features umsetzen will.^^
Der Name blubbOS hat sich einfach daraus entwickelt, dass mir kein besserer eingefallen ist.^^;;;

Das Konzept von blubbOS ist es, ein flexibles Betriebsystem auf der Basis eines kleinen, sicheren und schnellen Kernels aufzubauen. Wegen dem flexibelen Aufbau ist es sowohl möglich, eine POSIX kompatibele API sowie eine moderne objekt-orientierte API zu unterstützen. POSIX wird darbei unterstützt, um Anwendungen wie GCC benutzen zu können. Die API von blubbOS ist jedoch nur ein unabhängiges Interface, das eigentlich nur die richtigen Treiber aufruft.

Hier eine Skizze über den Aufbau von blubbOS:

Code: [Auswählen]


KERNEL   HARDWARE  
         |        |
     TREIBER
        |         |
 POSIX  BLUBBOS API
     |                              |
POSIX-APPS     NATIVE BLUBBOS PROGRAMME

blubbOS hat eine Exokernel ähnliche Architektur. Es unterstützt Treiber sowohl als Module, als auch als Prozesse, wie in einem Microkernel. Im Unterschied zu monolitischen Kernel, laufen Treiber aber immer im Userlevel. Prozesse können auch ohne Treiber auf die Hardware zugreifen, falls sie Rechte dafür besitzen. In einem normalen System wird dieses Feature aber nicht oder nur bei bestimmter Hardware benutzt.

Hardware Abstraktions Modell:

Code: [Auswählen]


HARDWARE
     |  |  
     |  |  
     |  |           KERNEL
     |  |             |    |
     |  MODULE    |
     |    |                |
     |    |                |
     |    |                |
PROZESSE / THREADS

Der Kernel von blubbOS ist nur sehr klein gehalten und verwaltet nur folgende Bereiche:
- Speicher (Prozesse können pageweise Speicher anvordern; Shared-Memory)
- Prozesse (Prozesse sind in blubbOS die Resourcen, die ein Programm besitzt, in Form von Speicher, Filehandles, usw. (sofern das vom Treiber so implementiert wird, der Kernel verwaltet keine Files)
- Threads (Threads sind einem Prozess zugeordnet und haben einen eigenen Stack)
- Module (Module können geladen, und in alle Prozesse gemappet werden, so dass schnelle Treiberaufrufe über normale JMPs möglich sind. Als Module sollten möglichst nur die geschwindigkeitskritischen Codeteile geladen werden.)
- Interrupts (Sobald ein Interrupt auftritt wird an den Thread, der ihn handlet ein Signal gesendet. Eventuell wird der Thread auch direkt aufgerufen.)
- I/O (Der Kernel kann den Threads den Zugriff verschiedene Hardwareteile ermöglichen. Er greift jedoch nicht selbst auf die Hardware zu (mit Ausnahme von eingebauten Debugfunktionen und Speicher). Ein Thread darf nur auf einen Hardwareteil gleichzeitig zugreifen, und normalerweise ist nur Treibern der Zugriff auf die Hardware gestattet.)
- Eventuell sollte noch der V8086-Mode unterstützt werden, um das BIOS aufrufen zu können. (Noch nicht implementiert)

Die native API von blubbOS besteht aus verschiedenen Objekten. Ähnlich wie bei CORBA, unterscheidet die API zwischen Client und Servercode. Ein API-Aufruf besteht eigentlich nur aus einem kleinen Codestück, das den Aufruf an einen Server weiterleitet. Der Server führt die angeforderte Aktion aus, und leitet die Rückgabe an den Client weiter. Die Kommunikation zwischen Client und Server basiert darbei nicht auf einem bestimmten Protokol, kann also über Sockets, Pipes oder auch ganze normale Funktionsaufrufe (sofern der Server auf dem gleichen Rechner befindet, wie der Client.). Die API soll möglichst alle von den Anwendungen benötigten Funktionen abdecken, so dass die erstellten Programme eine große API benutzen, statt auf viele verstreute Module zuzugreifen. Das umfasst File-IO, IO mit verschiedenen Geräten, GUI, Netzwerk, Datenverarbeitung (z.B. XML), Sound, Grafik, verschiedene Funktionen wie REGEXP usw.

Eventuell sollte auf dieser Basis auch noch eine .NET ähnliche VM bereitgestellt werden, um eine noch größere Sicherheit zu gewähren. Mit einem JIT Compiler sollte die Geschwindigkeit ja auch nicht sooo stark dem nativen Code hinterherhinken.

Der Kernel ist in C geschrieben, die Sprache für die anderen Teile steht noch offen, wobei ich auch stark zu C tendieren würde, da dass einfach am schnellsten ist.
Die Enduser Programme würden dann wohl die VM benutzen, nicht blubOS-Native Anwendungen sollten aber auch ohne die VM laufen, und POSIX benutzen können.

Der Kernel unterstützt bereits alle oben beschriebenen Features. Die nächsten Schritte werden sein, grundlegende Treiber zu entwickeln (VFS, HD/FD Treiber, Grafiktreiber). Danach sollte die POSIX API (zumindest die grundlegenden Teile, sodass GCC und evt. Bash läuft) umgesetzt werden. Danach kann man sich an die native blubbOS API machen. Sobald die soweit ist, kann man dann eine VM und einen JIT Compiler programmieren.

Bei der Lizenz hatte ich an GPL gedacht, ich denke, für dieses Projekt hat sie eigentlich garkeine Nachteile. Das Änderungen veröffentlicht werden müssen ist ja wünschenswert, und die Treiber usw. müssen ja eh nicht GPL sein, da sie ja keinen Code direkt verwenden und sich nicht im Kernel befinden.

Den Kernel werde ich wohl in einigen Tagen mal online stellen.^^

17

Lowlevel-Coding / Dynamisches Linken von Elf Executeables

« am: 19. August 2005, 14:12 »

Hi,
Kennt jemand ein Tutorial oder eine Seite, in der beschrieben wird, wie das dynamische Linken von Elf Files funktioniert? Ich habe mir die Dokumentation schon angesehen, ich verstehe aber nicht wirklich, was der dynamische Linker alles machen muss.

mfg,
SSJ7Gohan

18

Lowlevel-Coding / Real Time Clock unter Bochs

« am: 14. August 2005, 20:06 »

Ich wollte mir einen Treiber für die Real Time Clock schreiben. Laut einigen Tutorials müsste ich dazu nur Bit 6 des CMOS Statusregisters B auf 1 setzen.
Unter Bochs werden danach aber immernoch keine Interrupts generiert.
Hier ist mein Code:

Code: [Auswählen]

char byte;

outByte(0x70, 0x0B);
byte = inByte(0x71);
byte |= 0x40;

outByte(0x70, 0x0B);
outByte(0x71, byte);
Ist noch irgentwas nötig um die Realtime Clock zu nutzen?
Leider kann ich mein OS gerade nicht auf realer Hardware testen

19

Lowlevel-Coding / Parallel Port

« am: 13. August 2005, 22:04 »

Hi,
ich wollte den Parallel Port nutzen, um über Bochs in die Parallelport Logfile Debuginformationen auszugeben. Wie kann ich das realisieren? Kennt jemand Tutorials dafür?

Mein bisheriger Code sieht so aus:

Code: [Auswählen]

char *ptr = text;
while( *ptr != 0 ) {
outByte( 0x378, *ptr++ );
}

Leider funktioniert das nicht :/
Ich bräuchte den Parallelport wie gesagt nur, um über Bochs Informationen auszugeben.

20

OS-Design / Implementation von Kernelmodulen

« am: 20. June 2005, 21:19 »

Hio,
ich habe einen Microkernel, der die Prozessverwaltung und das Memorymanagement übernimmt. Jetzt möchte ich Kernel-Module laden und entladen können die dann in alle Prozesse gemappt werden und vom Kernel über einfache Calls aufgerufen werden sollen. Ich möchte die wichtigsten Treiber nicht als eigene Prozesse laufen lassen, da das die Performance erheblich beeinträchtigen würde.
Mein Problem liegt gedoch darin, wie ich die Kernel-Module laden und ausführen soll:
Normalerweise werden die Programme ja so gelinkt, das sie im Speicher an einer bestimmten Stelle stehen (Text Segment beginnt bei 0x12345 usw. ). Bei den Kernelmodulen weiß ich jedoch erst zur Laufzeit, wohin sie geladen werden. Wie ist es also möglich, sie zu laden? Ich müsste sie ja zur Laufzeit dynamisch linken, weiß jemand, wie das geht? Oder gibt es noch andere Möglichkeiten, die nicht allzu stark die Performance beeinflussen?

mfg,
SSJ7Gohan