Subject: Re: Why the partitioning should stay the same
To: Brian Gaeke <brg@dgate.ping.com>
From: Chris G Demetriou <Chris_G_Demetriou@LAGAVULIN.PDL.CS.CMU.EDU>
List: macbsd-development
Date: 01/27/1995 02:08:07
[ I didn't mean for this to get this long, and god damn it, i hate
  typing on this laptop, but... ]

> I strongly agree with Allen here -- keep the partitioning the way it
> is, because it works fine. The only reason I run Linux on my PC instead
> of NetBSD is that the PC also is used for real work (i.e. DOS), and I
> can't blow away the whole disk just so I can use NetBSD. 

And your point is?  NetBSD/i386 has been able to coexist on the same
disk with dos since day "1" of its existence, and it's apparently not
even too hard to do.  a fair number of people do it.

most of your argument is a straw-man, erected out of ignorance of the
capabilities of NetBSD/i386 and of the operation of the various
partitioning methods.

> So it is logical that each architecture port might have its own way of 
> acclimatizing UNIX to its native partition schemes, whether they be brain-
> damaged or not.

To a degree.  If an architecture's partitioning scheme provides a
benefit, then it should be investigated.  nothing about the mac's
partioning scheme provides any benefit.  (In fact, it more or less
looks like the PC BIOS partitioning scheme, with some sugar and with
support for more partitions.  It's nothing particularly 'odd'.)

> NetBSD/i386 has its lots-of-partitions-in-one scheme, which
> is distinctly inferior (IMO), in terms of compatibility, to Linux's method of
> simply having normal DOS partitions for user- and swap-areas.

having "many partitions in one native operating system partition"
(where "native operating system" can mean "PC bios" or "MacOS" or
whatever) DOES have several distinct advantages:

	(1) NetBSD can repartition its space easily.
	(2) NetBSD takes up only one 'native operating system'
		partition
	(3) it's "standard"
	(4) it's easy to manipulate (i.e. it's easy to find disklabel,
		etc.)
	(5) the admin can explicitly control which partitions appear
		in the NetBSD disklabel (by creating entries for them,
		or not creating entries for them)
	(6) mapping of disk locations to partitions is deterministic,
		as it's completely controlled by the disklabel.
		(no dynamic changing of whatever the root device
		happens to be to the 'a' partition, as happens on
		the amiga port)

> NetBSD/mac68k,
> on the other hand, has a Linuxy partition style: 1 macos partition for each
> 1 BSD partition. Is that so bad? It's certainly less complicated.

What if, in linux, what if you want to have seperate root,
/usr, /var, /a, /b, and swap partitions _ALL ON THE SAME DISK_?
you're out of luck, if you're using _ONLY_ the PC bios
partitioning scheme.

Also, it is _NOT_ more complicated.  Consider the work involved in the
two partitioning schemes:
	"many in one":	on start:
				find location of NetBSD partition.
				read NetBSD disklabel into core.
			when accessing data:
				add physical block number offset to
				    partition start offset in volume
				do the i/o.

	"many native":	on start:
				find locations of all NetBSD
				    partitions and any non-NetBSD
				    partitions which NetBSD is to be
				    given access to.
				fake up a disklabel, taking care
				    to assign the partitions that
				    NetBSD can access to disklabel
				    partition entries, in some sane,
				    deterministic way.
			when accessing data:
				add physical block number offset to
				    partition start offset in volume.
				do the i/o.

the per-access complexity of the two schemes is _identical_, and the
complexity of the code used to 'bootstrap' each scheme is a fair bit
simpler for the "many in one" method.
			
> Thus, having a weirdo partition scheme is a direction that I am specifically
> interested in seeing NetBSD/Mac stay away from.

And what NetBSD/mac68k has _RIGHT NOW_ is a weirdo partitioning scheme.

It overloads vendor-specified partition id's.
Space can't be repartitioned within NetBSD.
It has to assign partitions to partition numbers in an odd way,
	and removes the admin from this decision-making process.

Best of all, it provides _NO_ tangible benefit over a "disklabeled
partitiong within MacOS partition" scheme.



"next customer?"


chris