Subject: Re: Disklabel ioctls (was Re: nore on disk ...)
To: None <tech-kern@NetBSD.ORG>
From: Ty Sarna <tsarna@endicor.com>
List: tech-kern
Date: 11/17/1995 00:40:56
In article <m0tG7Py-0000jwC@moacs.indiv.nl.net>,
Waldi Ravens  <waldi@moacs.indiv.nl.net> wrote:
> I believe that, if support is added for all the vendor specific disk
> formats of currently supported platforms, it should be configurable.
> Otherwise it just adds a lot of hardly ever (or never) used code to
> the kernel. If, for example, in the current situation, I throw the
> AHDI compatibilty code out of disksubr.c, the size of the *disklabel()
> functions will decrease some 75-85%.

Oh, I thought that went without saying. I envisioned something along the
lines of the way emulations are handled now, with COMPAT_XXX options. 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.

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 (or for that matter, to
allow a DISKLABEL_NONE disk to be partitioned in the first place).  If
no format was specified, the current format would be used. 

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.