Re: uuid_name_lookup()

[David Holland <dholland-tech%netbsd.org@localhost>]

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.

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.

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
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
perfectly capable of patching the source. Provided there's a way of
entering one by hand that gpt doesn't know about yet, but I'm told
there is.

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.

Let's not add new non-administrator-maintained data to /etc.
Especially stuff like this that isn't even configuration.

-- 
David A. Holland
dholland%netbsd.org@localhost