I have been chasing all around trying to find out why
shm_open always returns ENOSYS. It is implemented
in glibc-2.2.2, and seems the 2.4.3 kernel knows about
shmfs.
It seems the file linux/mm/shmem.c has:
#define SHMEM_MAGIC 0x01021994
And the glibc-2.2.2/sysdeps/unix/sysv/linux/linux_fsinfo.h has:
#define SHMFS_SUPER_MAGIC 0x02011994
Well, which is correct?
Looking for (trouble?) the reason, I found a patch
http://www.mail-archive.com/[email protected]/msg16996.html
where there seems to be a typo, the remove line is correct:
-#define SHM_FS_MAGIC 0x02011994
but the insert line has the 0201 reversed:
+#define SHMEM_MAGIC 0x01021994
Has anyone else run into this? (It seems the documentation on shmfs
is sparse, so I don't think too many folks are even messing with it).
Initially I thought, hey simple, just fix the kernel source, and
everyone will be happy. But, then I thought, ooof! code I build
for someone without a patched kernel will surely break. So then
I thought simple I'll fix glibc and statically link. Of course, then
someone will fix this, and all my binaries will be broken.
Help! what is the "right" fix.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
shm_open doesn't work (fix maybe).
Tom Brusehaver (N-Sysdyne Corporation) Tue, 24 Apr 2001 09:34:38 -0700
- Re: shm_open doesn't work (fix mayb... Tom Brusehaver (N-Sysdyne Corporation)
- Re: shm_open doesn't work (fix... Jakub Jelinek
- Re: shm_open doesn't work ... Christoph Rohland

