From: Matthew Wilcox <willy@debian.org>
To: linux-kernel@vger.kernel.org
Cc: Matthew Wilcox <willy@debian.org>
Subject: What's the point of __KERNEL_SYSCALLS__?
Date: Fri, 19 Sep 2003 17:40:44 +0100 [thread overview]
Message-ID: <20030919164044.GF21596@parcelfarce.linux.theplanet.co.uk> (raw)
As far as I can tell, __KERNEL_SYSCALLS__ (see asm-*/unistd.h) are
merely an indirection for calling sys_foo -- they don't seem to play
around with DS or FS or whatever x86 register name got turned into an
arch-independent way of saying what userspace is.
Given that, why should they exist? It only encourages monstrosities
like sp8870_read_code() in drivers/media/dvb/frontends/alps_tdlb7.c that
probably don't work anyway.
The following are unused:
setsid
write
read is used by DVB and the wavefront sound driver
lseek is only used by DVB
dup is used only by init/main.c and could easily call sys_dup() instead.
execve is used by kmod, init/main.c, sbus/char/{bbc_,}envctrl.c and
arch/sparc64/kernel/power.c
open is used by DVB, init/main.c and wavefront.
close is used by wavefront. (DVB calls sys_close directly).
_exit is used by arch/ia64/kernel/process.c
waitpid is used by kernel/workqueue.c and net/ipv4/ipvs/ip_vs_sync.c
This doesn't seem like a big list to clean up. Any objections to
getting rid of them and making the calls directly? If nothing else,
at least it would make it explicit when we possibly needed to be calling
set_fs(KERNEL_DS) instead.
--
"It's not Hollywood. War is real, war is primarily not about defeat or
victory, it is about death. I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk
next reply other threads:[~2003-09-19 16:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-19 16:40 Matthew Wilcox [this message]
2003-09-21 4:54 ` Matthew Wilcox
2003-09-21 5:23 ` viro
2003-09-21 8:11 ` Alan Cox
2003-09-22 17:23 ` Johannes Stezenbach
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=20030919164044.GF21596@parcelfarce.linux.theplanet.co.uk \
--to=willy@debian.org \
--cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®