New generation drivers

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),

2. 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))