Multiboot2 Suggestions

Multiboot2 Suggestions

[Brendan Trotter]

Hi,

2010/3/28 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
> Also I'm aware that at least some people want more tags. Feel free to
> propose new ones.
> In short all ammendment ideas are welcome.

Here's my list.. :-)

1) If GRUB was using a serial port as a console device (e.g. on a
headless system) it'd be nice if the OS could continue using the same
serial port with the same configuration instead of resetting the
serial port, etc. A new tag (for 80x86, "8250/6550 compatible" serial
ports) would include base I/O port, the serial line configuration
(e.g. 8 data bits, no stop bit, no parity), the baud rate (e.g. 9600),
the IRQ number (if known/used by the boot loader) and the protocol
being used (ASCII, VT100, etc). If the boot loader doesn't know which
IRQ the serial port uses (e.g. it uses polling) then it sets the IRQ
number to 0xFFFFFFFF. Where the serial port has a different interface
(e.g. if the serial port uses MMIO or if it's not "8250/6550
compatible") a different tag with different fields are used to
describe it. The same idea should be used for any other console device
in future. For example, if a boot loader supports parallel ports or
"telnet+ethernet" or something in future then a new tag describing it
is created; and if a boot loader supports new protocols for existing
devices then they should added to the documentation (e.g. if a boot
loader supports a Braille terminal connected to serial port, then a
new protocol type is added to the existing serial port tags).

2) The "OS image format" information should be expanded, so that the
OS can tell the boot loader if it supports "8250/6550 compatible"
serial ports (and which protocols), and any other console devices (for
the same reason the "OS image format" already has flags, etc for
video).

3) There should be an (optional?) "critical error notification method"
tag that tells the OS which method/s it can/should use to tell the
user it encountered a problem before it was able to setup it's console
output. For example, can/should the OS return to the boot loader, or
use the "PC speaker" to beep, or make a PS/2 keyboard's LEDs flash, or
something else.

4) The section on "Machine State" is missing lots of information, and
needs to indicate the state of *all* hardware on all architectures
(regardles of firmware type). For example; for 80x86/PC it should say
that PCI devices are left in an undefined state (so that the boot
loader is not responsible for configuring PCI devices if the firmware
didn't for any reason), except for any PCI device that is indirectly
mentioned in the multi-boot information (e.g. if there's a serial port
tag then the OS can assume that serial port is configured, if there's
a video information tag then the OS can assume the video cards is
configured, etc).

5) The boot loader should always provide a "memory map". If the boot
loader is unable to get a memory map from the firmware then the boot
loader constructs a fake memory map from any/all information it can
find, including known areas that aren't RAM. For e.g. on "80x86 BIOS"
if "int 0x15, eax=0xE820" isn't supported, then other BIOS functions
are used to find usable RAM and the boot loader creates an entry that
marks the area from 0x000A0000 to 0x000FFFFF as "system" or "unknown".
The "mem_upper/mem_lower" tag should removed from the specification.

6) For any areas that aren't mentioned in the memory map, the OS can
assume these areas are safe to use when configuring memory mapped PCI
device's BARs. For 80x86 this means that if "int 0x15, eax=0xE820"
leaves holes in the area from 0x000A0000 to 0x000FFFFF (which is
almost always the case) then the boot loader creates entries that
describe these areas as "unknown", so that the area/s are mentioned in
the memory map and the OS doesn't assume the area can be used for PCI
devices.

7) The memory map needs more "area types". Any RAM that is reported by
firmware as faulty should use "area type 5" so that the OS can know
that some RAM is faulty, and (for e.g.) could tell a system
administrator about it. Also, "area type 0xFFFFFFFF" should be used
for "unknown", as this allows the OS to determine the difference
between "boot loader doesn't know what the area is" and "boot loader
does know what the area is but the area type is defined in a newer
version of the multi-boot specification".

8) Any RAM that is not immediately usable by the OS should not be
reported as "usable RAM" in the memory map. An example of this is the
"ACPI reclaimable" area (which is RAM that isn't usable until the OS
has finished using the ACPI tables). RAM used to store the multi-boot
information, RAM used to store the "kernel" and RAM used to store any
modules should be treated in the same way. I suggest using "area type
0xFFFFFFFE = RAM used for multi-boot information" and "area type
0xFFFFFFFD = RAM used for kernel/modules". This makes it much easier
to write a kernel's early initialisation code, because it can use RAM
without worrying about trashing data that is needed by the kernel/OS
later.

9) The "boot device" tag needs to be revised. If the firmware was not
"PC BIOS" it doesn't make any sense; and even if the firmware was "PC
BIOS" the OS is unlikely to care (and there's cases where the BIOS
device number still doesn't make sense if the OS does care - e.g. "El
Torito" boot CD emulating a floppy disk or hard disk). The "boot
device" tag should be removed, and (potentially) replaced by one or
more new tags that describes how the boot device is accessed - e.g.
one tag for "PCI_bus/device/function then controller_device_number and
partition", another tag for "PCI_bus/device/function then
protocol/IP_address/port", etc.

