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
DSL describing Plan9-like devices
DSL describing Plan9-like devices
Hobby stuff (suckless libs, compilators, game engines, kernels): github. Work @ zabbix: arseniuss@zabbix
Re: DSL describing Plan9-like devices
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.
Kaph — a modular OS intended to be easy and fun to administer and code for.
"May wisdom, fun, and the greater good shine forth in all your work." — Leo Brodie
"May wisdom, fun, and the greater good shine forth in all your work." — Leo Brodie
Re: DSL describing Plan9-like devices
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
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
- Member
- Posts: 2297
- Joined: Mon Jun 05, 2006 11:00 pm
- Location: USA (and Australia)
Re: DSL describing Plan9-like devices
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
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
My OS is Perception.
Re: DSL describing Plan9-like devices
For all that I like informal descriptions, I actually need something more formal because I want this:
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?
Kaph — a modular OS intended to be easy and fun to administer and code for.
"May wisdom, fun, and the greater good shine forth in all your work." — Leo Brodie
"May wisdom, fun, and the greater good shine forth in all your work." — Leo Brodie
Re: DSL describing Plan9-like devices
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.
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.