Subject: Re: Proposal for new Apple Partition types
To: Frederick Bruckman <fredb@immanent.net>
From: Bill Studenmund <wrstuden@netbsd.org>
List: port-macppc
Date: 02/08/2002 10:49:00
On Thu, 7 Feb 2002, Frederick Bruckman wrote:

> On Thu, 7 Feb 2002, Bill Studenmund wrote:
>
> > On Thu, 7 Feb 2002, Frederick Bruckman wrote:
> >
> > My concern is that it adds LFS support, but nothing more. While I admit
> > LFS is probably the one FS type we'd most want to add, I'd rather add
> > support for *all* fs types we can encode in a NetBSD Disklabel.
>
> One thing at a time. I mostly just wanted to play with LFS on the Mac.
> I real, bona-fide, editable-in-place NetBSD disklabel would be nicest of
> all, but then the problem is to find a safe place to write it to...

Ahhh! I'm suggesting being able to encode all partition types, but I'm not
suggesting writing a NetBSD label. :-) I'm suggesting being able to write
into an Apple partition (of type "NetBSD-something") all the info we store
per partition in a NetBSD disklabel. :-)

> How about... a program that can set the in-core label to whatever the
> user requests, without regard to the Apple Partition table on the disk?
> An "rc.d" script could load the label from "/etc/disklabels" or
> "/etc/disktab" at start-up time. Of course, the root partition better
> match the partition you booted from, just like the "/" entry in
> "/etc/fstab" needs to match the root you booted from. This would let you
> mount volumes on MSDOS disks, Apple disks, disk images, even read-only
> disks, that have more partitions than can be represented in the NetBSD
> disklabel, and would let you avoid surprises in NetBSD after
> rearrangement or renaming of unused partitions (unused by NetBSD).

That's a whole other kettle of fish. I think everyone agrees the best way
to do things is to move to having the in-kernel "disklabel" be read-only,
and to let userland be able to set it.

But I don't think we need an /etc/disktab. A program/daemon should be able
to read things fine. Unfortunatly I don't have time to flesh all of this
out. :-(

Take care,

Bill