Review request for glibc system call wrapper for statx

I've proposed a statx system call wrapper for glibc:

   https://sourceware.org/ml/libc-alpha/2018-06/msg01038.html

The somewhat questionable part is the userspace emulation if the kernel 
does not support statx.  It looks like this:

+/* Approximate emulation of statx.  This will always fill in
+   POSIX-mandated attributes even if the underlying file system does
+   not actually support it (for example, GID and UID on file systems
+   without UNIX-style permissions).  */
+static __attribute__ ((unused)) int
+statx_generic (int fd, const char *path, int flags,
+               unsigned int mask, struct statx *buf)
+{
+  /* Flags which need to be cleared before passing them to
+     fstatat64.  */
+  static const int clear_flags = AT_STATX_SYNC_AS_STAT;
+
+    /* Flags supported by our emulation.  */
+  static const int supported_flags
+    = AT_EMPTY_PATH | AT_NO_AUTOMOUNT | AT_SYMLINK_NOFOLLOW
+      | clear_flags;
+
+  if (__glibc_unlikely ((flags & ~supported_flags) != 0))
+    {
+      __set_errno (EINVAL);
+      return -1;
+    }
+
+  struct stat64 st;
+  int ret = __fstatat64 (fd, path, &st, flags & ~clear_flags);
+  if (ret != 0)
+    return ret;
+
+  *buf = (struct statx)
+    {
+      /* We copy everything from fstat64, which corresponds the basic
+         fstat64.  */
+      .stx_mask = STATX_BASIC_STATS,
+      .stx_blksize = st.st_blksize,
+      .stx_nlink = st.st_nlink,
+      .stx_uid = st.st_uid,
+      .stx_gid = st.st_gid,
+      .stx_mode = st.st_mode,
+      .stx_ino = st.st_ino,
+      .stx_size = st.st_size,
+      .stx_blocks = st.st_blocks,
+      .stx_atime = statx_convert_timestamp (st.st_atim),
+      .stx_ctime = statx_convert_timestamp (st.st_ctim),
+      .stx_mtime = statx_convert_timestamp (st.st_mtim),
+      .stx_rdev_major = __gnu_dev_major (st.st_rdev),
+      .stx_rdev_minor = __gnu_dev_minor (st.st_rdev),
+      .stx_dev_major = __gnu_dev_minor (st.st_dev),
+      .stx_dev_minor = __gnu_dev_minor (st.st_dev),
+    };
+
+  return 0;
+}

Do you think this emulation is a good idea?  Or should we drop it and 
just return ENOSYS?

Thanks,
Florian