This is the mail archive of the
cygwin-xfree@cygwin.com
mailing list for the Cygwin XFree86 project.
Re: MIT shared memory extension
Robert Collins wrote:
>
>>-----Original Message-----
>>From: Ralf Habacker [mailto:Ralf.Habacker@freenet.de]
>>Sent: Tuesday, May 07, 2002 7:41 AM
>>
>
>>What about using a new type respective casts for cygdaemon.
>>This would not break key_t compatibility and allows to
>>migrate single application to cygdaemon, while others works
>>with cygipc (at least for a limited time) ?
>>
>
> At the moment key_t's are generated locally without the cygserver. This
> means that in theory a cygipc linked app will still work with the new
> key_t code after recompiling (I think we do need to remove ftok from
> cygipc at that point though). If we have a list of key_t's, then it must
> be global, so cygserver will have to be running. I think that that is
> bad.
Hmmm??? Where would clients get ftok() from, then? Do the cygserver
patches to CVS cygwin1.dll add that function to the kernel?
> Also at the moment, we know that the same file will generate the same
> key_t every time. (because it's inode based).
Ah, a quick 'cvs update' and I see the answer to my question is yes.
So, I can't really remove ftok() from cygipc until after cygwin-1.3.11
is released...
> In short, I don't like the idea of making key_t 32 bits.
Yep.
--Chuck