> calling sys_function() functions directly doesn't look right:
>
> 1. what if one was to do some accounting of the system calls. Not going
> through the int 0x80 would break this.
>
> 2. what if one were to temporarily redirect some system calls to another
> handler (like timetravel.o module does).
>
> 3. probably other "what-ifs".
>
> So, it is better to ensure that either one can go through that gate as
> many times as one wants or forbid it completely.
We do not account syscalls, neither do we redirect system calls. If anyone
is doing anything like that then all problems triggered by such a change
should be solved. Current kernels do not have this problem, and calling
system calls from within system calls is a _feature_.
some users of this feature: exec() is using fop->read(). sys_ustat() is
internally using ->statfs(). autofs is using ->write(). kNFSd is using
->read(), ->write(), ->readlink(), ->statfs(). NBD, loopback, etc.
this is a regular kernel feature, it gives us flexibility to reuse already
existing functionality internally.
there are even 'deeper' calls than calls to sys_*(), eg. khttpd is using
the socket layer quite directly, to do ->recvmsg(), ->sendmsg(), ->read()
without any demultiplexing overhead and it's using internal socket-layer
data structures directly. [it uses other system calls as well, but only
those need set_fs()/get_fs() which are interacting with user-space VM]
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/