From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x244.google.com (mail-qt0-x244.google.com [IPv6:2607:f8b0:400d:c0d::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id BE85C21A0482F for ; Fri, 31 Mar 2017 13:02:02 -0700 (PDT) Received: by mail-qt0-x244.google.com with SMTP id r45so11595859qte.0 for ; Fri, 31 Mar 2017 13:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=fUhSXz+uQwBXv8ZeCob/v8qJnVskEL8OVk7VEeT6Ao8=; b=fCb7oI9tYzt0JAfvicD4vXIWMDghWNwOvGlutsxGIPg67R5hs3IRnpyCwR83Il9S5Z Iy6oQGOI+/KWyHlD8W0AcuAXCSfYE6w+37To4bogGYeKPuxOHT/ghptYBZR46NrsZqqg cZf9mtDpCNaQ6XOcgGi6Zl6mxbZD4KejByhPj1Xdk8yHX8GE4Ni3gHY5hWHXEjqtXIBV ssKhu7n7LLiwLezAbUTtjixDKxshpLRVI3Fu6OlWJLbatNrhBh4QHqLJhVFrMqdlWopS X7IQvX7bpGLHyBaDXUMxap9QsAaradjCP6JuHVo9T2pV+3hQNGuknwY19ySThbR8vZXQ h2PQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=fUhSXz+uQwBXv8ZeCob/v8qJnVskEL8OVk7VEeT6Ao8=; b=NEPQRlrB3LoxUMxnMhO3uknkf/sd9tvwDPWSm7+lQRdgEcAoq/MDLxObcUgUWFfBDG eci9PKMXdMmUW/lZTgVIySwUCKW9ATt89Tf1k3UXQ4Fbx03ZdxU/mBnv/GkCh4A39hMg ie4VF72kC26DHd0E2ayQ9TCH2g5watx2bOHzWnEfY2W4AbrYdOCEOm1xbM2Go5RDwb6B J8PW4WzYECrZtkZEEDkhzhgCjLxIFfUbH6tBq9l58ArD2vTODg5FB0UCJyY/mfAW0imf KtR4AP+X8JOZeP+WKvqfpX5FErduWWsIUBFoKErACZUn68GMJfhUHLgK5kCP2GHBYKeg I0HQ== X-Gm-Message-State: AFeK/H0hbKisBUDHCV9GJCdIMcWDLQnyVtt6PggR4OXPjfG1v8UR7GEKxmaUJt1yKrq9aA== X-Received: by 10.237.33.69 with SMTP id 63mr4534997qtc.109.1490990521625; Fri, 31 Mar 2017 13:02:01 -0700 (PDT) Received: from HEDWIG.INI.CMU.EDU (HEDWIG.INI.CMU.EDU. [128.2.16.51]) by smtp.gmail.com with ESMTPSA id v63sm4243558qkc.5.2017.03.31.13.02.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Mar 2017 13:02:00 -0700 (PDT) Date: Fri, 31 Mar 2017 16:01:59 -0400 From: "Gabriel L. Somlo" To: Phil Dennis-Jordan Cc: edk2-devel@ml01.01.org, Jordan Justen , Laszlo Ersek , agraf@suse.de Message-ID: <20170331200158.GE17098@HEDWIG.INI.CMU.EDU> References: <1488856465-8965-1-git-send-email-gsomlo@gmail.com> MIME-Version: 1.0 In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.8.0 (2017-02-23) Subject: Re: [RFC PATCH 0/6] OVMF: HFS+ (and Mac OS X boot) X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 20:02:03 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 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