OSDev.org

I think it would be nice to have my file system have not only reserved boot sector but have reserved kernel sectors to shorten the code for loading the kernel. This gives you more room to do things with your bootloader.

But if the owner of your machine wants to test out a temp copy of a new kernel, how can they do it without overwriting the good, working kernel?
And what if those special disk sectors become corrupted? Do you have no choice at that point but to go back and boot from your install CD? It is nicer if you can have multiple kernels stored in your root directory.

It is dangerous to have only one place where something as important as a kernel can be stored.

bewing wrote:But if the owner of your machine wants to test out a temp copy of a new kernel, how can they do it without overwriting the good, working kernel?
And what if those special disk sectors become corrupted? Do you have no choice at that point but to go back and boot from your install CD? It is nicer if you can have multiple kernels stored in your root directory.

It is dangerous to have only one place where something as important as a kernel can be stored.

I agree, I simply have a function that requires the kernel be contiguous on the hard drive. I can store it at any location and load it. I could easily compile a new kernel, and boot into it, while not touching the 'old' kernel, if the new one doesn't work, i simply update the pointer in my boot loader to the old kernels location and i'm back to my working kernel. I currently only have bootloaders for fat12, fat16, fat32 and a custom FS, but there isn't much difference for the bootloaders (mostly just the fat info table), since my second stage does all the loading of stuff. The first stage just needs the correct format for the file system, and a function to read sectors from disk . My second stage uses that function to finish loading, so my first stage is very small/simple (so complex file systems have plenty of room to play with). Although not the optimal approach (since having sectors contiguous on disk isn't always easy depending on the FS, but for the majority it's pretty easy to write a simple case for small files to be contiguous, like FAT, just find a few entries that are free consecutiverly).

Hmmm, while implementing an ext2 filesystem driver, I decided my filesystem would be based off of ext2 (But adding and updating some things 64-Bit fields, no field splitting, Unicode Support, Journaling), which seems like a good idea to me. Anyway, one of the points I decided to change, was the way the the filesystem's header (Super Block) is structured, one piece of data I added, was the "kernel_inode", basically, what this is, is a direct pointer to the inode that holds the kernel/Kernel datablocks. (Can be set to any file using a syscall through VFS code). All the bootloader will have to do is find the partition, read "super block", and then it has everything it needs to find the inode.

Reserving sectors is a bad idea in my opinion, due to size expansion, if you're going to keep the kernel a static size, then maybe it'll pay off. But otherwise I can see it just being a pain.

Shalted wrote:Hmmm, while implementing an ext2 filesystem driver, I decided my filesystem would be based off of ext2 (But adding and updating some things 64-Bit fields, no field splitting, Unicode Support, Journaling), which seems like a good idea to me. Anyway, one of the points I decided to change, was the way the the filesystem's header (Super Block) is structured, one piece of data I added, was the "kernel_inode", basically, what this is, is a direct pointer to the inode that holds the kernel/Kernel datablocks. (Can be set to any file using a syscall through VFS code). All the bootloader will have to do is find the partition, read "super block", and then it has everything it needs to find the inode.

Reserving sectors is a bad idea in my opinion, due to size expansion, if you're going to keep the kernel a static size, then maybe it'll pay off. But otherwise I can see it just being a pain.

It's not a reserved sector, and my kernel can be any size, it is a 'normal' file in the file system, the only stipulation is that it's contiguous, and my file system driver has a way to make this happen. I may change it later, but it works fine, and my kernel can be any size at any location on the disk. My bootloader doesn't depend on the file system in any way, shape or form, so for example, if I wanted to change over to another file system, as long as I had a way to make the kernel contiguous on disk, I won't have to re-write anything but the file system header in my boot-loader, and no changes to my kernel at all, except point it to another FS driver. With your method, your bootloader needs a way to parse the inode info, and do a little bit of work, so if you were to change to another FS, you would have to re-write parts of your boot loader for each file system, where mine doesn't change. My boot code for fat12, fat16, fat32 is all the same except the fat header in the boot sector, and with fat32 i use lba instead of chs. I'm not saying my method is the greatest in the world by an means, but it does make it simple for loading (no parsing a file system) and supporting multiple file systems. If you don't plan on supporting many file systems, it's not an issue, I want my OS to be able to run on a multitude of file systems though, so this was the simplest way for me.

Sorry, that statement wasn't directed solely towards you, but more towards the topic of the thread it self.

I think it would be nice to have my file system have not only reserved boot sector but have reserved kernel sectors to shorten the code for loading the kernel. This gives you more room to do things with your bootloader.

Although Ready, I am curious, how do you manage to keep files from becoming fragmented in your system? Anyway, parsing the Inode data isn't too bad, as long as you have a little knowledge of the ext2 filesystem structure . The Wiki should probably be updated with all the structures, and the Directory Information data (Unless it already has been).

Shalted wrote:Sorry, that statement wasn't directed solely towards you, but more towards the topic of the thread it self.

I think it would be nice to have my file system have not only reserved boot sector but have reserved kernel sectors to shorten the code for loading the kernel. This gives you more room to do things with your bootloader.

Although Ready, I am curious, how do you manage to keep files from becoming fragmented in your system? Anyway, parsing the Inode data isn't too bad, as long as you have a little knowledge of the ext2 filesystem structure . The Wiki should probably be updated with all the structures, and the Directory Information data (Unless it already has been).

Right now, I have code to find contiguous space in a fat partition based on the total file size being copied. It can write files non-contiguous (like if the size isn't known, or contiguous space for the file doesn't exist). The parsing of the inode data isn't bad, but it does make your bootloader a bit bigger and more specific. Of course, my way makes the file system code a bit more difficult, but the bootloader simpler, so it's a tradeoff. A good thing about it though, is it's code that doesnt' reside in memory when not being used, and it is useful in the actual OS for things that require more speed while reading/writing. For example, if I know the maximum size of a swap file, I can find a contiguous space for it on bootup, and it'll be much better than a noncontiguous swap file . The code would be much simpler, and I wouldn't have to rely on the FS driver for read/writing to the swap file, I could just read/write raw sectors based on it's starting sector using the disk driver, a lot less parsing and checking, no need to store the fat table entries for it in memory, or have an open handle, so it saves a bit of memroy and function calls. I mean, that's something that *may* be implemented, but nothing I've seriously considered yet.