New generation drivers - networkupstools/nut GitHub Wiki

  1. Runtime architecture approaches

2 options:

  • nutdrv_main (loader) + libnutdrv_<device_protocol> + libnutcomm_<communication_protocol>

    • pros => minimize footprints, allow max. reuse, allow multiple communication interfaces (classic nut, snmp, ampq), use symlink (?)
    • cons => use libltdl; fewer optimization opportunities with shared libraries; will require more extensive testing than incremental changes

  • classic (current) style monolithic (static) compilation

    • pros => classic, known, no libltdl,
    • cons => not flexible, doesn't allow other communication interfaces (classic nut, snmp, ampq),
  1. Binaries naming convention

Drivers (or driver libraries) will follow the (lib)nutdrv_* naming

  • (lib)nutdrv_skel
  • (lib)nutdrv_repeater
  • (lib)nutdrv_simu[lator]
  • (lib)nutdrv_snmp
  • (lib)nutdrv_modbus
  • (lib)nutdrv_usbhid
  • ...

Cons: ps defaults to narrow columns for process names

  • address generic driver with
    • a generic engine
    • external mapping file, to ease adding new mapping and modifying existing ones, while not overloading the driver nor having to recompile it,
  • thread-safe code in libs, and main.cpp loader / "empty shell" (using symlinks...),
    • but threads don't mix well with hardware
  • callbacks with real interface (not void/void))