SHMFS_SUPER_MAGIC discrepancy, Linux 2.4.2, glibc 2.2.2

[Jean-Francois Panisset]

I've been running into problems trying to get shm_open() to return
something else than ENOSYS running glibc 2.2.2 and Linux 2.4.2.
In sysdeps/unix/sysv/linux/shm_open.c, I find:

/* Determine where the shmfs is mounted (if at all).  */
static void
where_is_shmfs (void)
{
  char buf[512];
  struct statfs f;
  struct mntent resmem;
  struct mntent *mp;
  FILE *fp;

  /* The canonical place is /dev/shm.  This is at least what the
     documentation tells everybody to do.  */
  if (__statfs (defaultdir, &f) == 0 && f.f_type == SHMFS_SUPER_MAGIC)
    {
      /* It is in the normal place.  */
      mountpoint.dir = (char *) defaultdir;
      mountpoint.dirlen = sizeof (defaultdir) - 1;

      return;
    }


and in sysdeps/unix/sysv/linux/linux_fsinfo.h, I find:

/* Constant that identifies the `shm' filesystem.  */
#define SHMFS_SUPER_MAGIC       0x02011994

Unfortunately, in the Linux 2.4.2 source tree, in mm/shmem.c, I find:

#define SHMEM_MAGIC     0x01021994

which is close, but not quite what I want. Tracing through a call
to shm_open(), it does seem that the kernel is returning 0x01021994
as the fs type for the shmfs filesystem, causing shm_open() to fail
and return ENOSYS.

So it seems that in the short term, linux_fsinfo.h should be updated.
In the long term, there should be a way to have a single place where
these magic numbers are defined so that they don't get out of sync.

Of course, I could be completely mistaken on this.

JF