Disklabel question (versus bug)

[Matthew Dillon]

    I think it's because the in-kernel disklabel (without -r) is not allowed
    to upgrade a FreeBSD disklabel to a DragonFly disklabel.  I haven't look
    at the code carefully but its likely I am doing a sanity check to
    prevent that case somewhere where both DIOCGDINFO and DIOCSDINFO call.
    It's a bug for the GDINFO case.  The reason we don't allow an upgrade
    is because the FreeBSD disklabel does not have room for 16 partitions,
    because FreeBSD moved the boot code to be right after the disklabel
    in order to make room for both UFS1 and UFS2 recognition.

    With -r the disklabel program looks at the disk directly and is able
    to discern the difference between a DragonFly disklabel (with support
    for 16 partitions), and a FreeBSD disklabel.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>


:Perhaps a little background first:
:
:I've been using both DragonFly-current and FreeBSD-current from
:extended(logical) slices for about a year or so.  This is possible
:only because the DragonFly /boot/loader was patched to parse the
:DOS partition table correctly (unlike the FBSD version).
:
:Now -- can any of you gurus explain why the DragonFly disklabel
:program behaves this way when reading a FreeBSD disklabel:
:
:# disklabel ad1s8  [this is FBSD on an extended/logical slice]
:disklabel: ioctl DIOCGDINFO: Invalid argument
:
:BUT, if I add the -r flag, it works normally:
:
:# disklabel -r ad1s8
:# /dev/ad1s8c:
:type: unknown
:disk: amnesiac
:label:
:flags:
:bytes/sector: 512
:sectors/track: 63
:tracks/cylinder: 16
:sectors/cylinder: 1008
:cylinders: 16654
:sectors/unit: 16787862
:rpm: 3600
:interleave: 1
:trackskew: 0
:cylinderskew: 0
:headswitch: 0           # milliseconds
:track-to-track seek: 0  # milliseconds
:drivedata: 0
:
:8 partitions:
:#        size   offset    fstype   [fsize bsize bps/cpg]
:  a: 16273746   514080    4.2BSD     2048 16384 25600   # (Cyl.  510 - 16654*)
:  b:   514080        0      swap                        # (Cyl.    0 - 509)
:  c: 16787862        0    unused        0     0         # (Cyl.    0 - 16654*)
:super block size 0
:
:Is this a bug in 'disklabel'?  Or not.
:
:Thanks for any clues!