In article <Pine.NEB.3.96.980204175941.558G-100000@sublimation.anim.dreamworks.com> you write:
> 	This is a very nice idea, but how do you handle the case where
> 	you have two or more partitions named the same on different
> 	disks?
> 
> 		/dev/dsk/sd0/rdb/NetBSD-home
> 		/dev/dsk/named/NetBSD-home
> 
> 	The latter only created when there is a single unique partition
> 	named 'NetBSD-home'.

I don't think so. Having multiple partitions with the name should be
considered a configuration error. As to how to handle this, AmigaOS (or
at least the autoconfig ROM on controllers I used on the occaision
when I did this accidentally -- GVP, I think) uniqify any later-found
partitons with an existing name by adding ".N". Eg, the first partition
named "home" is "home", the second becomes "home.0".

One could argue that it should uniqify both ("home.0" and "home.1"),
purposely breaking fstab to prevent accidentally mounting something in
the wrong place (or worse, for eg database partitions or whatnot). I
think I lean towards this view.

Actually, I guess what you described above would accomplish this
(under "named" if unique, else "<DISKNAME>/rdb"), and give a hint as to
which is which. wedgeconfig should harangue the user about this
condition, though. It should not be considered normal.

> 	Since we would already have that functionality with rdb maps under
> 	NetBSD/amiga it certainly sounds good to have it on all ports...

Well, under mycroft's scheme you could already do this (use RDB's on
NetBSD/i386, or what have you) if you like.  I think that for general
use though we should come up with something less slanted to one port, and
with some improved capabilities. 

> > 4. For those partion map types where names aren't defined, but where we
> > can add them in a backward compatible manner, we should do so.
> > 
> 	Which cases would these be - for something like MBR you would have

I don't know, that's why I was vague :-) I think we should investigate
the possibility of adding that capability to other partition formats. 
For some, I'm sure it can't be done in a reasonable manner.  Others,
like NetBSD/sparc (and sun3?) already use a ROM-readable disklabel in
one place, and a more complete one in another place. Yes, they can get
out of sync, but that's possible now on those ports, right? I guess
wedgeconfig should know about these redundant partition maps and verify
that they match up (and if they don't... uh... well, I don't know :->)

Actually, if the new neutral named partition map type I proposed is
sufficently RDB-like, supporting a compat disklabel and new label on the
same disk (not nested, but pointing to the same partitions) is not too
hard, and could be automated by whatever new partition editing tool we
invent. One of the nice things about RDB is that it doesn't have to
start in block 0. You can start it anywhere in the first 16 (if I
remember) blocks, in order to accomidate bootblocks or whatever that
want to be at 0. The new neutral map type probably should increase the
limit number from 16, though.

Alternately you could stick a label containing a name as the first block
inside the partition under any scheme, with the risk that won't work if
something else wants to be there. I dunno.

> 	/dev/dsk/NetBSD-home runs into problems when someone names a disk
> 	'sd0' or similar... (dumb though it may be)

Hmmm...  good point.  They could also do less stupid things that would
be just as bad.  Maybe MBR.COM (random example) uses a filesystem called
/mbr (we have one called /endicor, after all).  So they name the
partition "mbr", and then things break :-(.  I guess I'm for
"/dev/dsk/named/...".