site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Jan 23, 2006, at 12:02 PM, darwin-dev-request@lists.apple.com wrote: 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 = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On Mon, Jan 23, 2006 at 01:00:26AM -0800, Mike Smith wrote: On Jan 22, 2006, at 12:02 PM, darwin-dev-request@lists.apple.com 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". 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. 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( This email sent to site_archiver@lists.apple.com