Re: uuid_name_lookup()
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 2783268 /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
Re: uuid_name_lookup()
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 dholl...@netbsd.org
Re: uuid_name_lookup()
On Sat, Aug 06, 2016 at 12:56:19AM -0700, John Nemeth wrote: > It seems that I have three choices: extend sys/tree.h, convert > uuid_name_lookup.c to use the newer sys/rbtree.h, or redo it > completely. I was thinking of a small array to cache the items > being looked up. It is highly unlikely that more then a handful > of items will be needed at any given time, which means that using > an rbtree is overkill and the time spent manipulating the tree is > likely to be excessive overhead. Any thoughts on which route to > go? 4th alternative: provide the same api but internally use cdb(5) Martin
uuid_name_lookup()
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. The code is here: http://gitweb.dragonflybsd.org/dragonfly.git/blob/refs/heads/master:/lib/libc/uuid/uuid_name_lookup.c or http://tinyurl.com/j4kotc7 . The problem is that the code uses sys/tree.h with extensions (the DragonflyBSD version is based on an old NetBSD version). Also, the interfaces in sys/tree.h are considered to be deprecated. It seems that I have three choices: extend sys/tree.h, convert uuid_name_lookup.c to use the newer sys/rbtree.h, or redo it completely. I was thinking of a small array to cache the items being looked up. It is highly unlikely that more then a handful of items will be needed at any given time, which means that using an rbtree is overkill and the time spent manipulating the tree is likely to be excessive overhead. Any thoughts on which route to go?
