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/linux-kernel@vger.kernel.org/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/

Reply via email to