Comment by kragen | Hacker News Reader

Comment by kragen | Hacker News Reader

Parent Full thread

It's more like #2, but without ioctl() and similar brain-damaged abortions. If you open /dev/mouse, for example, you get a stream of events (encoded as blobs of bytes), which you can get by read(), not a byte-addressable blob of bytes.

But lots of things in Plan9 present an interface that isn't just a single file. The 8½ window system, for example, presents not only /dev/mouse but also /dev/cons (character-oriented I/O), /dev/bitblt (to which you write requests for 2-D accelerated drawing operations), /dev/rcons (keystroke-oriented character I/O), and /dev/screen (the contents of the window—which is just a byte-addressable blob of bytes). http://doc.cat-v.org/plan_9/4th_edition/papers/812/ explains in more detail.

And, of course, file storage servers similarly provide an arbitrary tree of files, and when you remotely log into a CPU server, you mount your local filesystem on the CPU server so that processes running on the CPU server can access your local files transparently—including /dev/screen, /dev/mouse, and /dev/bitblt, if you so choose.

That's actually really cool.. This democratization of useful information probably opens the door for lots of interesting interactions between distributed systems.

Even on my local Linux system I wouldn't know how to get hold of the mouse data without using an X Windows API (or SDL on a console only app before X is run).

There are devices under /dev/input which are quite easy to decode for raw mouse data.

I agree! I think that kind of transparency and openness to hacking is very important.

You may be interested in https://gitlab.com/kragen/bubbleos/blob/master/spikes/intell..., which reads from /dev/input/mice, although I haven't yet implemented support in https://gitlab.com/kragen/bubbleos/blob/master/yeso/yeso-fb.....

And what's the advantage vs an API via function calls? It's the same thing no? Calling 0x42 with a given ABI vs interpreting bytes as an ABI seems oddly similar.

I'm not overly familiar with Plan 9, but a significant advantage of the filesystem as an API is that it composes well. You can put any service inbetween that consumes the existing file and provides a new file with the same API contract, but different behavior (e.g. a /dev/screen that's cropped to a certain area, or that inverts colors on everything drawn into it). Then you can make a new mount namespace where the new file is put in the place of the old file, so that the actual process consuming it has no idea that someone is sitting in the middle. With a traditional shared object, you'd have to engage in LD_PRELOAD shenanigans to achieve the same, or if the library is statically linked and does not have any hooks, you're straight out of luck.

In other words, it gives you a system wide way to override any APIs. As long as you are compatible with the ABI of course.

At the cost of probably making all APIs a bit less efficient. Now I wonder if any Plan 9 derivative offers a 3D rendering API?

No, and even for 2D it lacks acceleration.

Not true:

http://www.cs.cmu.edu/~412/lectures/2009-10-23_radeon.pdf

>>Provide 2D acceleration via the 3D engine.

I stand corrected, however 2009 is already past the time I was paying attention to Plan 9.

As explained in the abstract of the paper I linked above, 8½, the Plan 9 window system, has supported 2-D acceleration since at least 01992. I also mentioned this in my comment, which additionally outlines how this acceleration support works across networks.

Functionally it's the same. The functions called could live in the kernel (a system call), in the process itself or in a shared lib loaded into the process address space.

Interpreting bytes is message passing and this communication happens through the handle/descriptor to the file/object/whatever. As above, this handle could have come from the kernel, another process or the executing process itself (the process opened some file or whatever).

I think the message passing version happening through a handle can be more versatile as you could send this handle over to another process. Could copy it and distribute it to other processes in a easier way than injecting/changing a (presumably C ABI) into a process address space.

Well, as I said, one advantage is that processes running on the CPU server can access your local files transparently—including /dev/screen, /dev/mouse, and /dev/bitblt, if you so choose.

That means you can run graphical applications on the CPU server.

An advantage is, you don't need any API or function calls. You can inspect or manipulate anything from the shell ad lib using cat, echo, and the usual commands. Plan 9 doesn't have ioctl() calls because it's not meaningful to send pointers across the network. Instead each device and service provides a file called cntrl (or something similar) to which you can read or write text - using cat, echo etc. So it's easy to write small test scripts or even whole applications, in the shell or any language you like.

[From memory, so take with a grain of salt]

a) tooling and familiarity

b) it's leveraged for modularity, composition and access control. Normal unix basically has no modularity and little composition beyond piping to stdin (which is of limited applicability). And of course no useful access control mechanism to speak of. The last 5 decades mostly just added layers of shitty hacks that don't work and that no one understands anymore (by contrast e.g. the original unix ownership and permissions model was misdesigned but at least possible to grasp).

Plan9 does substantially better in both regards via clever use of a proper union file system (which incidentally makes another horrible hack superfluous: symlinks). If you want your shell, or some other executable, to find some executable, you mount it into its /bin -- there is no $PATH. If you want some process or user to have access to a resource (file, device, server in the network, ...) you mount it into their filesystem. This gets rid of a lot of problems and special purpose solutions.

Isn't the same possible now with mount spaces in Linux?

You mean union mounts? Typically doing a union mount is a privileged operation, while setting $PATH is not, so you cannot really replace the latter with the former. A bigger issue is that, even if mounting various things on /bin were unprivileged, removing $PATH from Linux would break an enormous amount of existing software. Similarly with file permissions. So union mounts don't permit you to simplify Linux in that way, even though they did permit you to simplify Plan9. (Incidentally, Plan9 did have the traditional user/group mode bits.)

Reply on news.ycombinator.com