3 ms·

> First, it's not always easy to map every object operation into either an open read or write. It doesn't seem like it. Linux has a habit of multiplexing alte

> First, it's not always easy to map every object operation into either an open read or write. It doesn't seem like it. Linux has a habit of multiplexing alternate functions through a single handle with additional and somewhat scary methods like ioctl. Plan9 manages this with servers, directories, and more than one path available for a single resource depending on what you're trying to access. This is far more sane. > With time, we should have seen a lot of ugly interfaces resulting from this limitation. They don't seem any more complicated than they need to be. Compare implementing a fuse server vs implementing a plan9 server. Yet I don't see where all of this complication adds anything or enables implementation of technologies that couldn't be implemented on plan9 with a few additional paths. > People could no more keep up with simple general designs. And to squeeze every bit of performance, These are contrary goals, and I'm not sure what you mean people can't "keep up" with "general designs." What is there to "keep up" with? And in exchange for that performance we got one of the most insane /class/ of unfixable CPU bugs ever imagined. > And this is how we ended with the extreme fragmentation and heterogeneity we have in Linux, And yet.. many of these systems are now being unified into generalized file descriptor based systems, that have wacky open methods, but boil down to allowing simpler interfaces through read(2) and write(2).

jabl 3y ago
For an example, most high performance devices expose functionality as memory locations mapped into the CPU address space. In many cases it's necessary to allow userspace direct access to (part of) the memory the device exposes, such as with GPU's, RDMA NIC's and so forth. Not sure you could get high performance with a read/write stream based interface, as conceptually elegant such an interface is.
- creshal 3y ago
  Devices have been doing that since forever, so Plan9 has an mmap equivalent with segment/segattach, where you use file I/O (only) to define a memory mapping and attach it to the current process. Everything from that point on is regular memory I/O.
SubjectToChange 3y ago
And in exchange for that performance we got one of the most insane /class/ of unfixable CPU bugs ever imagined. What do Spectre and Meltdown have to do with “everything as a file” system architecture?
- akira2501 3y ago
  The implication was that everything as a file _had_ to be abandoned to make way for performance "improvements." Which ended up just being a new class of CPU bugs. So.. was the trade worth it?
josefx 3y ago
> alternate functions through a single handle with additional and somewhat scary methods like ioctl. Plan9 manages this with servers, directories, and more than one path available for a single resource depending on what you're trying to access. This is far more sane. Given how horribly asynchronous filesystems are I take one handle owned by the current process over a dozen free hanging files that might be reused for different resources at any time. Hell I am quite sure Linux had to kill suid on scripts because the kernel could not guarantee that the script file wasn't swapped out before the interpreter would load the path.

jabl 3y ago

For an example, most high performance devices expose functionality as memory locations mapped into the CPU address space. In many cases it's necessary to allow userspace direct access to (part of) the memory the device exposes, such as with GPU's, RDMA NIC's and so forth. Not sure you could get high performance with a read/write stream based interface, as conceptually elegant such an interface is.

creshal 3y ago
Devices have been doing that since forever, so Plan9 has an mmap equivalent with segment/segattach, where you use file I/O (only) to define a memory mapping and attach it to the current process. Everything from that point on is regular memory I/O.

SubjectToChange 3y ago

And in exchange for that performance we got one of the most insane /class/ of unfixable CPU bugs ever imagined. What do Spectre and Meltdown have to do with “everything as a file” system architecture?

akira2501 3y ago
The implication was that everything as a file _had_ to be abandoned to make way for performance "improvements." Which ended up just being a new class of CPU bugs. So.. was the trade worth it?

josefx 3y ago

> alternate functions through a single handle with additional and somewhat scary methods like ioctl. Plan9 manages this with servers, directories, and more than one path available for a single resource depending on what you're trying to access. This is far more sane. Given how horribly asynchronous filesystems are I take one handle owned by the current process over a dozen free hanging files that might be reused for different resources at any time. Hell I am quite sure Linux had to kill suid on scripts because the kernel could not guarantee that the script file wasn't swapped out before the interpreter would load the path.