10) The word used for "kernel" should be changed. There is currently
no reason why the boot loader couldn't be used to load an extra (OS
specific) stage which in turn starts (one of) the OSs real kernel/s;
and no reason why the real kernel/s couldn't be loaded by the boot
loader as a module. Unfortunately, because the specification uses the
word "kernel" people who are new to OS development and/or multi-boot
make the mistake of assuming that "kernel" must be the OS's kernel. I
propose the world "kernel" should be changed to "initial module" (or
something else) to avoid confusion.

11) The multi-boot specification should say which tags are required
(e.g. "boot loader name", "memory map"); which tags must be present
under certain circumstances (e.g. "serial port" must be present *if*
the boot loader used a serial port as a console device); and which
tags are optional (and may be included or omitted by the boot loader).
For the current draft this is unclear.


Cheers

Brendan

Re: Multiboot2 Suggestions

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 8124 bytes --]

Brendan Trotter wrote:
> Hi,
>
> 2010/3/28 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
>   
>> Also I'm aware that at least some people want more tags. Feel free to
>> propose new ones.
>> In short all ammendment ideas are welcome.
>>     
>
> Here's my list.. :-)
>
> 1) If GRUB was using a serial port as a console device (e.g. on a
> headless system) it'd be nice if the OS could continue using the same
> serial port with the same configuration instead of resetting the
> serial port, etc. A new tag (for 80x86, "8250/6550 compatible" serial
> ports) would include base I/O port, the serial line configuration
> (e.g. 8 data bits, no stop bit, no parity), the baud rate (e.g. 9600),
>   
The kernel can read data bits, stop bits, parity and divisor from
registers itself. I think it's more useful to supply a base frequency
since there are a lot of "almost compatible" cards which differ only in
base frequency.

> the IRQ number (if known/used by the boot loader) and the protocol
> being used (ASCII, VT100, etc).
I think it's more useful to supply directly usable strings termcap
strings rather than an abstract ID
>  If the boot loader doesn't know which
> IRQ the serial port uses (e.g. it uses polling) then it sets the IRQ
> number to 0xFFFFFFFF. 
>   
> Where the serial port has a different interface
> (e.g. if the serial port uses MMIO or if it's not "8250/6550
> compatible") a different tag with different fields are used to
> describe it. 
I think it's more useful to have an I/O selector since yeeloong serial interface is basically the same, just attached differently

I think we need following fields:
1) I/O space selector (e.g. 0 = 32-bit MMIO, 1 = 64-bit MMIO, 2 = i386 I/O)
2) IRQ type selector (0 = None, 1 = standard platform interrupt)
3) 16-bit padding
4) address in I/O space (up to 64-bits)
5) Base frequency in Hz (32-bit)
6) IRQ (32-bit or even 64-bit since it's not excluded some platforms would use 64-bit IRQ ids, though I'm not aware of such).




