Hi, 2010/4/10 Vladimir 'φ-coder/phcoder' Serbinenko <phco...@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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
