Re: [RFC PATCH 0/6] OVMF: HFS+ (and Mac OS X boot)

[Phil Dennis-Jordan <lists@philjordan.eu>]

Hi Gabriel,

First off, thanks for going to the effort of building an HFS+ driver!
Due to travel, I've only just got around to checking these out, sorry.

Before I can try to help out with cleaning the patches up to the
extent they can be upstreamed, I still need to get them working.
boot.efi seems to load, and it finds the kernel, so the HFS+ driver is
definitely working, but it fails during early boot with "Error loading
drivers." This is with existing VM disk images that work with an old
variant of Reza's patchset, so it's possible that the prelinked kernel
image assumes something about the EFI implementation that's not true
for this patchset. I'll try reinstalling the VM from scratch with the
instructions from your website [1] before I try to dig deeper. It
could also be something to do with the hardlink issue I mention later
on, or maybe the lack of support for fragmented files.

A few general comments so far on the HFS patches below:

On Tue, Mar 7, 2017 at 4:14 PM, Gabriel L. Somlo <gsomlo@gmail.com> wrote:
>
>     - patch 3/6: A BSD-licensed implementation of an FSW HFS+ driver.
>                  Based on Apple's HFS+ specification (TN1150), this is
>                  a minimalistic, bare-bones set of FSW methods capable
>                  of locating and loading files from an HFS+ volume.
>                  Lots of functionality (e.g. stat, readdir, hard/sym
>                  links, or accessing files with more than 8 fragments)
>                  is unimplemented at this time. I only implemented the
>                  methods necessary to support loading Apple's boot.efi
>                  and kernel.

The OS X installer disk images produced by Apple's own
"createinstallmedia" tool creates hardlinks to the bootloader and
kernel image, so supporting hardlinks might be a useful feature we can
add, as it would simplify the installer image creation process
somewhat. But I guess the higher priority is getting rid of the FSW
wrapper.

> If not, it might be worth factoring out the common bits and roll the
> the whole thing up into a standalone HFS+ driver, which would be a
> significantly different direction to go.

Based on Laszlo's comments, that seems to be the preferred approach.
(Not entirely unexpectedly.) I'm unfamiliar with the FSW, so I'll try
to find some time to look over that and work out if I can make a
sufficient time investment to help out with distilling this down. Do
you think it'd be easier to start from zero, or to rip out FSW bits
one by one and hard-code them into the HFS+ driver, having the whole
thing working throughout?

Phil