Robert Collins wrote: > >>-----Original Message----- >>From: Ralf Habacker [mailto:[EMAIL PROTECTED]] >>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
