Re: Adding an ioctl to check for disklabel existence

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sun, 29 Sep 2019 13:32:51 +0200
    From:        Martin Husemann <martin%duskware.de@localhost>
    Message-ID:  <20190929113251.GA12540%mail.duskware.de@localhost>

  | If you just ask for the label
  |
  | 	disklabel $mydisk
  |
  | you will always get something.

Yes, we will - but can't we make that something detectable?   If the
kernel invents a lael, it says "fictitious" in the label field.
All we need to do is make sure that no label read from a disc (into
the kernel, if read directly by userland, then userland knows what it
got and from where, already) contains that value, right?   Like if
someone has actually written a label with that string ("fictitious")
to a drive, then when read back we just change it to "unnamed" (or even
just empty)  -- it is a bit hard to believe that anyone wants their drive
actuially named "fictitious" (they'd still be able to use "fictional"
if they wanted).

  | Now sometimes it is important to know the difference.

If we do that, we will know the difference, and what's more:

  | some architectures have native ways to store their partitions [...]
  | The kernel converts internally from the native partitions to disklabel when
  | trying to read a disklabel,

when that happens, it could set the label to "converted" or if
the native format has a name that we include, put that name in brackets
("[name]") or something so it can be reconised (and then remove the
brackets if this is one of the cases where the kernel coverts back).

  | Userland, however, has no way (that I know of) to learn about
  | such conversions.

After that it would have, without need for extra ioctls (or for that
matter, any extra system call or work beyond a strcmp or two) - and what's
more it would work just fine with existing tools, as only the kernel, and
then utilities that desire to make use of the extra info (sysinst I presume)
needs to be changed.

We could have the disklabel utility refuse to allow the user to write
back a label containing "fictitious" (or "converted") as a name sometime
later (or now, bnut that isn't really crucial, and people using existing
tools wouldn't see such a change anyway).

  | Or just extend and version DIOCGDINFO to provide that flag word in addition
  | to the disklabel?

Do we actually need something new, or just this interpretation of the
label field?

kre