> "telnet+ethernet"
It would need network tag first
> 2) The "OS image format" information should be expanded, so that the
> OS can tell the boot loader if it supports "8250/6550 compatible"
> serial ports (and which protocols), and any other console devices (for
> the same reason the "OS image format" already has flags, etc for
> video).
>   
Console flags tag is for this
> 3) There should be an (optional?) "critical error notification method"
> tag that tells the OS which method/s it can/should use to tell the
> user it encountered a problem before it was able to setup it's console
> output. For example, can/should the OS return to the boot loader, or
> use the "PC speaker" to beep, or make a PS/2 keyboard's LEDs flash, or
> something else.
>   
Processing such a selector may prove as difficult as setting up a
console based on console tags. So I doubt its usefullness
> 4) The section on "Machine State" is missing lots of information, and
> needs to indicate the state of *all* hardware on all architectures
> (regardles of firmware type). For example; for 80x86/PC it should say
> that PCI devices are left in an undefined state (so that the boot
> loader is not responsible for configuring PCI devices if the firmware
> didn't for any reason), except for any PCI device that is indirectly
> mentioned in the multi-boot information (e.g. if there's a serial port
> tag then the OS can assume that serial port is configured, if there's
> a video information tag then the OS can assume the video cards is
> configured, etc).
>   
Everything not said explicitly is undefined. However I would like to add
a sentence that some basic PCI initialisation OS usually expects and
which is done by firmware to be present.
> 5) The boot loader should always provide a "memory map". If the boot
> loader is unable to get a memory map from the firmware then the boot
> loader constructs a fake memory map from any/all information it can
> find, including known areas that aren't RAM. For e.g. on "80x86 BIOS"
> if "int 0x15, eax=0xE820" isn't supported, then other BIOS functions
> are used to find usable RAM and the boot loader creates an entry that
> marks the area from 0x000A0000 to 0x000FFFFF as "system" or "unknown".
>   
Where bootloader gets memory map from isn't part of specification and I
see no reason to change that
> The "mem_upper/mem_lower" tag should removed from the specification.
>
>   
If more people speak against this tag then yes.
> 7) The memory map needs more "area types". Any RAM that is reported by
> firmware as faulty should use "area type 5" so that the OS can know
> that some RAM is faulty, and (for e.g.) could tell a system
> administrator about it. Also, "area type 0xFFFFFFFF" should be used
> for "unknown", as this allows the OS to determine the difference
> between "boot loader doesn't know what the area is" and "boot loader
> does know what the area is but the area type is defined in a newer
> version of the multi-boot specification".
>   
What's the difference between type 2 and "type 5"
> 8) Any RAM that is not immediately usable by the OS should not be
> reported as "usable RAM" in the memory map. An example of this is the
> "ACPI reclaimable" area (which is RAM that isn't usable until the OS
> has finished using the ACPI tables). RAM used to store the multi-boot
> information, RAM used to store the "kernel" and RAM used to store any
> modules should be treated in the same way. I suggest using "area type
> 0xFFFFFFFE = RAM used for multi-boot information" and "area type
> 0xFFFFFFFD = RAM used for kernel/modules". This makes it much easier
> to write a kernel's early initialisation code, because it can use RAM
> without worrying about trashing data that is needed by the kernel/OS
> later.
>   
kernel should know itself what it asked bootloader to do. MBI now is a
single chunk. Further than that there are only elf section tag and
module tags which refer to external memory. I think it should be easily
trackable now.
> 9) The "boot device" tag needs to be revised. If the firmware was not
> "PC BIOS" it doesn't make any sense; and even if the firmware was "PC
> BIOS" the OS is unlikely to care (and there's cases where the BIOS
> device number still doesn't make sense if the OS does care - e.g. "El
> Torito" boot CD emulating a floppy disk or hard disk). The "boot
> device" tag should be removed, and (potentially) replaced by one or
> more new tags that describes how the boot device is accessed - e.g.
> one tag for "PCI_bus/device/function then controller_device_number and
> partition", another tag for "PCI_bus/device/function then
> protocol/IP_address/port", etc.
>
>   
I agree that current tag is quite useless but I'm not sure how to do a
new one cleanly
> 10) The word used for "kernel" should be changed. There is currently
> no reason why the boot loader couldn't be used to load an extra (OS
> specific) stage which in turn starts (one of) the OSs real kernel/s;
> and no reason why the real kernel/s couldn't be loaded by the boot
> loader as a module. Unfortunately, because the specification uses the
> word "kernel" people who are new to OS development and/or multi-boot
> make the mistake of assuming that "kernel" must be the OS's kernel. I
> propose the world "kernel" should be changed to "initial module" (or
> something else) to avoid confusion.
>   
I added a remark to Terminology section but I think that "Initial
module" will be more confusing.
> 11) The multi-boot specification should say which tags are required
> (e.g. "boot loader name", "memory map"); which tags must be present
> under certain circumstances (e.g. "serial port" must be present *if*
> the boot loader used a serial port as a console device); and which
> tags are optional (and may be included or omitted by the boot loader).
> For the current draft this is unclear.
>
>   
Only the ones OS image explicitly declared as required.


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: Multiboot2 Suggestions

[Brendan Trotter]

Hi,

2010/4/3 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
> Brendan Trotter wrote:
>> 1) If GRUB was using a serial port as a console device (e.g. on a
>> headless system) it'd be nice if the OS could continue using the same
>> serial port with the same configuration instead of resetting the
>> serial port, etc. A new tag (for 80x86, "8250/6550 compatible" serial
>> ports) would include base I/O port, the serial line configuration
>> (e.g. 8 data bits, no stop bit, no parity), the baud rate (e.g. 9600),
>>
> The kernel can read data bits, stop bits, parity and divisor from
> registers itself. I think it's more useful to supply a base frequency
> since there are a lot of "almost compatible" cards which differ only in
> base frequency.

You're right.

>> the IRQ number (if known/used by the boot loader) and the protocol
>> being used (ASCII, VT100, etc).
> I think it's more useful to supply directly usable strings termcap
> strings rather than an abstract ID

Here's an example termcap string:

ca|concept100|c100|concept|c104|concept100-4p|HDS Concept-100:\
             :al=3*\E^R:am:bl=^G:cd=16*\E^C:ce=16\E^U:cl=2*^L:cm=\Ea%+ %+ :\
             :co#80:.cr=9^M:db:dc=16\E^A:dl=3*\E^B:do=^J:ei=\E\200:eo:im=\E^P:in:\
             :ip=16*:is=\EU\Ef\E7\E5\E8\El\ENH\EK\E\200\Eo&\200\Eo\47\E:k1=\E5:\
             :k2=\E6:k3=\E7:kb=^h:kd=\E<:ke=\Ex:kh=\E?:kl=\E>:kr=\E=:ks=\EX:\
             :ku=\E;:le=^H:li#24:mb=\EC:me=\EN\200:mh=\EE:mi:mk=\EH:mp=\EI:\
             :mr=\ED:nd=\E=:pb#9600:rp=0.2*\Er%.%+ :se=\Ed\Ee:sf=^J:so=\EE\ED:\
             :.ta=8\t:te=\Ev    \200\200\200\200\200\200\Ep\r\n:\
             :ti=\EU\Ev  8p\Ep\r:ue=\Eg:ul:up=\E;:us=\EG:\
             :vb=\Ek\200\200\200\200\200\200\200\200\200\200\200\200\200\200\EK:\
             :ve=\Ew:vs=\EW:vt#8:xn:\
             :bs:cr=^M:dC#9:dT#8:nl=^J:ta=^I:pt:

