amusement value: How long was the minimum time to cross USA from East Coast (NYC) to West Coast (SF) back then in 1880s (Vayat Erp and Dock Holiday time: by horse or carriage)?
And how long for the same distance Today/Present time (by plane or shuttle)? Ron, technology advances... Doesn't it??? ;-) Zoran On Wed, Nov 30, 2016 at 10:18 PM, ron minnich <[email protected]> wrote: > amusement value: > > The 512 bytes used for MBR is about .04% of the 8" floppy disk that > shipped with the original IBM PC. For 128 MB to be that fraction of a new > disk, the disk would have to be 256 GiB. That's about $40 worth of disk. > > Geez. > > > On Wed, Nov 30, 2016 at 11:00 AM Zoran Stojsavljevic < > [email protected]> wrote: > >> > 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)? >> >> YES, you do. Accent on: "every disk" . >> >> Zoran >> On Tue, Nov 29, 2016 at 10:53 PM, Julius Werner <[email protected]> >> wrote: >> >> > 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.) >> >> -- >> coreboot mailing list: [email protected] >> https://www.coreboot.org/mailman/listinfo/coreboot >> >>
-- coreboot mailing list: [email protected] https://www.coreboot.org/mailman/listinfo/coreboot
