grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Multiboot2 Suggestions


From: Brendan Trotter
Subject: Re: Multiboot2 Suggestions
Date: Sat, 10 Apr 2010 08:41:13 +0930

Hi,

2010/4/10 Vladimir 'φ-coder/phcoder' Serbinenko <address@hidden>:
>> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]