Making sense out of arbitrary termcap strings isn't easy - it would
add a large amount of mess to early OS initialisation code (which
typically doesn't even have C library functions to rely on). A single
integer saying "which protocol" is much easier to parse and use,
especially as only a few standard protocols (e.g. VT100) would need to
be supported.

>>  If the boot loader doesn't know which
>> IRQ the serial port uses (e.g. it uses polling) then it sets the IRQ
>> number to 0xFFFFFFFF.
>>
>> Where the serial port has a different interface
>> (e.g. if the serial port uses MMIO or if it's not "8250/6550
>> compatible") a different tag with different fields are used to
>> describe it.
> I think it's more useful to have an I/O selector since yeeloong serial interface is basically the same, just attached differently

An I/O selector (for "8250/6550 compatible") makes sense, and
different tags for "not 8250/6550 compatible" serial ports.

> I think we need following fields:
> 1) I/O space selector (e.g. 0 = 32-bit MMIO, 1 = 64-bit MMIO, 2 = i386 I/O)

For 32-bit MMIO you could use 64-bit MMIO with the high bits of the
"address in I/O space" set to zero.

> 2) IRQ type selector (0 = None, 1 = standard platform interrupt)
> 3) 16-bit padding
> 4) address in I/O space (up to 64-bits)
> 5) Base frequency in Hz (32-bit)
> 6) IRQ (32-bit or even 64-bit since it's not excluded some platforms would use 64-bit IRQ ids, though I'm not aware of such).

Looks good to me.

>> "telnet+ethernet"
> It would need network tag first

Just an example of a different tag for a different type of console device.

>> 2) The "OS image format" information should be expanded, so that the
>> OS can tell the boot loader if it supports "8250/6550 compatible"
>> serial ports (and which protocols), and any other console devices (for
>> the same reason the "OS image format" already has flags, etc for
>> video).
>>
> Console flags tag is for this

Yes - the console flags tag needs to be expanded...

>> 3) There should be an (optional?) "critical error notification method"
>> tag that tells the OS which method/s it can/should use to tell the
>> user it encountered a problem before it was able to setup it's console
>> output. For example, can/should the OS return to the boot loader, or
>> use the "PC speaker" to beep, or make a PS/2 keyboard's LEDs flash, or
>> something else.
>>
> Processing such a selector may prove as difficult as setting up a
> console based on console tags. So I doubt its usefullness

I currently use "PC speaker" as my "critical error notification
method" - it's about 15 instructions that use I/O ports only and
doesn't require memory allocations or anything else. I doubt setting
keyboard LEDs (for a PS/2 keyboard) would be much larger or rely on
anything more than I/O ports.

In comparison, my video setup code is around 64 KiB of code that
starts with trying to get EDID information from the monitor, filtering
a list of video modes (from VGA and/or VBE), allocating several MiB of
RAM for video buffers and font data, scaling font data, etc. If
there's a problem setting up the memory management it's all useless
and I fall back to the "critical error notification method" so the
user knows the OS failed to initialise something (e.g. couldn't
allocate several MiB of RAM).

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).

>> 5) The boot loader should always provide a "memory map". If the boot
>> loader is unable to get a memory map from the firmware then the boot
>> loader constructs a fake memory map from any/all information it can
>> find, including known areas that aren't RAM. For e.g. on "80x86 BIOS"
>> if "int 0x15, eax=0xE820" isn't supported, then other BIOS functions
>> are used to find usable RAM and the boot loader creates an entry that
>> marks the area from 0x000A0000 to 0x000FFFFF as "system" or "unknown".
>>
> Where bootloader gets memory map from isn't part of specification and I
> see no reason to change that

The examples are examples (intended to illustrate why/how the boot
loader would create a memory map when the firmware doesn't provide
one; rather than intended for inclusion in the spec).

>> 7) The memory map needs more "area types". Any RAM that is reported by
>> firmware as faulty should use "area type 5" so that the OS can know
>> that some RAM is faulty, and (for e.g.) could tell a system
>> administrator about it. Also, "area type 0xFFFFFFFF" should be used
>> for "unknown", as this allows the OS to determine the difference
>> between "boot loader doesn't know what the area is" and "boot loader
>> does know what the area is but the area type is defined in a newer
>> version of the multi-boot specification".
>>
> What's the difference between type 2 and "type 5"

For a server environment, would your OS automatically send an email to
an administrator warning them that an area of memory is marked as
"system"?

>> 8) Any RAM that is not immediately usable by the OS should not be
>> reported as "usable RAM" in the memory map. An example of this is the
>> "ACPI reclaimable" area (which is RAM that isn't usable until the OS
>> has finished using the ACPI tables). RAM used to store the multi-boot
>> information, RAM used to store the "kernel" and RAM used to store any
>> modules should be treated in the same way. I suggest using "area type
>> 0xFFFFFFFE = RAM used for multi-boot information" and "area type
>> 0xFFFFFFFD = RAM used for kernel/modules". This makes it much easier
>> to write a kernel's early initialisation code, because it can use RAM
>> without worrying about trashing data that is needed by the kernel/OS
>> later.
>>
> kernel should know itself what it asked bootloader to do. MBI now is a
> single chunk. Further than that there are only elf section tag and
> module tags which refer to external memory. I think it should be easily
> trackable now.

