Re: uuid_name_lookup()

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Aug 17,  1:54am, David Holland wrote:
} On Sat, Aug 06, 2016 at 12:56:19AM -0700, John Nemeth wrote:
}  >      I'm thinking of importing uuid_name_lookup() and uuid_addr_lookup()
}  > from DragonflyBSD.  These functions look in a file, /etc/uuids and
}  > /etc/defaults/uuids, which contains a table mapping uuids to
}  > descriptive strings.  The advantage is that it makes it easy for
}  > various tools to know about new uuids without having to recompile
}  > them.
} 
} Except it doesn't make sense to have one big slushpile for all
} different kinds of uuids. If one is going to have such a file it
} should have at least some minimal type information to indicate what
} the uuid is a uuid for. Otherwise eventually you'll end up paging
} through hundreds of completely irrelevant things to find what you're
} looking for. And we'll have clueless users using uuids of the wrong
} kind in the wrong places.

     Right now the only place that we commonly use UUIDs is with
GPTs, but I see your point about being able to specify the purpose.

} And given that I don't think the file is a good idea, I don't think
} there's anything to be gained by importing the code for reading it.

     I like the idea as it simplifies things a lot.

} For partition types in gpt(8) I think it doesn't even make sense to
} have an external file; new partition types don't come up very often

     True, but I'm sure that there's some that we don't know about.
I gathered all the types I could find in a variety of locations,
so I have what I think is the most complete list.  However, given
that there is no central repository, it is quite likely that I'm
missing some.  So, I'm thinking about making it easy to add new
ones as we learn about them.  Being easy, means they are more likely
to be added.

} and it's easier for everyone if the list of known types is just
} compiled in -- anyone who's defining their own new ones will be

     Not really.  There are four different files to be edited.
That's ridiculous and error prone.

} perfectly capable of patching the source. Provided there's a way of

     Possibly, but that doesn't mean that they should have to do
so.  Especially if that would be the only reason to patch the source.

} entering one by hand that gpt doesn't know about yet, but I'm told
} there is.

     Yes.  That's actually what is expected.  But, if you give it
something that isn't a UUID, it will try to lookup the string that
you give it in a table.

} If you really want to have the list in an external file, I think it
} should be gpt-specific. I'd also recommend putting the file with the
} known types in /usr/share; e.g. /usr/share/misc/gpt.types or
} something. Then only if you really, really think it's worthwhile also
} add the abililty to read a supplementary /etc/gpt.types that has only
} new local types in it.

     I'm not sure I like the idea of /usr/share since that isn't
part of the base set.  My current file isn't all that big:

i386devel: {174} wc /usr/src/share/misc/gpt-uuids
     107     278    3268 /usr/src/share/misc/gpt-uuids

And, that's with plenty of comment lines.  The actual number of
entries is:

i386devel: {180} grep -cv '^#' /usr/src/share/misc/gpt-uuids
50

} Let's not add new non-administrator-maintained data to /etc.

     There would be nothing stopping the administrator from changing it.

} Especially stuff like this that isn't even configuration.

     You could consider it to be configuration for gpt(8).  :-)
Yes, I know that's stretching it.

}-- End of excerpt from David Holland