Opened 19 months ago

Last modified 18 months ago

#18455 new enhancement

rebrand mmc media type?

Reported by: kallisti5 Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: - General Version: R1/beta4
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

We may want to rebrand the "mmc" media type. Historically mmc was for arm boards + sd cards.. however it has shifted to be more "haiku image + EFI system partition" with a mix of u-boot scripts on some platforms.

The term mmc / sd still technically makes sense as this image can be written to these media, however it can also be written to usb flash devices, hard drives, etc and successfully booted as well.

Change History (4)

comment:1 by kallisti5, 19 months ago

So my brain jumps to calling the media type "efi", "efisys", etc.

*however* we also offer alternative platform loaders like native u-boot and native riscv64 loaders which can be used on mmc.

So I have no idea lol.

  • "anyboot" is the EFI + BIOS32 + ISO or HDD boot hell that is x86
  • "image" is taken for the bare bootloaderless haiku image
  • "raw" is taken for... I guess the same?
  • "vmware" is still around I think
Version 0, edited 19 months ago by kallisti5 (next)

comment:2 by pulkomandy, 18 months ago

Ideally there should be only "anyboot", "raw" and "vmware" and the details of "anyboot" for each platform should be handled either by the "anyboot" tool, or by jam internal logic.

The "user interface" for this (the build profile) should not be different for each platform.

And we can rename the "anyboot" profile to something easier to understand, I guess?

comment:3 by kallisti5, 18 months ago

Unfortunately, anyboot is a cd iso long before it's a disk image (https://cgit.haiku-os.org/haiku/tree/build/jam/images/AnybootImage#n41 ) making the anyboot logic a bit hard to program clearly (anyboot makes an iso with a fake mbr, mmc makes a normal EFI or u-boot disk image with a real mbr)

*eventually* (R2, etc) the anyboot/cd install media likely won't be a thing anymore. (along with mbr bios_32) EFI support in most desktop hardware has been great for a while, and i'd like to think most people use an external CDROM now-a-days (if at all). However, a lot of people also use Haiku on older hardware and we don't want to discourage that.

Given the above... i think anyboot should remain a thing on it's own. (heck.. maybe rebrand x86hybridboot or something, though anyboot is a nice name)

Last edited 18 months ago by kallisti5 (previous) (diff)

comment:4 by pulkomandy, 18 months ago

There is no reason the build profiles exposes all of this.

The build profile should be "I just want a bootable image" or "I just want a raw filesystem image", and the steps to achieve that should be handled internally.

Also, no, the anyboot is not an ISO image. It has a standard MBR and an EFI partition, and it also has an ISO bootable partition for booting from CD. It is a bit of everything. Ideally we would replace the "anyboot" tool (which is very hardcoded to this specific configuration) with something more generic that can be configured to do any type of image we need (you know, something like Rune, except we don't really want to add Rust as a build dependency).

Why is it not yet done that way? Initially the "anyboot" images were experimental, and offered side-by-side with the raw images (for USB booting) and real ISO images (where the whole root filesystem is an iso filesystem, with a special layer for attributes support, and there is no bfs at all). Now this is all long forgotten, everyone is booting from the anyboot. But the support for full-ISO images is still around, and probably very broken.

And once we got support for that, people added support for Apple PowerPC hardware and for MMC in a similar way, grafting them as completely different boot types and targets, which is not how it should work. The entry point should be "make me a bootable image" and the buildsystem should figure out what to do on its own.

Note: See TracTickets for help on using tickets.