Investigate dual-process model like upsmon for drivers #1663
Description
Idea stemming from discussions of USB reconnections when a device gets lost - particularly USB which gets grabbed by kernel and then rules like udev may give it back to NUT account in the OS (but may not exist e.g. due to not-yet-handled VendorID:ProductID pairs, so they are not listed in pre-built rules files, and users run the driver persistently as root).
The idea is to add an option (probably in main.c to cover future cases and simplify sharing between existing usbhid-ups, nutdrv_qx, blazer_ups et al) that a driver running initially as root would connect to device (as root) and fork before dropping privileges, and in this case the unprivileged child process would handle the protocol and exit with a special exit code upon connection loss. If the parent sees that code, it takes care of reconnection and forking again.
Maybe they can also PING-PONG, so a driver stuck on some I/O or library request would be killed and restarted, similar to issues killing off an earlier driver instance when starting a new one and finding a PID file (sometimes requiring a SIGKILL if a SIGTERM did not help). This would make the facility useful for non-root cases also.
This feels like a viable trade-off between running as root all the time vs. not getting back the device if connection drops (poor udev rules or similar facilities in other OSes). Note that generally we can't rely on existance of systemd/SMF/... to restart a driver if it just exits due to connection loss.