Unfortunately a lot of OSs are written by C programmers who do the
absolute minimum to setup paging in a small piece of startup code
written in assembly, before jumping to their "main()". This means they
allocate RAM for page tables, etc before they've parsed or checked
anything; usually by searching the memory map for the first "usable"
area and using the first pages of that area.

Unfortunately I'm often the person that needs to explain to them that
"usable" doesn't mean usable; and that their code only works by
accident (and their initialisation code could overwrite things needed
by the OS later if it's booted by a different multi-boot compliant
boot loader; including future versions of GRUB and not excluding
non-GRUB boot loaders); and that the only memory they can safely use
before determining what is usable and what isn't is the space in their
".bss", which usually happens to be linked to a virtual address (e.g.
above 0xC00000000) and not the address it's actually loaded at.The
other alternative is for the initialisation code to copy everything
from the "usable" areas into their ".bss" so that they can assume that
"usable" means usable (but there's no maximum size for the multi-boot
information and no way to know how big "big enough" is, and this won't
work if there's any extra modules).

Basically, regardless of how the OS handles the problem, the "small
piece of startup code written in assembly" ends up being an ugly mess.

If multi-boot guaranteed that "usable" actually did mean usable then
the problem goes away. Alternatively you could rename it, so that
"type 1 = potentially usable maybe" so that beginners realise they're
screwed before they write their dodgy code... ;-)


Cheers,

Brendan

Re: Multiboot2 Suggestions

[Bogdan]

This thread has the right name so I'll just reply here.

0) It should be specified in Multiboot 2 that Multiboot 1 can optionally be
supported by boot loaders when a different magic number is used.

1) The boot loader should calibrate timers that need this. I don't know about
other architectures, but in x86(-64) systems, these are the RDTSC and the
LAPIC. Needless to say, this must also be done when such hardware is
present.

2) I've seen this proposed before and turned down but it's my list of suggestions
and I'm free to repeat it :) A language tag passed by the boot loader would be
nice - that way Multiboot-compliant boot loaders could have a simple menu to
select the language for any of the operating systems installed. It would make
it easier for the user, who otherwise needs to know what to pass to cmdline.

3) On x86-64 systems, the boot loader should be able to boot in long mode.
I remember talking to Vladimir on IRC about paging and he said he prefered
to always have the simplest form of paging initialized by the boot loader --
disabled in the case of protected mode and identity-mapped in the case of
long mode. I think that is fair.

Regards,
Bogdan


      

Re: Multiboot2 Suggestions

[richardvoigt]

>>> 8) Any RAM that is not immediately usable by the OS should not be
>>> reported as "usable RAM" in the memory map. An example of this is the
>>> "ACPI reclaimable" area (which is RAM that isn't usable until the OS
>>> has finished using the ACPI tables). RAM used to store the multi-boot
>>> information, RAM used to store the "kernel" and RAM used to store any
>>> modules should be treated in the same way. I suggest using "area type
>>> 0xFFFFFFFE = RAM used for multi-boot information" and "area type
>>> 0xFFFFFFFD = RAM used for kernel/modules". This makes it much easier
>>> to write a kernel's early initialisation code, because it can use RAM
>>> without worrying about trashing data that is needed by the kernel/OS
>>> later.
>>>
>> kernel should know itself what it asked bootloader to do. MBI now is a
>> single chunk. Further than that there are only elf section tag and
>> module tags which refer to external memory. I think it should be easily
>> trackable now.
>
> Unfortunately a lot of OSs are written by C programmers who do the
> absolute minimum to setup paging in a small piece of startup code
> written in assembly, before jumping to their "main()". This means they
> allocate RAM for page tables, etc before they've parsed or checked
> anything; usually by searching the memory map for the first "usable"
> area and using the first pages of that area.
>
> Unfortunately I'm often the person that needs to explain to them that
> "usable" doesn't mean usable; and that their code only works by
> accident (and their initialisation code could overwrite things needed
> by the OS later if it's booted by a different multi-boot compliant
> boot loader; including future versions of GRUB and not excluding
> non-GRUB boot loaders); and that the only memory they can safely use
> before determining what is usable and what isn't is the space in their
> ".bss", which usually happens to be linked to a virtual address (e.g.
> above 0xC00000000) and not the address it's actually loaded at.The
> other alternative is for the initialisation code to copy everything
> from the "usable" areas into their ".bss" so that they can assume that
> "usable" means usable (but there's no maximum size for the multi-boot
> information and no way to know how big "big enough" is, and this won't
> work if there's any extra modules).
>
> Basically, regardless of how the OS handles the problem, the "small
> piece of startup code written in assembly" ends up being an ugly mess.
>
> If multi-boot guaranteed that "usable" actually did mean usable then
> the problem goes away. Alternatively you could rename it, so that
> "type 1 = potentially usable maybe" so that beginners realise they're
> screwed before they write their dodgy code... ;-)

This does sound like there ought to be different codes for "usable -
unused" vs "usable - valid".  I think the original objection may have
been to enumerating all the different kinds of "usable - valid"
regions which could snowball into a very large number of IDs.

