From: Bill Rees Subject: Item #412: RE: Item #411: Mac HFS support for CHRP Date: Tue, 8 Jul 1997 13:36:13 -0700 Ron, Where might I find the 1.7 CHRP spec? bill >---------- >From: ron@apple.com[SMTP:ron@apple.com] >Sent: Tuesday, July 08, 1997 1:00 PM >To: p1275-wg >Subject: Item #411: Mac HFS support for CHRP > > To: Mail list p1275-wg > From: > >P1275 Open Firmware Working Group Proposal -- Proposal #411 Ver 1 > >Title: MacOS HFS File System Support > >Author: Ron Hochsprung > >Date: 7/7/97 > >Ed/Tech: Technical > >Synopsis: Add HFS support requirement to CHRP > >Doc & Version: CHRP binding, Revision 1.7 > >Problem: MacOS now requires support for HFS > >Rationale: > >In order to cleanly support Macintosh ROM-in-RAM and Rhapsody booting, >Apple has determined that support for its HFS file system is now >required for CHRP platforms. Some implementations already support a >subset of the required facilities. This proposal is meant to specify >the exact requirements of the HFS implementations. > >The basic support of HFS involves locating a file by name in a >heirarchical scan of a specified volume (partition). The representation >of file names to allow extended character set support uses the HTML and >Apple Single/Double encoding to represent characters unambiguously and >to represent "illegal" characters (e.g., a space in a MacOS file name). > >In addition to locating files by name, the MacOS allows files to be >located by 'type' and/or 'creator', which are properties of a file that >are contained within the file's catalog information. The HFS support >required by this proposal supports locating a file by its 'type'. > >The ROM-in-RAM packaging is planning to use the "bootinfo" mechanism. >The bootinfo file will contain the normal bootinfo.txt text information, >but will also include the ELF-encoded client program and the ROM image. >This single file then encapsulates everything necessary to support >ROM-in-RAM. A bootinfo file will be required to be in the "blessed" >folder (usually called "System Folder") of the selected MacOS boot >volume for that volume to be considered "bootable". (A folder is >"blessed" by virtue of containing both a "system" file and a "finder" >file.) > >However, due to internationalization issues, and the ability of users to >arbitrarily rename their files, locating files by name does not provide >a "standard" way of locating the bootinfo file. So, in addition to >locating a file by name, a special syntax is used to specify a file by >MacOS "type" and to specify that the "blessed" system folder be used >instead of the root. The "blessed" system folder of a volume is >identified by its unique catalog ID in the boot-blocks of the volume's >Master Directory Block. > >Proposal: > >The following changes are proposed in the 1.7 version of the CHRP >binding. I use HTML italics (,) and bold (,) to indicate >the desired typography in the document. > >>>> add new table entry for Table 1, page 18, under Any block device: > > device:partition,:???? Mac HFS file system > >Note: ???? is TBD, hopefully by meeting time. > >>>> replace line 42 of page 56 with: > > ? MacOS Heirarchical File System > >>>> add new section: > >

1.1.1.2 Mac HFS File System Support

> > A CHRP platform that is to support the MacOS shall > support a Mac HFS volume by detecting the HFS partition > signature and interposing an HFS file system package. The > complete syntax that shall be supported by this mechanism > by an open-dev of an HFS file is as follows: > > device:[partition],[folder-pathfilename] > > where device is the device's pathname (e.g., > '/pci/mac-io/scsi/disk@0'), partition is the (decimal) > partition number, folder-path is the heirarchical > sequence of folder names using '\' as the separator and > filename-or-type is the target file's name or type. For > each of the folder, filename or type components, special > characters (e.g., space or '\') are represented by '%nn', > where nn are 2 hex digits that are the character's value. > > If partition is present, then corresponding partition map > entry is used to locate the partition. If the specified > partition does not exist or is not a valid HFS partition, the > open-dev shall fail. If partition component > is absent, the first HFS partition is implied; if no such > partition is found on the device, the open-dev > shall fail. > > The folder-path component consists of a sequence of > folder (directory) names separated by '\'. If the first > character of folder-path is '\', then the search is done > starting from the root of the volume. > > If the first character of the folder-path is not '\', > then the search starts with the "blessed" folder of the volume. > If no "blessed" folder exists for the specified volume > (partition), the open-dev call shall fail. > > The filename-or-type component is either a filename or > consists of a ':' followed by 4 (possibly '%nn' encoded) > characters that is the file type to be located within the > specified folder. If no such file exists, the open-dev > call shall fail. If multiple files of the given type are > found, any one of them may be used. > >>>> the OPEN algorithm starting on page 57 is still!! has some errors. >I plan to clean it up and submit it as another proposal. > >[ P1275 Item #411 -- Received: Tue Jul 8 13:01:14 PDT 1997 ] > > [ P1275 Item #412 -- Received: Tue Jul 8 13:41:13 PDT 1997 ]