All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: linux-arch@vger.kernel.org
Cc: drepper@redhat.com
Subject: Unexpected syscalls on 64-bit arches
Date: Fri, 16 Apr 2004 17:08:03 -0400	[thread overview]
Message-ID: <20040416210802.GU31589@devserv.devel.redhat.com> (raw)

Hi!

While updating our glibc-kernheaders asm*/unistd.h tables, I have noticed
a bunch of syscalls which IMHO should have never been added:

asm-ia64/unistd.h:
#define __NR_fstatfs64                  1257
#define __NR_statfs64                   1258
asm-ppc64/unistd.h:
#define __NR_statfs64           252
#define __NR_fstatfs64          253
#define __NR_fadvise64_64       254
asm-s390/unistd.h:
#define __NR_statfs64           265
#define __NR_fstatfs64          266
but doesn't have
#undef __NR_statfs64
and
#undef __NR_fstatfs64
in the __s390x__ section
asm-sparc64/unistd.h:
#define __NR_statfs64           234 /* Linux Specific                              */
#define __NR_fstatfs64          235 /* Linux Specific                              */
#define __NR_fadvise64_64       210 /* Linux Specific                              */

On all these arches, struct statfs and struct statfs64 are identical,
thus __NR_statfs64 is a dup of __NR_statfs and __NR_fstatfs64 is a dup of
__NR_fstatfs.
Similarly, __NR_fadvise64_64 is a dup of __NR_fadvise64_64.

At least from glibc's point of view, these syscalls will never be used
on 64-bit arches, so IMHO they should be at least killed from the
unistd.h headers to avoid confusion and maybe nuked from the syscall tables
as well.

	Jakub

             reply	other threads:[~2004-04-16 21:08 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-16 21:08 Jakub Jelinek [this message]
2004-04-16 21:38 ` Unexpected syscalls on 64-bit arches David Mosberger
2004-04-16 21:43 ` David S. Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040416210802.GU31589@devserv.devel.redhat.com \
    --to=jakub@redhat.com \
    --cc=drepper@redhat.com \
    --cc=linux-arch@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.