Re: Multiboot2 Suggestions

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 9671 bytes --]

Brendan Trotter wrote:
> Hi,
>   
>>> the IRQ number (if known/used by the boot loader) and the protocol
>>> being used (ASCII, VT100, etc).
>>>       
>> I think it's more useful to supply directly usable strings termcap
>> strings rather than an abstract ID
>>     
>
> Here's an example termcap string:
>
> ca|concept100|c100|concept|c104|concept100-4p|HDS Concept-100:\
>              :al=3*\E^R:am:bl=^G:cd=16*\E^C:ce=16\E^U:cl=2*^L:cm=\Ea%+ %+ :\
>              :co#80:.cr=9^M:db:dc=16\E^A:dl=3*\E^B:do=^J:ei=\E\200:eo:im=\E^P:in:\
>              :ip=16*:is=\EU\Ef\E7\E5\E8\El\ENH\EK\E\200\Eo&\200\Eo\47\E:k1=\E5:\
>              :k2=\E6:k3=\E7:kb=^h:kd=\E<:ke=\Ex:kh=\E?:kl=\E>:kr=\E=:ks=\EX:\
>              :ku=\E;:le=^H:li#24:mb=\EC:me=\EN\200:mh=\EE:mi:mk=\EH:mp=\EI:\
>              :mr=\ED:nd=\E=:pb#9600:rp=0.2*\Er%.%+ :se=\Ed\Ee:sf=^J:so=\EE\ED:\
>              :.ta=8\t:te=\Ev    \200\200\200\200\200\200\Ep\r\n:\
>              :ti=\EU\Ev  8p\Ep\r:ue=\Eg:ul:up=\E;:us=\EG:\
>              :vb=\Ek\200\200\200\200\200\200\200\200\200\200\200\200\200\200\EK:\
>              :ve=\Ew:vs=\EW:vt#8:xn:\
>              :bs:cr=^M:dC#9:dT#8:nl=^J:ta=^I:pt:
>
> Making sense out of arbitrary termcap strings isn't easy - it would
> add a large amount of mess to early OS initialisation code (which
> typically doesn't even have C library functions to rely on). A single
> integer saying "which protocol" is much easier to parse and use,
> especially as only a few standard protocols (e.g. VT100) would need to
> be supported.
>   
It doesn't need to be termcap string in its normal form. It can be sth like:
uint16_t offset_to_gotoxy_string;
uint16_t offset_to_cls_string;
...
uint16_t offset_to_end_of_last_string;
<strings>
This way if OS wants to e.g. clear screen it should have no trouble
retrieving and replaying string.


>>>  If the boot loader doesn't know which
>>> IRQ the serial port uses (e.g. it uses polling) then it sets the IRQ
>>> number to 0xFFFFFFFF.
>>>
>>> Where the serial port has a different interface
>>> (e.g. if the serial port uses MMIO or if it's not "8250/6550
>>> compatible") a different tag with different fields are used to
>>> describe it.
>>>       
>> I think it's more useful to have an I/O selector since yeeloong serial interface is basically the same, just attached differently
>>     
>
> An I/O selector (for "8250/6550 compatible") makes sense, and
> different tags for "not 8250/6550 compatible" serial ports.
>
>   
>> I think we need following fields:
>> 1) I/O space selector (e.g. 0 = 32-bit MMIO, 1 = 64-bit MMIO, 2 = i386 I/O)
>>     
>
> For 32-bit MMIO you could use 64-bit MMIO with the high bits of the
> "address in I/O space" set to zero.
>
>   
Do all platforms zero-expand? Or do some sign-extend? if it depends only
on ISA there is no problem in just saying if it's zero or sign-extended
depending on platform. Perhaps like
0 = you can access even if you're not 64-bit aware
1 = you need to be 64-bit aware

Another field I forgot which will go instead of 16-bit padding is flags.
First flag will be CONSOLE_ACTIVE which will indicate that console was
used by bootloader. This way bootloader can inform OS of additional
serial ports which it didn't use.
> Yes - the console flags tag needs to be expanded...
>
>   
It was meant to
>>> 3) There should be an (optional?) "critical error notification method"
>>> tag that tells the OS which method/s it can/should use to tell the
>>> user it encountered a problem before it was able to setup it's console
>>> output. For example, can/should the OS return to the boot loader, or
>>> use the "PC speaker" to beep, or make a PS/2 keyboard's LEDs flash, or
>>> something else.
>>>
>>>       
>> Processing such a selector may prove as difficult as setting up a
>> console based on console tags. So I doubt its usefullness
>>     
>
> I currently use "PC speaker" as my "critical error notification
> method" - it's about 15 instructions that use I/O ports only and
> doesn't require memory allocations or anything else. I doubt setting
> keyboard LEDs (for a PS/2 keyboard) would be much larger or rely on
> anything more than I/O ports.
>
> In comparison, my video setup code is around 64 KiB of code that
> starts with trying to get EDID information from the monitor, filtering
> a list of video modes (from VGA and/or VBE), allocating several MiB of
> RAM for video buffers and font data, scaling font data, etc. If
> there's a problem setting up the memory management it's all useless
> and I fall back to the "critical error notification method" so the
> user knows the OS failed to initialise something (e.g. couldn't
> allocate several MiB of RAM).
>   
If you use frmaebuffer info in mbi you can have basic video much faster.
> 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.
>>> 7) The memory map needs more "area types". Any RAM that is reported by
>>> firmware as faulty should use "area type 5" so that the OS can know
>>> that some RAM is faulty, and (for e.g.) could tell a system
>>> administrator about it. Also, "area type 0xFFFFFFFF" should be used
>>> for "unknown", as this allows the OS to determine the difference
>>> between "boot loader doesn't know what the area is" and "boot loader
>>> does know what the area is but the area type is defined in a newer
>>> version of the multi-boot specification".
>>>
>>>       
>> What's the difference between type 2 and "type 5"
>>     
>
> For a server environment, would your OS automatically send an email to
> an administrator warning them that an area of memory is marked as
> "system"?
>
>   
I'll think if this alone is enough reason. Are there any other motivation?
>>> 8) Any RAM that is not immediately usable by the OS should not be
>>> reported as "usable RAM" in the memory map. An example of this is the
>>> "ACPI reclaimable" area (which is RAM that isn't usable until the OS
>>> has finished using the ACPI tables). RAM used to store the multi-boot
>>> information, RAM used to store the "kernel" and RAM used to store any
>>> modules should be treated in the same way. I suggest using "area type
>>> 0xFFFFFFFE = RAM used for multi-boot information" and "area type
>>> 0xFFFFFFFD = RAM used for kernel/modules". This makes it much easier
>>> to write a kernel's early initialisation code, because it can use RAM
>>> without worrying about trashing data that is needed by the kernel/OS
>>> later.
>>>
>>>       
>> kernel should know itself what it asked bootloader to do. MBI now is a
>> single chunk. Further than that there are only elf section tag and
>> module tags which refer to external memory. I think it should be easily
>> trackable now.
>>     
>
> Unfortunately a lot of OSs are written by C programmers who do the
> absolute minimum to setup paging in a small piece of startup code
> written in assembly, before jumping to their "main()". This means they
> allocate RAM for page tables, etc before they've parsed or checked
> anything; usually by searching the memory map for the first "usable"
> area and using the first pages of that area.
>
> Unfortunately I'm often the person that needs to explain to them that
> "usable" doesn't mean usable; and that their code only works by
> accident (and their initialisation code could overwrite things needed
> by the OS later if it's booted by a different multi-boot compliant
> boot loader; including future versions of GRUB and not excluding
> non-GRUB boot loaders); and that the only memory they can safely use
> before determining what is usable and what isn't is the space in their
> ".bss", which usually happens to be linked to a virtual address (e.g.
> above 0xC00000000) and not the address it's actually loaded at.The
> other alternative is for the initialisation code to copy everything
> from the "usable" areas into their ".bss" so that they can assume that
> "usable" means usable (but there's no maximum size for the multi-boot
> information and no way to know how big "big enough" is, and this won't
> work if there's any extra modules).
>
> Basically, regardless of how the OS handles the problem, the "small
> piece of startup code written in assembly" ends up being an ugly mess.
>
> If multi-boot guaranteed that "usable" actually did mean usable then
> the problem goes away. Alternatively you could rename it, so that
> "type 1 = potentially usable maybe" so that beginners realise they're
> screwed before they write their dodgy code... ;-)
>
>   
I added a remark to the spec.
> Cheers,
>
> Brendan
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: Multiboot2 Suggestions

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1368 bytes --]

