Re: intercepting system calls?
Re: intercepting system calls?
- Subject: Re: intercepting system calls?
- From: Mike Smith <email@hidden>
- Date: Mon, 23 Jan 2006 13:30:31 -0800
On Jan 23, 2006, at 12:02 PM, email@hidden wrote:
On Mon, Jan 23, 2006 at 01:00:26AM -0800, Mike Smith wrote:
On Jan 22, 2006, at 12:02 PM, email@hidden
wrote:
I want to be able to capture the I/O calls of an application and
then
ship them back over the network to be handled by another machine.
There are plenty of examples of this in the system already;
they're called
"network filesystems". One of them is even called "the Network
File System".
A shared filesystem is great, if the administrators of both computers
agree to use the same shared filesystems. That usually doesn't happen
between institutions, for example.
This sounds like an administrative misconception revolving around
traditional
use of network filesystems.
You're already talking about running privileged code on the client
system
in order to intercept system calls; a network filesystem implementation
on the client is no different in degree.
There is no need for the server side of the equation to require
administrative
intervention; if you are currently intercepting client-side file I/O
and handling
it on the server, you already have a network fileservice protocol.
I'd point you to our papers for more motivating examples, but
there are times when if we want to access data remotely we can't count
on a shared filesystem, and have to use some sort of interposition:
http://www.cs.wisc.edu/condor/publications.html
(or a few other conferences that have papers in the same space:
IEEE High Performance Distributed Computing: http://www.hpdc.org/
USENIX WORLDS: http://www.usenix.org/events/bytopic/worlds.html
The only argument I can see for requiring interposition over simply
having
a portion of the filesystem namespace dedicated to remote access is when
you want to subvert the local namespace. From an architectural
perspective
that's pretty undesirable.
It also seems like Apple could keep the system call interface stable
between versions - the great thing about system calls is if you
need to
change the meaning of one, you can just create another system call
with a different name. You can leave the old one stable, and just
change
the framework to call the new one - if someone has found a way to
call the
actual system call, the can keep using it.
This is a naive assumption. It is much easier to version at the
shared
library interface; locking down the system call layer introduces a
lot of problems, especially if you guarantee the interface as ABI.
If you've got time, could you expand on this? Keep in mind I'm
assuming
that the main interface layer is the shared library, so most
applications
use whatever system calls the library uses, either a new version of
the
old system call, or a new system call. My claim is that Apple can
leave
the old system call in place and "version" by just introducing a
new system call.
The *only* interface permitted to the kernel is through the system
frameworks.
If the system call interface were exposed as ABI, it would be
impossible to
refactor the kernel/framework relationship without incurring
substantial overhead
in the form of "legacy support" code. This isn't one-time overhead
either; as the
internals of the kernel evolve, it has to be kept up.
Applications that (at their own peril) bypass the shared
library will keep working, and any application that uses the shared
library
gets the new interface. (I'll admit my evidence is "this approach
works for
Linux" :)
Having watched Linux for over a decade now, I would contest your
definition
of "works". Far too much effort has been wasted, and far too many users
have suffered over the relative instability and lack of coherent
behaviour
in that area. 8(
= Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden