--98e8jtXdkpgskNou
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 25, 2004 at 12:39:49PM -0400, Rian Hunter wrote:
> > Well, I'm not a responsible on macppc port, but personally
> > I still like bootxx/partition 0 methode (of course "loading from
> > MS-DOS paritition" could be optional one though) because I only have
> > old Apus compatible which has OFW 2.0 ;-)
> > The machine can use bootxx/ofwboot and I don't have to have
> > an extra MS-DOS partition (and the FDISK label) to load kernel.
> > (BTW I think installboot(8) should be fixed to recognize existing
> >  apple partition map though)
>=20
> in the partition 0 method on the hard disk, is ofwboot located in
> partition zero alongside bootxx? then it becomes responsible for loading
> netbsd off of the FFS filesystem?

There is no partition zero. What happens in this case is that OF loads a=20
driver off of the disk to handle booting. installboot will fake up an APM=
=20
and a driver that uses bootxx to load ofwboot.

> > Some people also want to share disks with MacOS-X, and others
> > uses Apple_UFS (though I don't know it very well ;-p) on
> > NetBSD. I think the Apple partition map is required in that
> > case so I guess FDISK partition can't exist on such disks.

MBR partition maps can coexist with Apple partition maps. MBR uses the=20
tail of block 0, and APM uses the begining.

> personally, since these are Apple machines, and i'm a little pedantic,
> it would be the right thing to do to keep the Apple Partition Map. But
> seeing as hardly anyone uses their Old World machines for dual booting
> (hah! imagine dual-booting MacOS 7 with NetBSD) it would make sense to
> ditch the Apple Partition Map, not to mention bootxx since it only slows
> down booting time. that's just my two cents.

Well, then we'll have to disagree. I will object to us getting rid of=20
Apple partition maps. They are the native format for the main OS for the=20
box, and they are much easier to work with than MBR partitioning schemes.

> another question comes to mind though. why isn't there adequate support
> in the NetBSD kernel (or any Free Kernel) for the HFS(+) file systems?
> is this just a lack of effort or work in that area or licensing issues
> (using code from darwin)?

Problem is no one has done it. All the open source implementations have=20
varying degrees of restrictions.

Back in '96, Paul Goyette (sp? sorry Paul!) and I had an implementation of=
=20
HFS kinda working, but we had locking issues. Also, the code we started=20
with had a restriction on it that it couldn't be used by the military.=20
That is a sufficiently restrictive license that the code would never make=
=20
it into the tree. One of the best implementations out there is GPL'd, and=
=20
would never get changed as it used code that was contributed to it under=20
the GPL. As it was GPL'd to keep it away from the large software company=20
in Redmond WA, we were unable to get the license changed.

Darwin code is under the APSL, which may or may not be ok in the NetBSD=20
kernel.

=46rom looking at the Darwin code, there is quite a lot of stuff in it, so=
=20
an independant implementation would have a lot of work to do.

Take care,

Bill

--98e8jtXdkpgskNou
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFBM5tUWz+3JHUci9cRArnYAJ9N59fMmMoxik0/VqbMsalmBZ30WACggLc7
YLA4btaU3NrNzVpuUuXCubk=
=UofS
-----END PGP SIGNATURE-----

--98e8jtXdkpgskNou--