4. Eigenes OS?

Eigenes OS?

  • ?

    volkard schrieb:

    nur ein kleines beispiel: ich bekomme als spielstandslader oder compilerbauer vom bs (win oder linux hier echt gleich) per filemapping daten hereingeschubst. Shade nannnte es dieser datenhaltung diesbezüglich afair NonCopyStrings, ich splitte bei zum beispiel immer bei \n und habe "zeilen", die aus struct{char *begin,*end} bestehen. das bs gibt mir einen bei read() z.B. 8K großen sektor un ich gebe ihn zurück, wenn ich ihn nicht mehr brauche.

    hört sich gut an. eine proprietäre high-speed datenschnittstelle zwischen OS und user-mode hat vorteile, z.b. wenn irgendwann netzwerkprotokolle, filesystems, etc. dran sind, die dann bequem im userspace laufen könnten, was der stabilität des system zugute kommen würde. knackpunkt ist aber das zurückgeben der buffer ans system, es wäre ja doof, wenn die anwendung das vergisst und der kernel irgendwann 'out of memory' ist.

    volkard schrieb:

    hihi, ich möchte nicht in deinen schuhen stecken.

    ich auch nicht, aber erhard hat durchhaltevermögen und auf den kopf gefallen ist er auch nicht.
    🙂

    0
  • E
    Mod

    Danke für den interessanten Einwurf. 🙂

    hihi, ich möchte nicht in deinen schuhen stecken.

    Das Problem ist, dass alles miteinander vernetzt ist, aber so ist es nun einmal.

    0
  • ?

    Erhard Henkes schrieb:

    Das Problem ist, dass alles miteinander vernetzt ist, aber so ist es nun einmal.

    deswegen sollteste frühzeitig das ganze in überschaubare teilkomponenten zerlegen, KISS-prinzip, teile und herrsche und so.
    🙂

    0
  • V

    Erhard Henkes schrieb:

    hihi, ich möchte nicht in deinen schuhen stecken.

    Das Problem ist, dass alles miteinander vernetzt ist, aber so ist es nun einmal.

    hihi, ich möchte nicht in deinen schuhen stecken.

    0
  • E
    Mod

    deswegen sollteste frühzeitig das ganze in überschaubare teilkomponenten zerlegen

    Genau dies werde ich versuchen, soweit das möglich ist. Paging, Heap, Task Switching, User Mode vs Kernel Mode, Syscalls, VFS sind solche Einheiten, die allerdings zum einfachen Begreifen teilweise zu groß sind. Da versuche ich gerade, Unterelemente als elementare Module weiter heraus zu schneiden.

    Noch wichtiger ist die Visualisierung / Verständlichmachung dessen, was passiert, wenn man dies oder jenes ändert, weil viele Leute beim Verstehen und Begreifen eher praktisch an die Dinge heran gehen.

    ..

    Der Schwachpunkt von PrettyOS besteht momentan noch darin, dass noch kein Fileformat festgelegt wurde (jedoch kein Problem) und noch kein Mechanismus zum Übertragen von "Files" (Laden/Lesen Schreiben/Speichern), z.B. aus der RAM Disk in den Speicher und umgekehrt existiert. Sobald diese Mechanismen funktionieren, komme ich auf dieses Thema "proprietäre high-speed Datenschnittstelle zwischen OS und User Mode" zurück. Es geht nichts verloren. Wie sehen die entsprechenden Pendants bei Linux und Windows genau aus, damit ich das im Detail studieren kann?

    0
  • V

    Erhard Henkes schrieb:

    Wie sehen die entsprechenden Pendants bei Linux und Windows genau aus, damit ich das im Detail studieren kann?

    win haste ja schon gefunden. bei linux heißt die schlüsselfunktion mmap http://linux.die.net/man/3/mmap

    0
  • E
    Mod

    Danke! 🙂

    0
  • ?

    Erhard Henkes schrieb:

    Wie sehen die entsprechenden Pendants bei Linux und Windows genau aus, damit ich das im Detail studieren kann?

    http://www.i.u-tokyo.ac.jp/edu/training/ss/lecture/new-documents/Lectures/
    unter: 10-LPC. auch der rest, z.b. memory management, dürfte dich auch interessieren.
    🙂

    0
  • E
    Mod

    @+fricky: Danke für den Link!
    Momentan interessiert mich dies hier am meisten, da ich davon bisher nur einen Bruchteil habe, und mir genau der Rest fehlt: 😉
    http://www.i.u-tokyo.ac.jp/edu/training/ss/lecture/new-documents/Lectures/02-VirtualMemory/VirtualMemory.pdf
    PrettyOS muss aber nicht wirklich performant sein, sondern vor allem verständlich, eben als Experimentier-Plattform geeignet. Ich bin mir noch nicht sicher, ob mir das gelingt, hängt davon ab, inwieweit mir geeignete Visualisierungs-Funktionen für die einzelnen Module und Exceptions gelingen.

    Gibt es eine Übersicht, wie man weitere Infos aus Registern erhält, um Exceptions möglichst vollständig zu analysieren? Dann könnte man diese Funktion, die bisher nur Page Faults genauer unter die Lupe nimmt, weiter ausbauen:
    ..
    r->err_code und das Register cr2 dürften wohl der Schlüssel dazu sein. Wenn man beim "Spielen" mit dem Code in ckernel.c auf eine Exception trifft, sollte man heraus finden können, was man eigentlich falsch gemacht hat. Das ist momentan noch nicht ausreichend gegeben. Das ist aus meiner Sicht noch das Hauptproblem.

    0
  • ?

    English, my German is not very well.

    Try to create some code for installing fault handlers, so each fault handler does have its own function. Check if a custom handler is installed, and execute it. If not, write down a message on the screen and halt CPU (cli, hlt, for(;;);)
    Keeping them apart this way like, is very handy for dynamically installing and removing handlers. Also, when having a Virtual86Mode implemented, you will need #GP (general protection fault) very often, and write some big routines for it.

    for the Debug and Break exception you can write some nice simple handler. Just dump all registers given as argument in function call.

    The Page Fault handler:
    Receive the CR3 AND CR2. CR2 contains faulting address. CR3 the PHYSICAL address of the page directory. Then, split the faulting address in some parts.
    PageDirectoryIndex (cr2 >> 22, when using 4kb pages on a 32-bit system)
    PageTableIndex ((cr2 >> 12) & 0x3ff)
    PageOffset ((cr2 & 0xfff), not necessary for now)

    Then, when page was not present, check the PDE for present bit, then the existence of the PageTable (PDE->frame << 12 and then to virtual), then present of PTE, and then existence of the page mapped to the PTE. (PTE->frame != 0x0)

    Solve any of these things, but keep patience: be sure caller should be able to write or read something at the address in cr2.

    When having r/w (read/write) page fault and is present, kill the process. It is trying to access kernel space. Same way with u/s (user/supervisor).

    When looking at the Intel Manual, we see that there is NO ID bit in the error code of a #PF (page fault).
    Reserved, if problems with that, kill process. (or maybe just continuing is fine too)

    greetings, and success.

    // PHPnerd 😃

    0
  • E
    Mod

    @PHPnerd: thank you very much. 🙂

    0
  • P

    Keine Probleme. 😛

    I will look at this topic often to help here 🙂
    I am busy with kmalloc.

    The memory management part is the most boring, tricky and frustrating part of OS development.Don't quit 😛

    Also: be sure you always print out messages of exceptions, especially at the page fault exception. There shouldn't be ANY exceptions occur when programming kernel itself.

    // PHPnerd

    0
  • ?

    PHPnerd schrieb:

    There shouldn't be ANY exceptions occur when programming kernel itself.

    even if the kernel is 100% bug free, third-party modules (device drivers and similar stuff running in kernel space) can crash the system. erhard should implement an exception handling mechanism, so that common errors (like wild pointers, divison by zero, etc.) are handled properly.
    🙂

    0
  • P

    Yeah, but kernel itself (main routine, setting up paging) should 😛

    Writing div by zero handler. I think that should be setting return value to zero.

    so
    int a = 5/0;
    a will be zero, instead of killing process.

    // PHPnerd

    0
  • ?

    PHPnerd schrieb:

    so
    int a = 5/0;
    a will be zero, instead of killing process.

    no, that keeps the error. the error creeps forward and will cause weird behaviour of the whole thing. instead, exceptions should be 'handled' in a controlled manner (like this):

    ...
