Re: key64_t? ino64_t?

["Charles Wilson" <cygwin at cwilson dot fastmail dot fm>]

On 11 May 2003 14:07:14 +1000, "Robert Collins" <rbcollins@cygwin.com>
said:

> Yah. And chris's work to use the native NT inode information will remove
> the chance of hash collisions completely. We will need with a 72 bit
> key_t, or a lookaside table. FWIW I think a lookaside table may not be
> worth the work (*). (I've changed my mind :})
> 
> Note: You'll need cygserver running if you use a lookaside table. It
> won't be doing any ipc logic, just maintaining the persistent
> key<->inode translation.
> 
> (*) st_dev may not be needed in the key once we are using the native
> inode values - IF the NT upper 64 bits are the filesystem ID. IF they
> are, then we have the native device id already in the key so our key
> becomes
> 
> struct {
>   native_inode_t inode;
>   u_short keyid;
> };

Unfortunately, the NT upper bits are not the filesystem ID, according to
Corinna's investigation.  So, we need dev_t, too.  And besides, the
struct idea is a really really bad, IMO.  People expect key_t to be a
primitive, don't they?  Sure, key1 < key2 doesn't mean anything, but key1
== key2 ought to be meaningful.  So, you'd have to implement operator==,
which makes key_t a class, not a struct.  

But that kills packing (e.g. a key_t object is no longer '72 bits of id
data') because key_t now has vtables, ctor, dtor, etc etc.  I *really*
don't like the idea of making key_t a non-primitive type.  Why should we
-- linux doesn't, and they've decided to live with aliasing into 32bits. 
Surely we can live with a 64bit space, and its one billion times lower
probability of clashing?

What do you think of the attached patch?  (The comments explain my
rationale).

--Chuck
--
  Charles Wilson
  cygwin at removespam cwilson dot fastmail dot fm

Attachment: 64bit_keyt.chg
Description: application/unknown

Attachment: 64bit_keyt.patch
Description: application/unknown