[openbeos] Re: x86 boot loader milestone
- From: Michael Phipps <mphipps1@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Thu, 22 Apr 2004 14:46:05 -0400
On 2004-04-21 at 23:29:59 [-0400], Commander Sozo wrote:
> I gotta admit, when I talked with you about a month or so ago your comments
> on what you were doing did help direct my ideas :) Here's what just came to
Aw, shucks. :-)
> mind that I was wondering if it was feasible. It's possible and rather easy
> now to make an image of a drive or a filesystem. Is it possible, however, to
> create an image of RAM? Given that there is the AGMS RAM filesystem, I think
> it should be possible. If so, would it be possible to boot the system until
Yes, this is possible in a kernel module, I think. It could be a little tricky
and might require more access to things than we had with Be's kernel. Not 100%
sure. But it is theoretically possible. Drivers would be a pain. Loading it
could be a little trickier - you would need a custom boot setup. Axel will tell
you how much fun those are.
> the instant before the UserBootscript is processed, and take an image of the
> current memory contents and store them on the CF card? That way, when the
> system boots, instead of re-loading things from the boot drive, etc it can
> restore the memory contents and pick up where it left off (process
> UserBootscript, etc). Of course, there would have to be a check of some sort
> before the RAM image dump happens so that in case something changes and needs
> reprocessing it can be done. DHCP, device detection, and things of that
> nature will have to be done after the RAM image restore. Anyway, it's just a
> random idea I had, there may be enough things that must be detected and
> re-configured every boot that makes this system have no practical use. But
> some things always are loaded into memory (kernel parts, app_server parts,
> tracker parts, etc etc), and they may benefit from this.
The truth is, as fast as BeOS (esp off of compact flash) boots, there is little
benefit to doing this. You might save a whole second or something.
Investigating a faster BIOS (i.e. LinuxBios) makes a whole lot more sense, from
a "speed up the boot process" point of view, than looking at this. I considered
the same things but don't think that it is worth bothering with. That's just my
POV on it.
OTOH, I think that this could be a huge feature if it had nothing to do with
bootup. How cool would it be if you could hit some key combo and the system
would freeze for a few seconds, pouring data onto the HD. When it was done, you
would have a complete, bootable image of exactly where you where at that
moment? Not to save boot time, but for other things - like saving all of your
apps exactly where they were. This would also work better than a boot setup
because you would restore user processes, not kernel processes. Things like
drivers need to init properly. You can't have an image do that without special
knowledge. OTOH, if you boot to a normal (open)BeOS kernel with new driver
instances and all, then restore the userland processes, that might work better.
Other related posts:
