OSDev.org

I'll start a new thread and explain my idea, and see if anybody else thinks this is a good idea.

Providing an user-friendly environment:

• There should be no requirement for the end user to learn any configuration scripts (although advanced users might be able to fine-tune configurations)
• The end user should not be required to build anything, and should not need any kind of compilers preinstalled
• The bootloader should be available as ISO-files, floppy images, or be bundled with graphical setup tools for popular OSes (Windows, Linux), that requires no deep knowledge about disk-layout to install

Providing an OS friendly environment:

• The OS should be able to decide which mode it wants to be invoked in (for example real mode, protected mode, long mode).
• The OS should be passed memory information, but will not intrude in any other way with OS-typical tasks

Boot environment:

• Will be put in MBR sector
• Will support automatic detection of boot sector identities for popular OSes
• Will support automatically locating multiboot and own boot headers from roots of partitions on all available devices
• Will let the end-user fine tune the configuration in an interactive process

Hi,

rdos wrote:I'll start a new thread and explain my idea, and see if anybody else thinks this is a good idea.

Providing an user-friendly environment:

• There should be no requirement for the end user to learn any configuration scripts (although advanced users might be able to fine-tune configurations)
• The end user should not be required to build anything, and should not need any kind of compilers preinstalled
• The bootloader should be available as ISO-files, floppy images, or be bundled with graphical setup tools for popular OSes (Windows, Linux), that requires no deep knowledge about disk-layout to install

Providing an OS friendly environment:

• The OS should be able to decide which mode it wants to be invoked in (for example real mode, protected mode, long mode).
• The OS should be passed memory information, but will not intrude in any other way with OS-typical tasks

Boot environment:

• Will be put in MBR sector
• Will support automatic detection of boot sector identities for popular OSes
• Will support automatically locating multiboot and own boot headers from roots of partitions on all available devices
• Will let the end-user fine tune the configuration in an interactive process

Why not just use GRUB?


Cheers,

Brendan

Brendan wrote: Why not just use GRUB?

Because the above list is what GRUB cannot do today. It doesn't come on ISOs, or with installers, it cannot live without configuration files and scripting, and it cannot handle OS requests about operating mode.

In order, what how grub does (or doesn't do) your points.

1. This can be hidden by the OS developer (see grub.d on Ubuntu)
2. Binary packages, common on linux distros (so, same as above)
3. Grub2 can do that (I have liveCDs booted from my USB disk)

4. One thing lacking, but that's because long mode is harder to leave in a config that the booted OS can just use, and real mode is rarely needed after early boot (especially when the loader passes memory maps and graphics information)
5. See above, multiboot can pass a memory map (I use this myself)

6. Yeah, grub is a little large, but it can be pared down at install-time
7. Seems a litte bit non-extensible, why not just chainload them (again, grub does this for windows)
8. Interesting idea... but a little expensive (disk IO at boot time should be kept minimal), and iterating over a potentially huge root directory reading the first 64K of each file will add up.
9. GUI configuration app? Again, this is a point for the OS developer, the loader should only need to understand its configuration file. Most grub versions can do runtime reconfiguration (but it does involve editing command lists, but that's because it's a) simpler, and b) a more power user option)

thepowersgang wrote:In order, what how grub does (or doesn't do) your points.

1. This can be hidden by the OS developer (see grub.d on Ubuntu)
2. Binary packages, common on linux distros (so, same as above)
3. Grub2 can do that (I have liveCDs booted from my USB disk)

Only within the Linux environment. If you want your own OS to be dual-booted with Linux, there is no way of doing it without editing configuration files. In Linux with Grub 2, you even need to know how to update the configuration as this is not done by editing the file alone as in GRUB legacy.

thepowersgang wrote: 4. One thing lacking, but that's because long mode is harder to leave in a config that the booted OS can just use, and real mode is rarely needed after early boot (especially when the loader passes memory maps and graphics information)

I wouldn't agree with that. GRUB basically assumes the kernel is a 32-bit flat image (default in ELF-format), and those assumptions are violated by real-mode OSes, non-flat protected mode OSes and long mode OSes.

thepowersgang wrote: 7. Seems a litte bit non-extensible, why not just chainload them (again, grub does this for windows)

The user can do this only if:
1. The user knows where the configuration file is located
2. What the syntax for chainloading is
3. Which disc and partition Windows is on (and what this notation is in *nix syntax)
4. In the case of Grub 2 on Linux, the user knows how to update the boot-configuration

thepowersgang wrote: 8. Interesting idea... but a little expensive (disk IO at boot time should be kept minimal), and iterating over a potentially huge root directory reading the first 64K of each file will add up.

This only needs to be done when there is no established configuration. An alternative could be to provide this as a tool that creates a decent menu.lst file that contains all bootable modules on first startup, and then letting the end-user remove or rename these entries (possibly also scanning sub-directories on demand).

Hi,

The first reaction to this is the same as Brendan's - why not just use GRUB?

I've frequently been disappointed with the quality of bootloaders out there and working on a new, user friendly, reliable bootloader may seem a good idea. However, a "user-friendly" bootloader seems a bit redundant: users who are happy messing with config scripts are likely to want to use something that lets them tinker, like GRUB. Are there many users out there who are not happy with editing basic config scripts but do want to run a system with multiple OSes? I'm not convinced that the target audience will be very big.

The second thought is that GRUB2 is modular for a reason - anything which can detect and automatically select correct boot devices, CPU modes etc... is likely to be huge and slow, when we're in an era of computing where users expect fast boot times (if not instant-on) due to tablet computing, smartphones etc... Even adding a couple of seconds to a desktop PC boot is likely to be unacceptable.

Cheers,
Adam