first shared library

[mcheung63]

hi
tell me something about how your os load the *first* shared library?
thanks
from Peter (www.kingofcoders.com)

[samoz]

If you mean one that you write yourself, in C you can just write an #include statement.

[suthers]

If you mean one that you write yourself, in C you can just write an #include statement.

No, I believe that he is reffering to libs that aren't linked in at link time (DLL's in windows or .so in linux).
Jules

[Ready4Dis]

Well, I have an initial ramdisk that is loaded from my boot loader, my kernel is actually a shared library, which the bootloader runs first. The kernel then parses my initial ramdisk and loads the rest of my 'critical' libraries, after this, the rest can be loaded from disk using the drivers supplied in the initial ramdisk. The initial ramdisk is populated with the proper drivers for the device it's installed on, so pci scanning for an ide device, so it can find the ide controller, as well as my generic ata driver and file system driver, for floppy it is my fdc driver and fs driver, etc. Once I add support for USB, it would be the pci, usb, mass storage and fs drivers. It's a pretty simple method, but works for me, and solves the problem of how to load a file system or disk i/o driver without a disk driver or fs driver loaded . My kernel has a method for parsing and reading from the initial ramdisk (actually uses my VFS so the init ramdisk is read just like any other directory/file).


--- Edit ---
Oh, just wanted to mention, all my drivers are linked to their location and against my kernel once loaded, so they can directly access fucntions in the kernel, and are relocateable so I don't have to have them in specific places. Also, i have functions for finding functions by name in my drivers, so my kernel can find the proper functions to call depending on driver type (which is also stored in the driver, a structure containing basic info about the library, type sub-type, version and revision). I have a method to search for a driver based on any or all of the above information, so when loading/mounting a new disk, i search all file system drivers and check if they support the disk (by passing in the first sector of the disk to each driver).

[mcheung63]

Ready4Dis
OK, so for any os, the first shared library must be in a fixed location, like your os, your first shared library is located in the ramdisk, and the location is hard coded.

Does your os have a website? I want to put its introduction in my kingofcoders.com.

thanks
from Peter

[Ready4Dis]

Sorry, no website. And no, it does not have to be at a fixed location, it just typically is at a fixed location for simplicity. I use a fixed location in my OS, but it's not required. In your boot loader you can load it to any address and relocate the symbols, then jump to whatever location you loaded it at, which could be different at each load, or a known static address. I use a fixed location, I first load my ramdisk starting at 1mb physical, then I use paging to make it appear at 0xc0000000. My kernel code starts at location 0xc00000f0 due to my ramdisk header and coff file header, so i know where it starts (And where to link it in my linker script). All my other files are not at a known location due to the variable length of my kernel, so my kernel initializes my memory manager, then multitasking, then my virtual file system driver, and then initializes my ram disk, which appears in my root/dev/initrd directory. It then loads my InitDrivers.txt file which is just a listing of drivers to launch on bootup, and runs those drivers from my ramdisk (so it's easy for me to test drivers simply by changing the .txt file to run only drivers I want and updating my image file). All my drivers are not at fixed locations, just my kernel to make it easier for my bootloader to run. I am trying to keep my bootloader under 1k, it has to enable a20 (I try the most common 3 or 4 methods), find system memory and build a map, load my kernel image over 1mb area, setup paging, enable pmode, and jump to kernel. The kicker is, everything in the first 512 bytes is reserved for the specific boot medium, my second 512 bytes is the non-specific setup code, so when I compile for fat12, or fat32, the only part that changes is the first sector. Anyways, what exactly are you trying to do with loading your libraries, or are you just trying to find out for learning purposes?

[skyking]

hi
tell me something about how your os load the *first* shared library?
thanks
from Peter (www.kingofcoders.com)

Included in the kernel image. A pointer to a jumptable is provided to new processes as argument to the entry point function.

[Jeko]

Ready4Dis is your OS open source? If it's open source, can you send me your shared library loading code?

[lukem95]

My OS is going to use ELF .so's as its shared libraries.

Im about 75% done implementing them, it's quite easy, but i've lost count of the amount of times i've reread the bloody specification.

Theres a thread about it in "os theory" called "DLL's". I'd recommend reading it

[Ready4Dis]

Ready4Dis is your OS open source? If it's open source, can you send me your shared library loading code?

Umm... haven't really thought about it much, i don't have a website or anything setup. Alos, a lot of my code relies on other sources, so it's hard to just send my library code. Basically though, it's just some code that loads coff files, and supports relocations, pretty simple stuff really. Once the file is relocated, the information about symbols is updated, so when another application wants to find the "Init" function from a coff file, it simply calls CoffFindSymbol(Lib,"Symbol") and it returns the address of the symbol, or 0 if no match. If you really want the coff relocating and symbol searching code, let me know, i can send it (PM me), I think most of it doesn't rely to much on other stuff (mostly memory allocatino for the .bss and I can strip most of the other crap out, it relocates in memory, so that makes it simple).