begin_guarded_section();
{
  ...
  int a = x/0;
  ...
}
if (get_exception_code() == DIV_BY_ZERO)  // enter exception handler 
{
  // deal with division by 0
}
end_guarded_section();  // stop guarding
...   // process will be killed at this point, if another exceptions occur

    ^^all can be done using c-functions. there's no need for a modfied compiler (like that is the case with structured exception handling under m$-windoofs).
    🙂

    0
  • P

    So, no kernelmode div by zero handler?

    Erhard: do not forget to invalidate the TLB. use INVLPG (see Intel manuals) or read CR3, and write it to it again.

    // PHPnerd

    0
  • ?

    PHPnerd schrieb:

    So, no kernelmode div by zero handler?

    of course, kernel must handle that, but must not terminate the application if an exception occurs inside guarded code. after that, the application should ask the kernel for exception code and (if there is one), retry the operation, notify the user, abort the program or something like that.
    🙂

    0
  • P

    All right, understand. But that is something for later on to me 😛

    // PHPnerd

    0
  • E
    Mod

    Yes, exception handling has to be fine-tuned in PrettyOS. Currently, there is only a message and a big stop sign. Page faults are already analyzed deeper.

    I worked on the VFS and the RAM disk, because it is very important to bring data, specialized kernel modules or user code into the memory of the OS. The way how it works now is as follows:

    1. produce a binary image from various files (with "make_initrd.exe", source code: "make_initrd.c"). I renamed the resulting image to "file_data.dat". This is the target for incbin in process.asm.

    2a) include it in process.asm with incbin, global addresses:

    ; data for ramdisk
global _file_data_start
global _file_data_end
_file_data_start:
incbin "file_data.dat"
_file_data_end:

    2b) Linker transfers it to the memory at &file_data_start

    1. The source code line
    k_memcpy((void*)ramdisk_start, &file_data_start, (ULONG)&file_data_end - (ULONG)&file_data_start);

    in ckernel.c transfers the data with the files to the RAM disk (this is the way we exchange data with PrettyOS at the time being)

    1. The Virtual File System (VFS) with individual file headers helps to access the files in the RAM disk

    Enjoy it! 🙂

    PrettyOS: http://www.henkessoft.de/OS_Dev/Downloads/36.zip
    Screenshot: http://www.henkessoft.de/OS_Dev/Downloads/ramdisk_test.png

    Currently the framework for booting, loading asm kernel, switch to PM and C-kernel, interrupts, write/read key queue, set system timer frequency (I use 100 Hz), paging, heap, virtual file system, RAM disk, multitasking, syscalls now basically work. 🙂

    0
  • A

    Erhard Henkes schrieb:

    Hier ein prinzipielles Beispiel mit Erzeugung mehrerer Tasks und Taskswitch:...

    Aha, jetzt wird's interessanter und praxisbezogener...

    0
Anmelden zum Antworten