lkml.org 
[lkml]   [2004]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC] dynamic syscalls revisited
From
Date
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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.111 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site