Ty Sarna wrote:

> I imagine something along the lines of:
> 
> options DISKLABEL_BSD		# traditional BSD disklabels
> options DISKLABEL_MSDOS	# msdos disklabels
> options DISKLABEL_RDB		# Amiga RDB labels
> options DISKLABEL_AHDI	# Atari disklabels
> options DISKLABEL_SUN		# SunOS labels
> ...
> 
> I imagine configured types would be held in a list like the emulation
> list. They would be probed in order, and a default scheme (call it
> "DISKLABEL_NONE", but it would probably not be optional) would be used
> to make a label with just a c partition.

Looks good. I just wonder if there could be clashes between the vendor
specific labels. The AHDI label must be one of the worst, no magic
numbers, no checksums, just try to find some sensible data, doing as
much sanity checks (e.g. partition extends beyond medium) as possible.
I wonder if any other vendors were foolish enough to `invent' such
nonsense.

> Ideally the scheme would also follow the proposed emul reorganization,
> and allow a specific format to be specified to the write ioctl, to allow
> a sparc to partition a DOS disk, or whatever

I suppose you mean re-initialising the disk, not transferring from one
format to another, while keeping all original partitions and data?
 
> (or for that matter, to allow a DISKLABEL_NONE disk to be partitioned
> in the first place).

It seems that this is not possible on some (most?) platforms. I wonder
why? Just because the manual says it isn't possible? (I didn't read
the manual before implementing the stuff, but now that I've read it
I can't see why this should not be allowed).

> Note that some disklabel formats would want to be read-only (as they are
> already), since writing RDB (or AHDI, which sounds similar) labels would
> be impractical, and in fact undesirable.

Indeed, that's one of the reasons to have a NetBSD disk label within one
of the AHDI partitions. The former can easily be modified and rewritten,
which is mostly impossible (or at least extremely complicated) with the
latter.


Waldi