DSL describing Plan9-like devices

[arseniuss]

Hello, everyone!

I was reading in Wikipedia critique about Plan9: "Plan 9 constrains everything to look like a file. In most cases the real interface type comprises the protocol of messages that must be written to, and read from, a file descriptor. This is difficult to specify and document, and prohibits any automatic type checking at all, except for file errors at run time. (...)"

And I was wondering if you have seen any descriptive protocol language (something like protobuf) which could describe a device in Plan9 and generate C boilerplate to counter critique mentioned above?

If not how would you declare Plan9 device like vga: https://plan9.io/magic/man2html/3/vga

[eekee]

I was attracted to Plan 9 by its simple interfaces with (mostly) clear documentation, so I'm not too sure about that critique. "The protocol of messages" is exactly what I want to know; formal grammars and what-not do more to confuse me than help. However, I can see how it prevents automated safety checks. Type checking certainly is left to run-time errors. I found this acceptable, but I was only shell scripting.

[spenc]

I agree, it's especially nice for things like implementing automated pickers. Sandstorm (https://sandstorm.org/) which to be fair bills itself as a platform and not an OS, uses Capt'n Proto (https://capnproto.org/) for all it's IPC, and it's extremely nice in that anything you have that implements the eg. email interface can be swapped in anywhere its used in a very object oriented style way, and the UI can immediately tell what can be shown and what won't work.

I don't know if Cap'n Proto is up to the task as the core of an OS, though they use it extensively in Cloudflare Workers. Either way, agree that having some sort of interface description is very handy.

Another way this is done is how Genode does it: https://genode.org/documentation/genode ... onnections
where instead of things being files, they are client server sessions. The interface has to declare a name using static const char *service_name(); which can then be asked for by anyone who knows about it.

Or, another example which I embarrassingly don't know very well is the COM model for windows.

There's tons of others too, here's a list:
https://en.wikipedia.org/wiki/Interface ... n_language

[AndrewAPrice]

I created an IDL called Permebufs in my OS for basically all RPC.

Here's my Permebuf definition of a Graphics Driver: https://github.com/AndrewAPrice/Percept ... r.permebuf

My Window Manager: https://github.com/AndrewAPrice/Percept ... r.permebuf

The services are named and get registered with the OS. "minimessages" are messages so small that they can be passed around in registers. I generate C++ glue. Here's an example of a sending my window manager a message:
https://github.com/AndrewAPrice/Percept ... #L145-L151

And here's an example of my server of implementing a server (just inherit <service class>::Server and implement the handlers):
https://github.com/AndrewAPrice/Percept ... _manager.h

[eekee]

For all that I like informal descriptions, I actually need something more formal because I want this:

it's extremely nice in that anything you have that implements the eg. email interface can be swapped in anywhere its used in a very object oriented style way, and the UI can immediately tell what can be shown and what won't work.

I made myself a note the other week on Go's structural typing: "If an interface looks like another interface, it's the same type." Capt'n Proto goes further, of course. I think I'll take another look at it. I had a quick look at AndrewAPrice's permebuf description language. It's easy to read, but what does it do that isn't replicating structure and type definitions?

[spenc]

just came across this article describing an alternative to compiled IDLs, thought it might be relevant here
https://os.inf.tu-dresden.de/papers_ps/ ... dynrpc.pdf
don't quite understand it yet but it seems to be using C++ marshaling as the main interface.