Bogdan wrote:
> This thread has the right name so I'll just reply here.
>
> 1) The boot loader should calibrate timers that need this. I don't know about
> other architectures, but in x86(-64) systems, these are the RDTSC and the
> LAPIC. Needless to say, this must also be done when such hardware is
> present.
>   
On MIPS bootloader needs to supply CP0 counter frequency. Is it anything
similar on x86?
I don't feel like on x86 this should be mandatory. Usually OS doesn't
expect bootloader to do these steps and it takes booting time.
If there is however a motivation to do this task in bootloader we could
add a tag requestion bootloader to do this step
> 3) On x86-64 systems, the boot loader should be able to boot in long mode.
>   
I'll implement and specify it as soon as I'm finished with newreloc.
> I remember talking to Vladimir on IRC about paging and he said he prefered
> to always have the simplest form of paging initialized by the boot loader --
> disabled in the case of protected mode and identity-mapped in the case of
> long mode. I think that is fair.
>
> Regards,
> Bogdan
>
>
>       
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: Multiboot2 Suggestions

[Brendan Trotter]

Hi,

2010/4/10 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
>> Making sense out of arbitrary termcap strings isn't easy - it would
>> add a large amount of mess to early OS initialisation code (which
>> typically doesn't even have C library functions to rely on). A single
>> integer saying "which protocol" is much easier to parse and use,
>> especially as only a few standard protocols (e.g. VT100) would need to
>> be supported.
>>
> It doesn't need to be termcap string in its normal form. It can be sth like:
> uint16_t offset_to_gotoxy_string;
> uint16_t offset_to_cls_string;
> ...
> uint16_t offset_to_end_of_last_string;
> <strings>
> This way if OS wants to e.g. clear screen it should have no trouble
> retrieving and replaying string.

That could work (and would be much better than a termcap string in its
normal form).

>> For 32-bit MMIO you could use 64-bit MMIO with the high bits of the
>> "address in I/O space" set to zero.
>>
> Do all platforms zero-expand? Or do some sign-extend? if it depends only
> on ISA there is no problem in just saying if it's zero or sign-extended
> depending on platform. Perhaps like
> 0 = you can access even if you're not 64-bit aware
> 1 = you need to be 64-bit aware

I've never seen an architecture where physical addresses are
interpreted as signed (instead of unsigned).

> Another field I forgot which will go instead of 16-bit padding is flags.
> First flag will be CONSOLE_ACTIVE which will indicate that console was
> used by bootloader. This way bootloader can inform OS of additional
> serial ports which it didn't use.

That's a good idea. :-)

>> I currently use "PC speaker" as my "critical error notification
>> method" - it's about 15 instructions that use I/O ports only and
>> doesn't require memory allocations or anything else. I doubt setting
>> keyboard LEDs (for a PS/2 keyboard) would be much larger or rely on
>> anything more than I/O ports.
>>
>> In comparison, my video setup code is around 64 KiB of code that
>> starts with trying to get EDID information from the monitor, filtering
>> a list of video modes (from VGA and/or VBE), allocating several MiB of
>> RAM for video buffers and font data, scaling font data, etc. If
>> there's a problem setting up the memory management it's all useless
>> and I fall back to the "critical error notification method" so the
>> user knows the OS failed to initialise something (e.g. couldn't
>> allocate several MiB of RAM).
>>
> If you use frmaebuffer info in mbi you can have basic video much faster.

I'm not planning to have any support for "basic video" (only "eye
candy video"). I don't support text modes either (and have no desire
to add support for text modes).

