P: A programming language for asynchrony, fault-tolerance and uncertainty

>what is so complicated about writing device drivers, whose sole purpose typically is to transport data from input to output, and vice versa?

What you ask if valid, and very true, but for cable construction, not driver writing.

There are tons of protocols and issues to handle when designing a device driver. Negotiate device capabilities. Handle hot plugging and unplugging. Handle intermittent state changes in the device. Handle buffering. Handle different versions of the protocol (or multiple protocols from the same bus). Handle throttling. Initialize and configure the device correctly (and infinite variations of devices from different vendors with perhaps slight or big inconsistencies in their implementation).

And of course device drivers are not just about I/O.

>what is so complicated about writing device drivers, whose sole purpose typically is to transport data from input to output, and vice versa

I don't think it's the device driver part that makes it complicated. It's implementing something that is a collection of interdependent state machines in an asynchronous fashion, and doing that in a way that performs well and is reliable and safe.

In their specific example of a USB driver, here's what's in the paper:

"It receives a large number of un-coordinated events sent from different sources such as OS, hardware and other drivers, in tricky situations when the system is suspending or powering down. It can receive unexpected events from disabled or stopped devices, noncompliant hardware and buggy drivers. The hub driver can fail requests from incorrect hardware or buggy function drivers. However,it is important that the USB hub itself handles all events and does not crash or hang itself."

But it doesn't have to be a device driver. They give the example of elevator control in the paper as another collection of state machines that interact.

>shouldn't drivers be sandboxed to prevent stability problems

That would be a microkernel, which has it's own set of problems. There are ways to implement user mode drivers for Windows, Linux, etc, but they are currently limited in functionality and performance.

The graph visualization towards the end of the video in MS VS is amazing. I can see this being really useful for my robotics projects. I'll have to figure out how to get started. I was learning Erlang, and looked briefly at Pony, but the syntax and the demo appeals to me.

In my day job, I work in a company that is into generation of device drivers from a high level specification - so I can talk forever on this topic! But other comments here are already spot on - and I don't have much to add.

But the question assumes(?) that the P language is meant for writing device drivers - and IMHO that assumption is not entirely true, for the language doesn't have any constructs for capturing the software's (the "physical device driver's" [1]) interaction with hardware.

For instance, I don't see a way to capture : 1. Software programmable registers (MMIO or over PCIe, I2C etc) 2. The software's contribution in DMA by setting up descriptors and buffers correctly and efficiently 3. Interrupts that the hardware can raise and how software should service them 4. Sequences to negotiate device capabilities and configuration, reset, perform transmit/receive, etc.

Many other comments here touch upon these and other aspects as being characteristic of "device drivers", they are missing altogether in the P language (I read the manual, didn't check the source, but I'm quite sure).

There is a "higher" driver - a logical device driver (LDD, [1]). An implementation of LDD is not specific to a device hardware (from some vendor); it remains same across all devices in a certain category. So an LDD is usually supplied/maintained by the OS vendor. For those who are aware of the WinCE architecture, the LDD is called an MDD ([2]).

The P language does seem to enable is specification of LDD - as long as it lends itself to the "message passing machines" paradigm (and in that respect, LDD is no more special to the P-language than any other software that can be modeled using "message passing machines").

References

[1] https://en.wikipedia.org/wiki/Device_driver - distinction between PDD and LDD

[2] https://msdn.microsoft.com/en-us/library/aa447512.aspx

So no B, C, or D?

What about common words like Java, Ruby, Python, Go?

I suppose this makes Scala and Perl the easiest languages to find documentation for.