RE: MIT shared memory extension
This is off-topic for the xfree mailing list, it's really a developer or
general topic. Anyway
-Original Message-
From: Ralf Habacker [mailto:[EMAIL PROTECTED]]
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
RE: MIT shared memory extension
This is off-topic for the xfree mailing list, it's really a developer or general topic. Anyway Should we move this to the cygwin list ? I'm not subscribed to the develop list. 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? Yes, this can be done after the stat() call. 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). But how do you ensure this in the current implementation ? st_ino contains a hash value. So this problem concerns the current implementation and the suggestion I've made. How do you suggest that you avoid hash collisions? With my suggestion I haven't adressed the problem of avoiding hash collisions. I only have addressed the newlib patch you suppose. Sorry :-( BTW: I have additional looked into the cygipc implementation. They uses only the lower word of st_ino and lowest byte of st_dev and lowest byte of id. And this seems to work, although the must have this hash collision problem even more, doesn't it ? May be this is another way to prevent the newlib patch. Regards Ralf
RE: MIT shared memory extension
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:
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.
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.
key_t
ftok(const char *path, int id)
{
struct stat statbuf;
// call stat() only as file existing check
if (stat(buf, statbuf))
{
/* stat set the appropriate errno for us */
return (key_t) -1;
}
#ifdef CASE1
char buf[MAX_PATH];
sprintf(buf,%s%08x,path,id);
return hash_path_name(0,buf);
#else /* CASE2 */
return hash_path_name(id,buf);
#endif
}
This would allow using the current 32 bit key_t implementation.
Ralf
FW: MIT shared memory extension
Ups, there were some wrong usages of path/buf in the last code example. Sorry.
key_t
ftok(const char *path, int id)
{
struct stat statbuf;
// call stat() only as file existing check
if (stat(path, statbuf))
{
/* stat set the appropriate errno for us */
return (key_t) -1;
}
#ifdef CASE1
char buf[MAX_PATH];
sprintf(buf,%s%08x,path,id);
return hash_path_name(0,buf);
#else /* CASE2 */
return hash_path_name(id,path);
#endif
}
RE: MIT shared memory extension
The definition of key_t in newlib is a 32bit int, for cygdaemon it needs
to be 64 bit to store the inode and the index cleanly. Redefining that
will break every cygipc linked application when they are rebuilt, until
cygipc is rebuilt against the new source. However rebuilding cygipc will
break every already linked app. So until the cygdaemon shm code is
complete, Chuck and I figured that it was not worth putting everyone
through the agony of a backwards incompatible ABI change.
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) ?
./include/sys/types.h:typedef long key_t;
What about interpreting key_t as pointer to shm_key_t or something else ?
Okay, this causes to support an internal list of shm_key_t elements :-(
But when I see right, you have to maintain already such a list
class shmnode {
public:
class shmid_ds * shmds;
int shm_id;
class shmnode *next;
+ shm_key_t key;
- key_t key;
HANDLE filemap;
HANDLE attachmap;
class _shmattach *attachhead;
};
The interfaces of the relates functions could be used as before, only the
interpretation is changed.
key_t ftok(const char *, int)
{
...
return node-key;
}
int shmget(key_t key, size_t, int);
...
shm_key_t *akey = (shm_key_t *)key;
...
What do you mean, could this be a workable solution ?
Ralf
RE: MIT shared memory extension
-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. Also at the moment, we know that the same file will generate the same key_t every time. (because it's inode based). If we walk a list, then we'll have to walk the entire list *and store the file name the key was generated from* to see if it's been handed out already. Lastly we don't have an existing list of key_t's, that was a list of shm areas you are referring to, and they can share the key_t values. (the shmid is the index in that list). In short, I don't like the idea of making key_t 32 bits. Rob
Re: MIT shared memory extension
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
RE: MIT shared memory extension
-Original Message- From: Charles Wilson [mailto:[EMAIL PROTECTED]] Sent: Saturday, May 04, 2002 10:20 AM the cygwin-daemon code was recently merged into CVS; the snapshots have the functionality but the daemon itself is not turned on by default. Just like ipcdaemon.exe, you have to start up the cygwin-daemon yourself. For more info, see the cygwin-developers mailing list archives. cygdaemon provides ipc and shm, but the shm is incomplete. Someone want to fund it? (only half kidding). As for it being turned on, you need to patch newlib (for the new key_t definition) and cygwin (to export the functions) and then rebuild cygwin. Rob
RE: MIT shared memory extension
It works, we have done so for the kde-cygwin port Yeah, but it requires CygIPC, doesn't it? Yes, which is not distributed with cygwin because of license problems,.. the old story ... and I know, about what you like to talk - the new cygwin daemon, isn't it ? :-) BTW, has anybody tried to run kde-cygwin using the new cygwin-daemon to provide the IPC services? No, we haven't yet. I have already thought about using the cygwin daemon, but currently there are some reason why this isnt't happened. The first reason is, I don't know how stable and performant the cygwin ipc stuff works. I have thought about checking this, but found no time to do so. Perhaps I found some time after the kde 2.2.2 b1 release day next week. The second reason is, that it does not make sense to compile kde-cygwin with the cygwin daemon and use cygipc for xfree. The consequence of this seems to me to compile xfree with cygwin daemon too, but I does not have the knowledge and time to do this job. (I don't like to say that the xfree guys has to do so, only that I can't) subset of the three main IPC mechanisms (semaphores, messages. shared memory) -- but I don't remember if shm was part of that subset... If I remember right, it has. Anyway, even if the cygwin-daemon DOES provide the necessary IPC features, you'd probably need to recompile kde-cygwin against it instead of CygIPC. Yes, this is sure. --Chuck the cygwin-daemon code was recently merged into CVS; the snapshots have the functionality but the daemon itself is not turned on by default. Just like ipcdaemon.exe, you have to start up the cygwin-daemon yourself. For more info, see the cygwin-developers mailing list archives. Thanks for this info Ralf
RE: MIT shared memory extension
-Original Message- From: Ralf Habacker [mailto:[EMAIL PROTECTED]] Sent: Saturday, May 04, 2002 8:55 PM To: Robert Collins; Charles Wilson Cc: [EMAIL PROTECTED] Subject: RE: MIT shared memory extension the cygwin-daemon code was recently merged into CVS; the snapshots have the functionality but the daemon itself is not turned on by default. Just like ipcdaemon.exe, you have to start up the cygwin-daemon yourself. For more info, see the cygwin-developers mailing list archives. cygdaemon provides ipc and shm, but the shm is incomplete. Someone want to fund it? (only half kidding). Can you explain this a little bit more ? I've got very little spare time at the moment. To devote more to Cygwin, I'd need to allocate consulting time from my employer, and my employer will want money to do that. I will eventually get it done on my own time however. As for it being turned on, you need to patch newlib (for the new key_t definition) Could this perhaps not be patched in the cvs or are there compatibility issues against it ? The definition of key_t in newlib is a 32bit int, for cygdaemon it needs to be 64 bit to store the inode and the index cleanly. Redefining that will break every cygipc linked application when they are rebuilt, until cygipc is rebuilt against the new source. However rebuilding cygipc will break every already linked app. So until the cygdaemon shm code is complete, Chuck and I figured that it was not worth putting everyone through the agony of a backwards incompatible ABI change. and cygwin (to export the functions) all shm* symbols ? Index: cygwin.din === RCS file: /cvs/src/src/winsup/cygwin/cygwin.din,v retrieving revision 1.44 diff -u -p -r1.44 cygwin.din --- cygwin.din 2002/02/25 17:47:46 1.44 +++ cygwin.din 2002/03/03 21:52:10 @@ -1246,3 +1246,8 @@ acltotext _acltotext = acltotext aclfromtext _aclfromtext = aclfromtext +ftok +shmat +shmctl +shmdt +shmget Rob
Re: MIT shared memory extension
/ arun [EMAIL PROTECTED] wrote: | hello, | | Does cygwin/xfree86 support MIT shared memory extension. I am trying to port | some code that uses these functions on linux. and I get a linker error. No it doesn't. It is possible though to compile xfree86 for cygwin with that enabled, but it haven't been tested, check the mailinglist. /Andy -- The eye of the beholder rests on the beauty!
RE: MIT shared memory extension
It is possible though to compile xfree86 for cygwin with that enabled, but it haven't been tested, check the mailinglist. It works, we have done so for the kde-cygwin port Regards Ralf
Re: MIT shared memory extension
Ralf Habacker wrote: It is possible though to compile xfree86 for cygwin with that enabled, but it haven't been tested, check the mailinglist. It works, we have done so for the kde-cygwin port Yeah, but it requires CygIPC, doesn't it? BTW, has anybody tried to run kde-cygwin using the new cygwin-daemon to provide the IPC services? Currently, the cygwin daemon implements some subset of the three main IPC mechanisms (semaphores, messages. shared memory) -- but I don't remember if shm was part of that subset... Anyway, even if the cygwin-daemon DOES provide the necessary IPC features, you'd probably need to recompile kde-cygwin against it instead of CygIPC. --Chuck the cygwin-daemon code was recently merged into CVS; the snapshots have the functionality but the daemon itself is not turned on by default. Just like ipcdaemon.exe, you have to start up the cygwin-daemon yourself. For more info, see the cygwin-developers mailing list archives.
MIT shared memory extension
hello, Does cygwin/xfree86 support MIT shared memory extension. I am trying to port some code that uses these functions on linux. and I get a linker error. thanx
