Re: Multiboot2 Suggestions

[Brendan Trotter]

Hi,

2010/4/21 Vladimir 'φ-coder/phcoder' Serbinenko <address@hidden>:
> Brendan Trotter wrote:
>> Where possible, I currently use the EDID information to determine the
>> physical size of the monitor (e.g. "520 mm wide and 320 mm high"), and
>> then scale font data, etc to suit; so that everything is the same
>> shape regardless of the monitor's aspect ratio, so that things aren't
>> too small on a small screen or too big on a large screen, and so that
>> everything looks the same in all video modes (resolution independent).
>> For an example, for a 1600*1200 video mode on a small 4:3 monitor I
>> might end up with 32*42 characters, for a 800*600 video mode on the
>> same small 4:3 monitor I might end up with 16*21 characters, and for a
>> 800*600 video mode on a large 16:9 monitor I might end up with 8*19
>> characters; and in all of these cases I can draw a square box (that
>> doesn't look like a rectangle in any case).
>>
>>
> Perhaps it's better to just supply estimated DPI?

Would "100 DPI" be tall and narrow, or short and wide?

If the boot loader supplied screen width and height (rather than EDID)
it'd work; but obtaining the EDID and then extracting the width and
height would probably be more work for the boot loader than just
supplying the raw EDID data (and potentially less useful to the OS).

>>>> Alternatively, (for my OS) for headless systems; I use RTS/CTS and the
>>>> VT100 "identify" command to detect if anything is listening on the
>>>> serial port (and if it's a terminal or something else). When nothing
>>>> is listening on the other end the OS can't talk so it uses the PC
>>>> speaker as a fallback (but continues monitoring the serial port).
>>>> Basically if something goes wrong at any stage, the OS beeps, and the
>>>> user can plug a terminal in afterwards to find out what went wrong
>>>> (rather than having no idea what caused the problem, then connecting a
>>>> terminal and rebooting to see if it happens again while they are
>>>> watching).
>>>>
>>>>
>>> I feel like here it's not anymore about present hardware or its state
>>> but about user configuration. Generally for this type of parameters
>>> command line is better suited.
>>>
>>
>> It's about "what does the OS do when it needs to tell the user there's
>> been a problem but can't talk to the user using the normal console/s
>> for any reason (regardless of what the normal console/s are and
>> regardless of what the reason/s may be)".
>>
>>
> If you put it this way it's configuration

Sigh.

There's only 2 types of "user configuration". The first type is really
"user preferences", where everything works regardless of which
preferences the user has setup (or even if they haven't set any
preferences). This sort of configuration is fine (as long as it's not
too excessive or intrusive, it's a good thing).

The second type of user configuration is "design failure"; where (due
to bad design) the user is forced to tell software something, and the
system can't work properly until/unless the user has been hassled. In
all cases this sort of configuration is bad. Unfortunately, in a lot
of cases it's unavoidable because the design failure was made by
someone else. An example of this is the keyboard layout for PS/2
keyboards - software can't autodetect the keyboard layout due to
design failures made by IBM several decades ago. Another example is
figuring out if the firmware's time is UTC or local time (and which
time zone).

The goal is to minimise the total amount of "design failure
configuration" for the system as a whole (not for any specific OS, or
any specific piece of software). For an example, it'd probably be
better if the firmware told all OSs which keyboard layout to use and
if the user told the firmware which keyboard layout (so the user only
needs to be hassled once when setting up the firmware, and not each
time they install any OS). The same could be done with the time - the
real time clock hardware could've been "always UTC" and maybe there
could've been a "time zone" firmware setting. In both of these cases
you're looking at "cascading design failure" - the original failure
caused by the design of the hardware, with a secondary failure caused
by the design of the firmware.

One way to minimise "design failure configuration" is the use of known
defaults for the expected case. For example, rather than the user
being forced to tell software that the real time clock is UTC or local
time, it might be reasonable for software to assume the clock is set
to UTC unless the user tells it otherwise. That way, if most computers
do use UTC then most users don't need to configure it.

Now, let's consider a potential scenario. Someone writes a multi-boot
compliant OS called "FooBarOS" (where "multi-boot compliant" does NOT
mean "complaint with some specific version of GRUB" - it means it
should work on any boot loader that supports multi-boot, whether it's
GRUB or not). Someone else puts "FooBarOS" onto a bootable CD, along
with GRUB and 3 other OSs (and a pretty menu, so the user can easily
choose which OS they'd like to boot/install). A normal user downloads
an image of this bootable CD from the internet and burns it onto a CD,
then tries to boot "FooBarOS". "FooBarOS" starts but realises it can't
talk to the user using the normal (video or serial) method or has some
other problem before it's able to use the normal method.

In this case, what does the author of "FooBarOS" do? Do they make
"FooBarOS" ask the user (how??) if it is allowed to return some sort
of error code to the boot loader? Do they use kernel parameters and
hope the person who made the bootable CD knows enough (and cares
enough) to get it right? Do they assume the OS can return to the boot
loader with an error code and then blame someone else when their OS
tries to return to the boot loader and crashes? Wouldn't it be nice to
avoid the "design failure configuration" entirely, and just make the
boot loader tell the OS if the OS is able to return to the boot loader
or not?

What about the PC speaker -  can "FooBarOS" ask the user (how??) if it
can/should use the PC speaker; or does the author of "FooBarOS" use
some sort of configuration and let whoever made the CD stuff it up; or
do they assume that the PC speaker can be used (even if the people who
make the bootable CD are using the CD as a free promotional thing
that's supplied with a range of computers that don't have a PC
speaker)?

For the PC speaker, the boot loader itself may not know if the
computer supports a PC speaker or not - it's unavoidable "design
failure configuration". However, the "design failure configuration"
can be minimised - you could rely on the boot loader's default (so
that most of the time nobody needs to configure anything), and if some
sort of "don't use the PC speaker" setting must be made then it only
needs to be made once for all of the OSs on the CD, not once for each
OS (and not each time any of the OSs are booted).


Cheers,

Brendan