loading modules

[redDot]

while implementing the file system, we give the command module /initrd.img , where imitrd.img is the filesystem file.
in the main to get the location of the loaded module we write,

Code: Select all

ASSERT(mboot_ptr->mods_count > 0);
    u32int initrd_location = *((u32int*)mboot_ptr->mods_addr);
    u32int initrd_end = *(u32int*)(mboot_ptr->mods_addr+4);
    placement_address = initrd_end;

and then we do identity mapping in the initialize_paging part...
wat exactly is happening, how does the kernel get to read the initrd.img file ? is the entire file mapped into the virtual memory while identity mapping ???

[JamesM]

Hi,

the "module /initd.img" command, given to GRUB, causes GRUB to load initrd.img to some point in physical memory. The place that initrd.img is loaded to is given in the multiboot header (that's what we're parsing in the lines of code you wrote).

When we initialise paging, we identity map virtual memory up to and including the loaded module.

[redDot]

so if i want to write a filesystem for the harddisk, then how will it be able to identity map the entire space (greater than 4GB) ?
also what will be the content of the initrd.img file in this case ? for sure it can't be of the size of the entire harddisk as tat won't fit in the floppy image...

[JamesM]

The initrd.img is an image file for an *initial ramdisk*. That is, a disk that goes directly into RAM. A Harddisk driver would communicate directly with the harddisk controller.

[redDot]

ok, so for harddisk reading, u saying that i will have to do it with the harddisk driver, then does anything needs to be loaded through GRUB ? i guess not...
n with initrd.img, wats this initial ramdisk ? after loading it, can i write new files into the initrd.img ?

[lukem95]

if you read the tutorial it explains it.

if you create your own fs implementation, then yes you can. Using JamesM's you cannot create/write, just read. Which should be adequete.

I think you should read the Ata specification, and write a HDD driver.

[redDot]

can i modify JamesM's implementation and add the codes to create/write files ? actually i tried to do it, by adding dummy data in initrd.img and then trying to write values into these dummy data through the kernel code, but ended up getting page fault ???
If the file initrd.img is getting identity mapped, this should not happen...

[AJ]

Hi,

I have the feeling that you may have followed the tutorial through without really understanding what is going on. As long as you stay within the bounds of the initrd, you should be fine. If you stray in to an unmapped page, you will have problems.

What is the value of CR2 after the page fault? If it's zero, you are trying to use a null pointer somewhere. Otherwise, is CR2 pointing to somewhere you think you should be reading from / writing to or is it a completely random address? Have you paged in the RAM disk as 'read only'?

To give you an example about the other query, my initrd is currently FAT12 (it won't stay that way, but it is at the moment). Because I am reading from a memory location instead of a physical floppy, this has allowed me to do two things:

1. Write a virtual floppy disk driver using the initrd as the target which is loaded by GRUB.
2. Write a FAT driver and get that all tested nicely *before* attempting to use it on real hardware.

Although the RAM disk is completely in memory, when writing to / reading from a hard disk, you would not expect to cache the whole thing - it is up to your VFS to cache directory structures as requred and your user apps to flush buffers when appropriate.

Cheers,
Adam