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

["Gabriel L. Somlo" <gsomlo@gmail.com>]

Hi Phil,

On Thu, Mar 30, 2017 at 12:22:16PM +1300, Phil Dennis-Jordan wrote:
> 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?

FTR, my main objectives with that patch set were, in roughly this
order:

	- backup: if I get hit by a bus, i wanted to have a (BSD)
	  license-compliant way to glue it all together and get it
	  working

	- something public to point at from my instructions webpage :)

	- solicit initial feedback re. HFS+ support
		- that's where Laszlo's "Lose the FSW!" came in :)

I decided to stick with FSW initially because I needed to focus on the
HFS+ nitty-gritty, and FSW allowed me to ignore the EDK2 nitty-gritty
during that process. (TBH, on the few occasions I've contributed anything
to EDK2, I always started out by writing in "regular" C coding style,
then translate into EDK2-ese immediately before submitting the patch :)

Last, but not least, I figured the refind project might also be
interested in a BSD-licensed HFS+ driver, so that'd be a free bonus.


If you decide to go for it and do the translation or
re-implementation, that'd be awesome! If it were me, I'd probably
try to delay the part where I eliminate the FSW until I were finished
with understanding and implementing the HFS+ specific bits. I'd delay
dealing with the coding guidelines until I had finished eliminating
the FSW, and had working C code I could understand just by
eyeballing...

But that's just me and my personal strength vs. weakness (mainly the
latter) tradeoff :) Any way that works for you is by definition better!


Last, but not least: I completely cargo-culted Reza's patches, with
only the bare minimum intervention to keep them compiling as I rebased
on top the accumulating upstream edk2 commits. Since they have no
reasonable chance of being applied without HFS+ support, I figured I'd
focus on that first and foremost. That also means that, right now, I have
absolutely no idea if (and how) anything in those patches could be done
more elegantly or efficently :)


Thanks again,
--Gabriel