On 11 Feb 2022, at 14:04, Chuck Lever III wrote:
Yes. We're not using the output of the tool for anything
else. At the very least the man page should explain the
proposed client ID usage as an EXAMPLE with an explanation.
But honestly, I haven't seen any use case that requires
this exact functionality. Can you explain why you believe
there needs to be extra generality? (that's been one of
the main reasons I object to "nfsuuid" -- what else can
this tool be used for?)
Not yet, no.
If we name it nfsmachineid or nfshostid,
do you feel like we ought to have it do the much more complicated job
of
accurately outputting the actual client id?
It could do that, but the part that the kernel struggles
with is the uniquifier part. That is the part that _has_
to be done in user space (because that's the part that
requires persistence). The rest of the nfs_client_id4
argument can be formed in the kernel.
Sure we could, but what I was trying to point out is that your names are
just as miserable if you apply your exacting logic to them, and we're
going
to be hard-pressed to meet the bar unless we name it something
completely
meaningless.
Right now nfsuuid outputs uuids (or whatever was previously stored,
up to 64
chars).
Right. It can output anything, not just a UUID. It will
output whatever is in the special file. If the content
of that file is a random string, what will nfsuuid output?
64 chars of random string.
If someone runs nfsuuid expecting a UUID and gets the
random crap that was previously stored in the persistence
file, wouldn't that be surprising?
Nothing on stdout surprises me. After years of sysadmining I'm cold as
ice.
Precisely because it has the ability to output whatever
is in the persistence file, and that file does not have
to contain a UUID, that makes this tool not "nfsuuid".
Alright.
It generates uuids, like uuidgen. Without something external to
itself (a udev rule, for example), it doesn't have any relationship
to an
NFS client's id. It could plausably be used in the future for other
parts
of NFS to generate persitent uuids. The only reason we don't just
use
`uuidgen` is that we want to wrap it with some persistence. A would
a name
like stickyuuid be better?
No: a UUID is a data type. Would you call the tool
nfsunsignedint if we stored the ino of the net namespace
instead?
I really might, sadly, just to get the job done.
Do you have any other specific use cases for an nfsuuid
tool today? If you do, then you have a platform for more
generality. If not, then there really isn't any other
purpose for this tool. It is a single-tasker, and we
shouldn't treat it otherwise.
All the arguments for exacting tolerances on how it should be named
apply
equally well to anything that implies its output will be used for nfs
client
ids, or host ids.
So, I've forgotten your other suggestions that don't have anything to do
with NFS or clients or machine IDs. I'll make more suggestions:
persistychars
mostlyuuids
theuniquifier
randomonce
distroschoice
I like these. These names are more fun. :)
In good will,
Ben
