Re: Ventoy support

I've moved the Ventoy support discussion to the -hackers mailing list.

On Thu, 26 Oct 2023 at 20:07, Ed Maste <emaste@freebsd.org> wrote:
>
> The second way is via block mapping, using some service to translate
> offsets in the image file within the lower filesystem to physical
> offsets in the underlying device. Linux has native support for this
> via lvm2/dmsetup, and this is the mode that's used when I tried
> booting a Ubuntu ISO via Ventoy. As it turns out NetBSD and
> DragonflyBSD have a GPL'd lvm2 port, and presumably work the same way
> with Ventoy. Ventoy's geom_ventoy FreeBSD kernel module works
> similarly, just in a slightly hackish and Ventoy-specific way.

I want to clarify one item here, because it has come up again. I've
looked into how Ventoy operates, and it appears to require more than
just including the (BSD licensed) geom_ventoy.ko in our releases.
Ventoy stores the block mapping in the kernel module itself that it
then injects into the ISO image.

I think methods of supporting Ventoy, in order of "architectural elegance" are:

1. Mount the exFAT device and then mount the ISO image within. This
unfortunately requires FUSE as we do not yet have kernel exFAT
support. There's probably also a small performance penalty, but it
shouldn't be a significant issue in the context of an installer.

2. Use a geom module that provides arbitrary block mapping, akin to
one of the modes of Linux's lvm2. We do have a geom_linux_lvm module
already, but I am not sure if it provides the required functionality.
It may be that we can use it as-is, it may be that we can extend it to
support what we need, or we could use geom_ventoy as a starting point
for something new.

3. Include geom_ventoy in our tree (after code review) and find a way
to have Ventoy write the mapping into it.

I believe that helloSystem (a FreeBSD derivative,
https://hellosystem.github.io/docs/) has already gone down this path,
so the first step is to see what they've tried and what works for
them.