OSDev.org

Not sure how to describe this thread. I load the entire disk at boot and store the address of the kernel and call it to go to main. Is it reasonable to assume that:

01. Any other file on disk would be in memory.
02. That file would be located directly after my kernel in memory.

there would be only one other file on disk other than my kernel, both in root with no sub folders. thanks

Hi,

If you are using a disk format such as FAT12 or ext2, it would not be reasonable to make the assumption - you would need to look for the other file and load it at the point you want in memory.

If, on the other hand, you have deliberately written another file after your kernel (sector-wise) on the disk, then you could assume its location. IMO, it would be better to use a disk format so that you have exact file sizes, rather than blindly loading the entire disk in to memory.

Cheers,
Adam

jake12 wrote: 01. Any other file on disk would be in memory.

you have loaded the entire disk, so it is.

jake12 wrote:
02. That file would be located directly after my kernel in memory.

that depends on how your fs implemented.is there memory align or file align,or the vaule of them are equal?
If so, then it does.

So, it would be in memory and I could literally search for it in memory if I wanted, but it is best to simply search the sectors for it and load it where I know it will be once I am inside my kernel? It would be FAT12.

Hi,

It depends what the file is. If it is an essential module used at load-time, you will want your bootloader to place it in memory for the kernel. If it can be added later, the kernel could do the work.

Generally with FAT12, you load a copy of the FAT, the root directory and that is enough to search for any file. I guess you are on an emulator at the moment, but loading an entire physical floppy disk in to RAM will make the boot time of your OS looooong! When you start using a USB drive/CD/Hard Drive, you won't want to load the entire disk in to memory then, either.

Cheers,
Adam

It is essential to the OS as far as its usefulness is concerned, the OS will run without it however. In an emulator it is long, about 2 minutes to load 2880 sectors, on real hardware it loads in about half that time. Did you expect a higher figure? I suppose I can load it as a ram disk behind my kernel during boot which would save me from writing a fat12 driver in pmode. I'll give it a shot. thanks

Hi,

jake12 wrote:Not sure how to describe this thread. I load the entire disk at boot and store the address of the kernel and call it to go to main. Is it reasonable to assume that:

If you load the entire disk into memory (e.g. for a 100 GiB hard disk you load the entire disk from 0x0000000100000000 to 0x00000019FFFFFFFF) then:

• If the disk uses some sort of file format (e.g. FAT, ext2, etc) and was created using normal tools under another OS (e.g. "format", "copy", etc), then:
  • You can't assume that any file will start at any specific address in memory, and
  • You can't even assume that the sectors used by any file are contiguous
• If the disk is created by your own tool/s, then you can assume anything that your tool/s guarantee. For example, if your tool/s guarantee that the boot sector will be followed by the kernel (which will be followed by a picture of your grandmother), then you can assume that the boot sector will be followed by the kernel (which will be followed by a picture of your grandmother). However, even in this case you might not be able to assume that:
  • The disk doesn't contain trash left over from previous uses (data that wasn't overwritten by your tool/s).
  • Your OS won't waste a lot of time during boot, loading data from disk that is never needed.
  • The entire disk will actually fit in memory. For example, an 80386 with 2 MiB of RAM won't even handle a 2880 KiB floppy disk.

Cheers,

Brendan

Hi Brendan,

Point well taking. I decided that I would read only the amount of sectors that are needed to load the kernel which should be about 74 sectors which is about 1.9% of the capacity and well below any limitations you've described. I appreciate your input. thanks

Hi Brendan,

Did what you suggested and my OS now loads in less than 3 seconds. Thank you.