> Actually, I thought that there was an ANSI Standard for partitioning scsi
> drives so that multiple systems could co-exist.

that's not the point, here; that standard is not in use.

> The PC bios scheme is inferior to the A/UX scheme. Don't complain because
> you had to live in shackles. What if on NetBSD/386, I want to have /usr
> /var /a /b /c ... /z. I like smaller partitions on my 4gig drive. By
> unmounting the ones that are not in use, I help protect the system from my
> mistakes.

This is a straw man.  You have deliberately created a situation which
is in no way meaningful in 'real life', and purport that partitioning
scheme used by NetBSD/mac68k can address it, while the partitioning
scheme (used by NetBSD/i386 and some of the other NetBSD ports) which
i claim is 'better' cannot.

Why is it not meaningful in real life:
	(1) there is absolutely no benefit to putting that many
		partitions on one disk -- it does _NOT_ help disk
		or file system stability.
	(2) putting that many partitions on one disk is actually
		_quite_ detrimental to file system performance.

Better than that, NetBSD/mac68k CAN'T DO IT ANYWAY!!!

Regardless of whether you do a "many partitions" (i.e. NetBSD/mac68k)
or "many partitions in one" (i.e. NetBSD/i386) scheme,
NetBSD CAN ONLY USE `MAXPARTITONS' PARTITIONS!

Right now, the i386 uses MAXPARTITIONS of 8.  it could use
MAXPARTITIONS of 16, or even 22.  (22 is the maximum reasonable value,
for reasons that become obvious if you read the sources.  22 also
won't allow the compiler to optimize some operations, etc., so it will
be slower than 16...)

The mac68k port could use MAXPARTITIONS of 16 or 22.

But regardless of what MAXPARTITIONS is set to, in NetBSD, on any
port, regardless of partitioning scheme, the system is NOT CAPABLE
of accessing more than MAXPARTITIONS partitions per disk.  It is
theoretically possible to change this.  It it decidedly non-trivial,
however (and requires re-working a fair number of internal interfaces.)

> IMHO, neither approach is "clean" What you really have is:
> 
> 1) The random access device controller(s) = Pick one.
> 2) The device = Pick one.
> 3) The Master Partitioning scheme = (Mac, DOS, Raw) Match one
> 4) The Particular Partition = Pick one
> 5) The NetBSD subpartitions = Find the appropriate one
> 6) The file system organization.
> 7) The particular kernel instance.

This makes very little sense, mostly because you don't make clear
exactly what you're talking about in each instance.

The device controller, device, and 'master' partitioning scheme are
all 'set in stone.'

"the particular partition" and "the NetBSD subpartitions" are what
this discussion is about.  see below.

The file system organization is pretty much already decided, and what
in God's name does the 'particular kernel instance' have to do with
any of this?  ABSOLUTELY NOTHING says that the kernel has to come from
the NetBSD partitions of the disk, or hell, even that it has to come
from _any_ place on the machine being booted.  It can be loaded over
the net, for instance.


Now, about "the particular partition" and "the NetBSD subpartitions."
again, here are the two options (note that the 'per-access' operations
have not been restated, as they're the same for each case):

"many-in-one":
	on startup:
		find the NetBSD partition on the drive.
		load the NetBSD disklabel from it into core.

"many":
	on startup:
		create a disklabel for the disk; fake up various
			fields.
		look through the partition table, matching those
			partitions which it's possible to use in
			NetBSD.
		for each partition matched, figure out which entry
			in the disklabel to use, and fake up
			a partition entry for it.

you tell me, which is 'cleaner'?  the former requires:
	(1) much less knowledge of the native file system
	(2) much less in the way of 'smarts' in the disklabel-getting
		logic

and allows the sysadmin to deterministically create a mapping from
disk locations to partitions,

> >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.
> 
> Simpler is always at the expense of generality.

That's not true.  for instance: would you say that 'cat' is simpler
than 'ex'?  did you know that there are 'general' things that 'cat'
can do that 'ex' can't?

be very, very carefull when you use the word 'always' -- you may be
wrong.  you happen to be wrong here.  I suggest you read the source
before you start explaining the ins and outs of how it works...

For instance, what if you'd like to access a partition whose type the
NetBSD/mac68k kernel does not recognize?

If you're using the "many partitions" scheme, you're OUT OF LUCK,
and at minimum have to recompile your kernel.  If you're using a "many
partitions in one" scheme, all you have to do is add an entry to the
disklabel to describe the partition -- not very hard at all.

Perhaps you're thinking about the number of partitions that are
accessible -- but the fact that you're always limited to MAXPARTITIONS
in NetBSD proves you wrong on this count, too.

> >It overloads vendor-specified partition id's.
> You overload a single partition.

BZZT.  perhaps you don't know what overload means.

NetBSD/mac68k has taken an already-existing partition ID, used for
other things, and usurped it for its own uses.

NetBSD/i386 uses a partition id (0xA5) which has traditionally (since
386BSD) meant "*BSD partition" -- the contents of the "*BSD partition"
are completely up to *BSD, and it just so happens that those contents
have always been "BSD partitions described by a BSD disklabel.


NetBSD/mac68k has taken another partition ID and changed its meaning
(slightly).  NetBSD/i386 has been using one dedicated to its purpose.
The former is overloading, the latter is not.

> In both cases vendor partitions create a sub-device structure.
> The NetBSD partitions are a sub-sub-device level.
> In the case of NetBSD/mac, they REQUIRE that each logical drive be on
> different sub-devices.

Right.  (i'm not going to comment on your notion of these things being
'logical drives' -- it's just not the proper notion, because if they
were truly logical drives, you couldn't access the disk outside of them!)

> In your case, you REQUIRE that they all be in the
> SAME one.

WRONG.  a disklabel can address _ANY_ data on the disk.

i.e. just because all of the NetBSD/i386 data by default happens to
live within a partition of type 0xA5, doesn't mean that NetBSD/i386
CAN ONLY access data inside the 0xA5-marked partition.  Indeed, people
often put entries in their disklabels for DOS partitions, etc.

> Neither scheme is perfect. In both cases, I should be able the specify the
> particular logical devices that I want to use.

"specify the particular logical devices that you want to use"?  FOR WHAT?!

for the assignment of name->partition translation?  You _can't_ do
that reliably under the "many partitions" scheme -- if you delete one
partition that is recognized, they all "slide down" by one slot.

for booting?  that's the boot loader's problem -- it has nothing to do
with what the kernel thinks the partitions are named!

> It is appropriate to be able the have the flexibility to go either way.

the "many-partitions-in-one" with a BSD disklabel gives you all the
flexibility to:
	(1) modify your disklabel while running NetBSD
	(2) access any area of the hard disk

the "many partitions" scheme used by NetBSD/mac68k gives you _NEITHER_.

> When booting, I need to specify both the kernel to load and the initial
> virtual root of a file system. They might be in very different locations,
> even on different types of media and different file systems under that.

Cool, you shop at "Non-sequiters 'r' Us" too?

These have nothing to do with which partitioning scheme is used.
As long as the booter and the kernel understand what partitioning
scheme is in use, this is not a problem for either method.



On a slightly related related note, i see that NetBSD/mac68k doesn't
support RB_DFLTROOT or 'swap generic'.  They're no easier to
implement, but they make a fair bit more sense when used with a "many
partitions in one, with a BSD disklabel" scheme.  They're also _quite_
useful, allowing you to specify your root and swap devices once you're
mostly booted...



chris