Ok, so I have persuaded NetBeans to start a new project, and I've rewritten the example OS's multiboot header code, and wired in my Grub-Bochs image.
It now compiles the (noddy) kernel, links it into an ELF binary, and loads Bochs so Grub can load the kernel.
I'm considering how modules, libraries and executables will load as I want to take this opportunity to separate them from the kernel completely.
I think I understand now what crt0.o does in the grand scheme of things. When you write a program, you start your program with a "void main()" and stuff like "stdout" already exists and stuff like "printf" works. When your executable is first loaded, the OS actually passes control to the crt0.o section in your program (the start() function). This routine (which is part of the toolchain which builds programs specifically for that platform) then uses some platform-specific voodoo to get references to things, it gets a reference to the environment somehow, it gets some library to power write() and open(), and generally sets up stuff that the C library will need to operate.
Now, I imagine I'm going to end up with two different types of entity, Executables and Libraries.
An Executable will be loaded into memory, a new thread (or process) will be created, and sent in to the start address of the executable. If this is a C toolchain program, it'll land in crt0.o and start the process. If it's a seat-of-the-pants assembly marvel, it will do something else.
When the program exists, either by calling an Exit() function or by the main thread leaving the building, the process will end, and the memory for the program will be freed.
This can all be achieved by me creating a crt0.o as part of my C library, and compiling programs as normal. They'll run and won't know the difference.
A Library on the other hand, is slightly different. It will be loaded into memory, and will present a set of entry points. It won't have a main thread or process given to it, and it won't have a defined exit point.
I imagine that all libraries will need some form of Open() entry point so that the C library linked into the library can connect all of its functions to the basic kernel functions. I guess it must be like a crt0.o, but it won't set up stdin or stdout, and it might not look to call the main() function once it's finished (although it may call a further initialise() in the library code itself, in case it needs to open further libraries or do other set-up).
Beyond that, the libraries could just be ELF .o files (which have no unresolved symbols) and just has symbols exposed which are its entry points.
(I'd have to investigate how to make a linked .o file with specific symbols exposed and others not (public vs. private) )
This all comes down to whether the device drivers should be executables or libraries. I suspect the answer is that they should be libraries, and will be loaded in the kernel memory space (for the moment) but some of the drivers may launch a new kernel thread in their initialise.
So. A device driver is a library. The kernel will have to be told to load it at some point (possibly by a driver list file, possibly by some form of probe program). The library will be loaded and will have its Open() method called (as all libraries will). I guess the open code will register the device driver with the kernel, or I guess it could start probing the system for compatible devices.
In the Amiga world, the device driver library would be a normal library but with some specific entry points to make it into a driver and then it's loaded especially as a driver ( http://amigadev.elowar.com/read/ADCD_2.1/Libraries_Manual_guide/node029E.html ).
I think the device drivers are going to work in a similar manner. The Device driver will be a library (ELF .o file) and will be loaded into the library list, .... (thought interrupted) ...
No comments:
Post a Comment