Re: intercepting system calls?
Re: intercepting system calls?
- Subject: Re: intercepting system calls?
- From: Erik Paulson <email@hidden>
- Date: Mon, 23 Jan 2006 11:10:25 -0600
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.
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
> >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. 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" :)
At any rate, our experience is that it's easier to interpose at the
system call interface instead of the library interface to get the sort
of virtualization we want. It sounds like the interface we want is not
available in Darwin, and there's not really something equivalent. Thanks
to everyone who answered!
-Erik
_______________________________________________
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