I'm also wondering if a "primary monitor's EDID" tag could be added to
the multi-boot information. This tag would optional - if the boot
loader can't get the information, or if the boot loader doesn't even
try to get the information, then the boot loader can skip the EDID tag
(but the EDID information is easy to obtain from VBE and U/EFI if
you're writing "firmware specific" code).

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).

>> 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)".

>>> What's the difference between type 2 and "type 5"
>>
>> For a server environment, would your OS automatically send an email to
>> an administrator warning them that an area of memory is marked as
>> "system"?
>>
> I'll think if this alone is enough reason. Are there any other motivation?

Does there need to be any other motivation?

The first priority is making sure things work. If mains power fails
you use backup power from a UPS, if a power supply fails you rely on
another redundant power supply, if a CPU has failed you take it
offline and use the other CPUs, if a RAM chip failed you don't use it
and rely on the remaining RAM chips, if a hard disk fails you use the
other hard disks in the RAID array, and if a network card or network
connection dies you use the other network cards/connections; and in
all cases everything works (possibly with some performance loss).

The second priority is making sure that someone knows that there's
been some sort of failure (hopefully someone who's responsible for
fixing the problem), even though the system as a whole is still
working fine. Otherwise the performance loss (if any) may not be
noticed and a second (or third, fourth, ...) failure can prevent the
system from working.

The third priority is detecting potential future failures, so that
people can do something to avoid failures before they happen. "SMART"
(Self-Monitoring, Analysis, and Reporting Technology) used in hard
drives is one example of this.

For RAM chip failures detected by firmware during POST, the firmware
tries to tell the OS by including a "faulty RAM" area in it's memory
map, but if GRUB fails to pass this information on to the OS then
there's no other sane way for an OS to know.


Cheers,

Brendan

Re: Multiboot2 Suggestions

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 3739 bytes --]

Brendan Trotter wrote:
>>> I currently use "PC speaker" as my "critical error notification
>>> method" - it's about 15 instructions that use I/O ports only and
>>> doesn't require memory allocations or anything else. I doubt setting
>>> keyboard LEDs (for a PS/2 keyboard) would be much larger or rely on
>>> anything more than I/O ports.
>>>
>>> In comparison, my video setup code is around 64 KiB of code that
>>> starts with trying to get EDID information from the monitor, filtering
>>> a list of video modes (from VGA and/or VBE), allocating several MiB of
>>> RAM for video buffers and font data, scaling font data, etc. If
>>> there's a problem setting up the memory management it's all useless
>>> and I fall back to the "critical error notification method" so the
>>> user knows the OS failed to initialise something (e.g. couldn't
>>> allocate several MiB of RAM).
>>>
>>>       
>> If you use frmaebuffer info in mbi you can have basic video much faster.
>>     
>
> I'm not planning to have any support for "basic video" (only "eye
> candy video"). I don't support text modes either (and have no desire
> to add support for text modes).
>
> I'm also wondering if a "primary monitor's EDID" tag could be added to
> the multi-boot information. This tag would optional - if the boot
> loader can't get the information, or if the boot loader doesn't even
> try to get the information, then the boot loader can skip the EDID tag
> (but the EDID information is easy to obtain from VBE and U/EFI if
> you're writing "firmware specific" code).
>
> 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?
>>> 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



-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: Multiboot2 Suggestions

[Brendan Trotter]

Hi,

2010/4/21 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
> 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