Em 02/07/2009, às 09:47, "Ingo Weinhold" <ingo_weinhold@xxxxxx> escreveu:
Use the source, Luke! :-)
By looking at the loader source it looked like a way of having nested BFS volumes in the form of a disk image somewhere. I didn't look at the add-on source, indeed. Will do.
I guess Axel misread you, probably due to your "funny" remark. At least that was almost prompting me to reply something similar.
Okay, my bad choice of words. As usual.What I meant to say is that as a developer I found it amusing because the interface leaked the implementation details. I'm a geek. :P
Strictly on the shoes of a user, though, one would be left perplexed if the loader is executed but no volumes are found and it doesn't print a message regarding the source of the problem. If the user doesn't know any better, that could, say, be blamed on the ATA/IDE stack, because that's the most discussed issue regarding not being able to find bootable volumes, and the most likely type of hits one would get if searching for boot issues.
So, yes, the boot loader tries to recognize partitions and it can only boot from one that it recognized. And although the boot loader has been loaded from the would-be boot partition, it still has to find the partition, since the stage one loader by which it had been loaded previously had no clue about partitions, just an offset to the boot partition, which at some point has to be translated to an actual partition description.
May I propose a small (I'm guessing) change with broad ease-of- adoption consequences, then? Let the system be loaded from a volume defined only by its disk offset and superblock description.
This way, as long as the volume isn't corrupt, the system would be resilient to partitioning software running amok, or lost extended partitions, or what have you. It could conceivably allow booting Haiku from otherwise unpartitioned space, which would be very convenient for when you already have four PRIMARY partitions defined (which since XP is done easily, and also a common scenario for non-Windows users) and can't easily repartition due to how IBM-PC-style extended partitions are chained and require an extra description sector per-logical- partition that you might not have any space left to define unless you both shrink *and* move a partition forward into the disk, which could be extremely time-consuming.
Allowing booting from "unpartitioned" space lets one simply shrink an existing partition, which is much, much easier on Linux, Windows and just about any OS that can do it. Then it would be just a matter of dd'ing a raw volume at the right place and adjusting the offset on stage1. It could conceivably allow booting from a contiguous file, too, but those are harder to produce consistently among OSs, not even considering FS fragmentation.
I have a faint idea where to start, and since booting from GPT was much much easier than I thought it would be as you guys had done all the heavy-lifting already, I could look into tackling this after integrating the scheduler.
But first I'd like to know if you you guys even like this idea at all. Cheers, A.
