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
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
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@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Apr 30 2001 - 21:00:12 EST