Date: Sun, 29 Sep 2019 13:32:51 +0200 From: Martin Husemann <mar...@duskware.de> Message-ID: <20190929113251.ga12...@mail.duskware.de>
| 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