Comment by arghwhat

1 month ago

Indeed, you can disregard plan9 common practice and adopt the ioctl pattern, but then you just created ioctl under a different name, having gained nothing over it.

You will still have the significant context switching overhead, and you will still need distinct write-then-read phases for any return value. Manual buffer sharing is also notably more cumbersome than having a kernel just look directly at the value, and the neat part of being able to operate these fileservers by hand from a shell is lost.

So while I don't disagree with you on a technical level, taking that approach seems like it misses the point of the plan9 paradigm entirely and converts it to a worse form of the ioctl-based approach that it is seen as a cleaner alternative to.

Being able to do everything in user space looks like it might be a worthwhile gain in some scenarios. You're right that there can be some context switching overhead to deal with, though even that might possibly be mitigated; the rendezvous(2) mechanism (which works in combination with segattach(2) in plan9) is relevant, depending on how exactly it's implemented under the hood.

  • I must admit that the ability to randomly bind on top of your "drivers" to arbitrarily overwrite functionality, whether to VPN somewhere by binding a target machine's network files, or how rio's windows were merely /dev/draw proxies and you could forward windows by just binding your own /dev/draw on the target, holds a special place in my heart. 9front, if nothing else, is fun to play with. I just don't necessarily consider it the most optimal or most performant design.

    (I also have an entirely irrational love for the idea the singular /bin folder with no concept of $PATH, simply having everything you need bound on top... I hate $PATH and the gross profile scripts that go with it with a passion.)

    • > I also have an entirely irrational love for the idea the singular /bin folder with no concept of $PATH, simply having everything you need bound on top

      That's really an easy special case of what's called containerization or namespacing on Linux-like systems. It's just how the system works natively in plan9.