From: Steven Rostedt <rostedt@goodmis.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] dynamic syscalls revisited
Date: Mon, 06 Dec 2004 17:01:57 -0500 [thread overview]
Message-ID: <1102370517.25841.216.camel@localhost.localdomain> (raw)
In-Reply-To: <cp2i3h$hs0$1@terminus.zytor.com>
On Mon, 2004-12-06 at 21:14 +0000, H. Peter Anvin wrote:
> Because we already have a name resolution mechanism in the kernel,
> called the filesystem? We also have a mechanism for ad hoc system
> calls, it's called ioctl().
>
> And before you go "but ioctl() sucks": dynamic syscalls suck for
> *exactly* the same reasons.
>
I disagree about this statement. ioctl's suck because they usually have
none, or very poor documentation and you are stuck with opening devices,
and sending parameters to them that may be for the wrong device and
there is really no good checking to see what you sent is what you want
since its all defined by human unreadable numbers.
As for dynamic system calls (and especially the way I've implemented
them) you have human readable names, with varying amount of parameters
that can make sense. So even if you still have none to very poor
documentation, you can understand things perhaps a little better. There
is also much better checking in dynamic system calls than to ioctls.
So instead of
struct mydev_struct myparams;
fd = open("/dev/mydev",O_RDWR);
myparams.arg1 = arg1;
myparams.arg2 = arg2;
... etc ...
ioctl(fd,IO_HOPE_THIS_IS_RIGHT_IOCTL_NUMBER,&myparams);
you now have
mydev_syscall(arg1,arg2,arg3,...);
But you do give me a idea on how to implement dynamic system calls with
the ioctl approach, and this can be added for anyone that wants dynamic
system calls. But I like my original patch better, since the ioctl way
would really be a nasty hack.
-- Steve
next prev parent reply other threads:[~2004-12-06 22:02 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-29 15:11 [PATCH][RFC] dynamic syscalls revisited Steven Rostedt
2004-11-29 15:17 ` Christoph Hellwig
2004-11-29 15:36 ` Steven Rostedt
2004-11-30 19:30 ` Kristian Sørensen
2004-11-29 16:41 ` [RFC] " Jan Engelhardt
2004-11-29 17:10 ` Steven Rostedt
2004-12-05 23:46 ` Adrian Bunk
2004-12-06 16:07 ` Steven Rostedt
2004-12-06 17:16 ` Steven Rostedt
2004-12-06 17:32 ` Zwane Mwaikambo
2004-12-06 17:57 ` linux-os
2004-12-06 18:03 ` Steven Rostedt
2004-12-06 18:18 ` Arjan van de Ven
2004-12-07 0:20 ` Michael Buesch
2004-12-07 0:57 ` Steven Rostedt
2004-12-06 21:14 ` H. Peter Anvin
2004-12-06 22:01 ` Steven Rostedt [this message]
2004-12-06 22:20 ` H. Peter Anvin
2004-12-06 22:38 ` Steven Rostedt
2004-12-14 23:14 ` Werner Almesberger
2004-12-15 2:14 ` Steven Rostedt
2004-12-15 3:35 ` Steven Rostedt
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=1102370517.25841.216.camel@localhost.localdomain \
--to=rostedt@goodmis.org \
--cc=hpa@zytor.com \
--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