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