[ori_b]

Yes, that's the meaning of no special cases*: it means you don't add special cases. But this is why plan 9 has 40-odd syscalls instead of 500, and tools can be interposed, redirected, and distributed between machines. I don't have to use the mouse device from the server I logged into remotely, I can grab it from the machine I'm sitting in front of and inject it into the program. VNC gets replaced with mount.

I don't have to use the network stack from my machine, I can grab it from the network gateway. NAT gets replaced with mount.

I don't have to use the debug APIs from my machine, I can grab them from the machine where the process is crashing. GDB remote stubs get replaced with mount.

You see the theme here. Resources don't have to be in front of you, and special case protocols get replaced with mount; 9p lets you interpose and redirect. Without needing your programs to know about the replacement, because there's a uniform interface.

You could theoretically do syscall forwarding for many parts of unix, but the interface is so fat that it's actually simpler to do it on a case by case basis. This sucks.

* In kernel devices can add some hacks and special magic, so long as they still mostly look as if they're speaking 9p. This is frowned upon, since it makes the system more complex -- but it's useful in some cases, like the '#s' device for fd passing. This is one of the abstraction breaks that I mentioned earlier.

[cycloptic]

That's what I mean though, I see the theme, but it seems to me to be about the same as trying to fit everything into an HTTP REST API, it all falls apart when something comes along that breaks the abstraction. For example if you have something that wants to pass a structure of pointers into the kernel, you can't reasonably do that with 9p, so now you've got a special case. The debug APIs can still only return a direct memory mapped pointer to the process memory as a special case, the normal case is doing copies of memory regions over the socket, no matter how large they are. If you want to add compression to your VNC thing, or add some more complex routing to your network setup, you have to start adding special daemons and proxies and translation layers into another socket, which is not really different from what you would be doing on a more traditional Unix. Or is there another way plan9 handles these?

[ori_b]

These things have already been done with 9p.

> The debug APIs can still only return a direct memory mapped pointer to the process memory as a special case

Can you point to the special case here?

http://man.cat-v.org/plan_9/3/proc

Because it replaces ptrace, and seems to work perfectly fine when I mount it over 9p. It's used by acid, which needs no additional utilities: http://man.cat-v.org/plan_9/1/acid

> If you want to add compression to your VNC thing

Images may be sent compressed. More -- or at least better -- formats would be good, but this is done.

http://man.cat-v.org/plan_9/3/draw

For a full implementation of remote login using these interfaces, here's the code:

http://shithub.us/ori/plan9front/fd1db35c4d429096b9aff1763f2...

It's a bit complex because it needs to do more than just forward mouse, keyboard and drawing -- signals need to be interposed and forwarded, and there are a few other subtle things that need to happen in the namespace. And because it contains both the client and server code. Even so, it's still small compared to VNC.

And yes, shithub is hosted on plan 9.

> or add some more complex routing to your network setup, you have to start adding special daemons and proxies and translation layers into another socket

Here are the network APIs.

http://man.cat-v.org/plan_9/3/ip

What kind of complex routing are you talking about, and why would it be impossible to implement using those interfaces?