Re: Adding an ioctl to check for disklabel existence

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> So far all good. But there is a catch: some architectures have native
> ways to store their partitions and no real userland support for those
> schemes.  [...]

> Userland, however, has no way (that I know of) to learn about such
> conversions.  The above recipe with "disklabel -r" will fail on such
> disks, as -r makes disklabel check for a *real* disklabel and fail if
> there is none (and besides arcon32, the userland disklabel binary
> does not know of any such magic kernel conversion). [ side note: that
> acorn32 magic userland code should be removed ]

Userland has fdisk for MBR parititoning, disklabel -r for BSD
disklabels, and sunlabel for Sun labels.  (Are there other such tools?
I'm not aware of any.)

It seems to me that the rightest ways to go, depending on which way
NetBSD wants to jump here, are

(1) Eliminate such knowledge from userland entirely.

(2) Merge tools such as fdisk and sunlabel into disklabel -r (though
MBR partitioning is a bit of an odd duck in practice, because MBR
partitions are typically carved up further, which in my experience is
not true of either BSD or Sun labels).

(3) Split acorn32 userland code out into a separate userland tool a la
sunlabel; ideally, write similar tools for any other formats of
interest (IIRC mac68k has one, though that memory is fuzzy; there
doubtless are others I know nothing about).

(4) Something else I haven't thought of.

That is, pick a direction and then go there.  The current state is a
rather ad-hoc mishmash of all three of the above, with all the issues
that inconsistency brings.

Personally, I don't like (1), because I find such tools too useful; I'm
not sure whether I prefer (2) or (3).

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B