RE: MIT shared memory extension

["Robert Collins" <robert dot collins at itdomain dot com dot au>]

This is off-topic for the xfree mailing list, it's really a developer or
general topic. Anyway....

> -----Original Message-----
> From: Ralf Habacker [mailto:Ralf.Habacker@freenet.de] 
> Sent: Friday, May 10, 2002 5:36 AM
> Robert Collins wrote:
> 
> > In short, I don't like the idea of making key_t 32 bits.
> >
> I have taken deeper into ftok and have some questions:

The current implementation (excuse the indenting):
key_t
ftok (const char *path, int id)
{
  struct stat statbuf;
  if (stat (path, &statbuf))
    return (key_t) -1;
  /* dev_t is short
   * ino_t is long
   * and we need 8 bits for the id
   */
  return ((long long) statbuf.st_dev << (5*8)) | (statbuf.st_ino << (8)
) | (id & 0x00ff);
}

> 1. Why do you use st_dev explicity. Isn't ftok() only for 
> files ? From the ftok documentation: "The ftok() function 
> returns a key based on path and id that is usable in 
> subsequent calls to msgget(), semget() and shmget(). The path 
> argument must be the pathname of an existing file that the 
> process is able to stat()."
>
> So st_dev seems to make no sense for me and could be removed.

Possibly. If the file can be stat'd - and devices can - we should check
it, no?
 
> 2. Does st_ino creates uniq inodes rsp. hash values ? If so, 
> why not (CASE1) adding an ascii representation of id to the 
> path and calling hash_path_name() (the function which creates 
> statbuf.st_ino) or (CASE2), using id as hash value for 
> hash_path_name() like the following code.

hashs collide. key_t's can not collide under any circumstance, and must
be deterministic (i.e. not dependent on currently issued keys).

How do you suggest that you avoid hash collisions?

Rob