This is the mail archive of the cygwin-xfree@cygwin.com mailing list for the Cygwin XFree86 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: 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





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