This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: key64_t? ino64_t?


On Sun, 2003-05-11 at 13:50, Charles Wilson wrote:

> Actaully, I don't think anything in winsup (other than cygserver itself)
> uses key_t -- and cygserver was designed to use 64bit key_t from the
> beginning.  So as long as the redefinition of key_t in newlib is guarded
> by #if __CYGWIN__ (so that ./newlib/libc/sys/linux/ stuff that DOES use
> key_t is protected from this change), I think you're home free.

ACK.

> Even though we don't want to export the cygserver stuff, we *might* want
> to export *just* ftok.  Currently, cygipc provides it's own
> implementation (which I hope will remain sync'ed with the cygserver
> version after key_t goes to 64bits, IF it goes to 64bits).  That
> synchronization is obviously much easier if there's only one copy, and
> cygipc-the-64bit-generation uses the one from cygwin1.dll... See patch,
> below.

I like that idea.

> BTW, Robert wrote in this message (concerning key_t)
> http://www.cygwin.com/ml/cygwin-xfree/2002-05/msg00155.html
> "hashs collide. key_t's can not collide under any circumstance, and must
> be deterministic (i.e. not dependent on currently issued keys)."

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;
};

Rob
-- 
GPG key available at: <http://users.bigpond.net.au/robertc/keys.txt>.

Attachment: signature.asc
Description: This is a digitally signed message part


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]