>     External attribute-types are identified by class-name and an 32 bit id.
>     Internal attribute-types are identified by a kernel-structure-type 
>     depended index.

This is a good idea (at least it seems so to me, because I'm working on
something similar for some internal projects -- it gives a good way
to extend ROM-based code).  This idea can be used, for example, to
canonically identify "optional" system calls -- one looks up the 
system call by ID, gets a short number (index in the system call table),
and then just uses the short number to issue the system call.  Ditto
for generalized IOCTL operations, and even matching up things like
device numbers to device drivers.  

However, 32-bit ids are a problem if the ID name space is not centrally
administered.  Since you have to do a lookup, I recommend that you 
use something like the 128-bit UIDs that Microsoft uses for OLE, 
and (I think) has proposed to IETF for use as 'globally unique ids'.
I'm pretty sure the generation algorigtm is given somewhere.  It doesn't
matter if you use exactly the same scheme, it's the idea that is nice.

In our application, I was planning on allowing the ID to have a pre-
computed hash code appended -- once you decide that a UID has to be
passed by reference, the hash code can be carried as well, for free.  

For various reasons, I was going to use the Microsoft standard UID 
format (it's easy for our customers to understand), so the hash code 
had to be appended as an extra step; so I couldn't included in the basic 
format.  You would have no such limitations, of course.  

(If NetBSD decided to standardize on a UID format, I would switch
to it in preference to the Microsoft format, because there
already is a fair amount of code interchangability between our
platforms and NetBSD -- and we use NetBSD for development.)  

For completeness, I'll mention how I was going to compute the
hash code.  After doing some reading on coding theory, I decided 
that 16-bit SDLC CRCs make an good hash code -- quick to compute 
(with table lookup), and a well-defined and well-scattered mapping 
of text to code.  In our application, we always use out-of-table
chaining; I'm superstitious enough to use a multply to map 
into a prime-sized hash table, but USHORT x USHORT-const multiplies, 
followed by a 16-bit right shift, don't take very much time even on 
relatively slow machines.  I wanted to retain the flexibility to
adjust the hash-table size based on the anticipated number of
entries, hence the notion of saving a hash code with enough
bits to support any reasonable hash table size.  

--Terry