On 28.11.2016 20:26, David Hendricks via coreboot wrote:
On Sun, Nov 27, 2016 at 8:28 PM, ron minnich rminnich@gmail.com wrote:
yeah, david and nico both make very good points. I like the idea of JSON file, and further we're working on a Go program on the u-root project that would parse said file (trivial in Go to parse JSON, it's one statement and blam! your Go struct is all filled in) and then decide what to configure/what to download/how to validate (we have a gpgv command written in Go by Eric Grosse) and then how to kexec it.
I think what we're doing might be useful?
Now we're talkin' - A standardized data format that is human readable/writeable that can be easily parsed and generated using small libraries. It looks like Go can already handle it easily, for C we could maybe use JSMN (http://zserge.com/jsmn.html) or something similar. I think that addresses Nico's first point.
For the other points, I imagine we'd have two varieties of the JSON file. One would be generated along with the payload and included as a CBFS file to specify things like capabilities and bootable device priority*. The other would be on the bootable media and specify things like the kernel path and parameters. A tool which is used to generate the latter would verify the capabilities and warn the user if their coreboot payload lacks support for something.
A tool like that might have to see the whole bootable medium. You can't tell from the configuration file in which type of filesystem it's stored for example. But I really like the idea. Such a tool could tell if a boot medium only needs capabilities that are mandatory in the spec, thus, should always boot ;)
*Stuff like boot device priority might need some more thought since CMOS may be a preferable way of controlling something like that. However given that CMOS might not exist on a particular platform (especially in the non-x86 world) replacing the config file in CBFS file might not be a bad way to go.
I'd like to keep that out of scope (for the moment). Let's just start with what happens when the bootloader has found the configuration.
Nico
To sum it up, I want something that is lean and clean enough so it could
be added to any bootloader. Even if that boot loader is not of the let's build a tiny OS type.
I don't really see how you could reach this goal with anything that requires reading a file from the boot media? There are billions of different file systems out there... do you want to require your "minimal" bootloader to include drivers for all of them? (There are bootloaders that don't contain any file system drivers at all, like depthcharge.) Or do you want to do the full EFI "let's waste 128MB of every disk on a special FAT32 partition" madness (which still requires bootloaders to include one specific FS driver they might otherwise not want)?
I think if you want to do anything truly minimal and compatible with everything, you can't rely on files (and you should try to rely on partitions as little as possible, e.g. no full GPT parsing). Which probably means putting it in the first sector. And once you have that, you can create some fancy text-based format (or Go source file / node.js script / whatever the cool kids use these days) to describe the target sector, load address etc. of the fallback kernel... but you're really just exemplifying the XKCD Igor mentioned because you've just reinvented the MBR. (And let's face it... no coreboot bootloader has the pull to sufficiently promote adoption of some completely new fallback boot descriptor format right now, even if it doesn't require a Go compiler in your bootloader.)
So, really, I think what you want is just the MBR. It is the deadest simple design possible (just load a sector and jump), it is as infinitely flexible as code itself, and it coexists perfectly with all partitioning schemes relevant today (MBR and GPT). Yes, it requires a software interrupt BIOS interface, but if the recovery kernel code is cleverly written you really only need the disk access part (and you know your bootloader already has that driver because that's how it loaded the MBR in the first place). And yes, on x86 it requires real mode (for non-x86 I'd just make up an as equivalent as possible system with your software interrupt solution of choice), but that's a small price you pay with a few files worth of shim code in exchange for automatic compatibility with 35 years worth of existing BIOSes. I'd say that's a better deal than any new dead-on-arrival scheme you could make up out of thin air.
(If you really can't stand the idea of BIOS interrupts and real mode, I think your next best option would be to try to cram an as-small-as-possible binary recovery descriptor and the real mode code to parse/load/execute it together into the 446 bytes of MBR space you have. This way, your new payloads can just find and parse/load/execute the descriptor itself without having to provide any BIOS interface, but the thing is still compatible with existing legacy BIOSes as well.)
-
Julius Werner -
Nico Huber