dose any one have an idea of how to implement this into a bootloader? I want the boot loader to search the floppy drive (CD, or HD lator on) for my kernal, then load it into memory.
I'm thinking it would scan the drive media for a specific string that is in the very beggining of the kernal, then search for the EOF marker at the end of the kernal. It records the location on the drive where both those are found and then loads the file into memory.
thanks,
Spam
searching for then loading kernal from disk?
-
grey wolf
Re:searching for then loading kernal from disk?
this question was answered just a few threads below.
http://www.mega-tokyo.com/forum/index.p ... eadid=2150
http://www.mega-tokyo.com/forum/index.p ... eadid=2150
-
Mr_Spam
Re:searching for then loading kernal from disk?
i read that post, i guess i just didn't understand what the question was 
-
Tom
Re:searching for then loading kernal from disk?
I don't think that you'll have enough room to do that in a bootloader/sector...
-
Curufir
Re:searching for then loading kernal from disk?
Ok, I think I get what you mean, and its a bad idea and here's why.
First you have to run through every sector on the disk to find the first kernel sector even if your kernel isn't on the first partition. You have to do this by loading up each sector and testing for the magic string at the start of the sector. Now just by general randomness of bytes on your disk that string comparison is actually going to average more than one loop just to have a sector fail the comparison.
Once you've got that first sector things get even more interesting.
a) If the kernel isn't stored contiguously then you're screwed, you don't know where the next sector is to load. So you'd need a magic number at the start of every sector, which would require searching the entire disk for every individual sector (My spine runs cold at the thought)
b) Even if it is stored contiguously then if you haven't put the magic end string at a fixed place (Eg X bytes from the end of the sector) you have to do a string comparison starting at every byte in the sector, that's a minimum of 512 checks for every sector you load.
c) Now even if you've put the magic end string at a fixed place you have to check every sector you load for it(Back to the random thing, you'll always average more than 1 loop to fail a string test in these bulk situations). Imagine the slowdown having to do this for 20 or 30 sectors (And that's a small kernel).
Now imagine your kernel is occupying the last partition of a 30gb drive. I know we shouldn't allow ourselves to be driven by the demands of the end users, but even I think 2 hours is a bit much to load a 20k kernel
The one saving grace is that you could locate your kernel anywhere on the disk and still have it load, but the detriments far outweigh the benefits. Find yourself a nice filesystem, fat12 and ext2fs are simple enough to put into bootloaders. This will solve your problems much more nicely I think.
Incidentally, if I misinterpreted the question then I apologise, but someone's bound to think of the one I answered sooner or later so it's valid...I guess ;D
Curufir
and here's why.First you have to run through every sector on the disk to find the first kernel sector even if your kernel isn't on the first partition. You have to do this by loading up each sector and testing for the magic string at the start of the sector. Now just by general randomness of bytes on your disk that string comparison is actually going to average more than one loop just to have a sector fail the comparison.
Once you've got that first sector things get even more interesting.
a) If the kernel isn't stored contiguously then you're screwed, you don't know where the next sector is to load. So you'd need a magic number at the start of every sector, which would require searching the entire disk for every individual sector (My spine runs cold at the thought)
b) Even if it is stored contiguously then if you haven't put the magic end string at a fixed place (Eg X bytes from the end of the sector) you have to do a string comparison starting at every byte in the sector, that's a minimum of 512 checks for every sector you load.
c) Now even if you've put the magic end string at a fixed place you have to check every sector you load for it(Back to the random thing, you'll always average more than 1 loop to fail a string test in these bulk situations). Imagine the slowdown having to do this for 20 or 30 sectors (And that's a small kernel).
Now imagine your kernel is occupying the last partition of a 30gb drive. I know we shouldn't allow ourselves to be driven by the demands of the end users, but even I think 2 hours is a bit much to load a 20k kernel
The one saving grace is that you could locate your kernel anywhere on the disk and still have it load, but the detriments far outweigh the benefits. Find yourself a nice filesystem, fat12 and ext2fs are simple enough to put into bootloaders. This will solve your problems much more nicely I think.
Incidentally, if I misinterpreted the question then I apologise, but someone's bound to think of the one I answered sooner or later so it's valid...I guess ;D
Curufir