running linked-in drivers outside of erts?

[Shawn Pearce]

I'm about a 3rd of the way into writing this external driver container
program...  I still have a lot of the APIs to implement, but I do
want to thank the genius who designed the Windows dynamic driver magic.
TWinDynDriverCallbacks made it possible for the same DLL to be loaded
both into my process and beam, without relinking.

This effort should be easily modified to allow drivers to run in a
different security context than the node, using CreateProcessAsUser on
NT systems, and setuid executables on UNIX.  I'm not sure if this is
of any help to folks, but it might be nice to be able to let erts
drop its permissions down to almost nothing, and use isolated external
servers to do the dirty work of talking to an actual device.  Or the
exact reverse, run erts with relatively high access rights to files on
the local system, but push driver code down into very tight sandboxes
that can't do squat.

I think I'm sort of insane for even trying this, but its fun.  One
problem is port_call/3 and port_control/3 will block beam while it
waits for the external driver to respond.  :-(

Shawn Pearce <spearce@REDACTED> wrote:
> Ok, so I'm building a whole slew of drivers this week, and I want
> them to run both in erts, and outside as a port process.  Reason is,
> for early development or environments where I can't have the node crash
> due to a driver bug, I want the safety of the port process - but other
> users of the driver, or in some situations, I may want to use a loaded
> driver for performance/memory/etc.
> 
> Has anyone thought about writing a driver compatability layer that
> would offer most of the driver_* APIs, but in an external shell? This
> would let the a driver written for erl_ddll to be loaded in an external
> port process.

-- 
Shawn.