snmp-ups: enhance the --mibs (plural!) to actually support several MIBs
#2036
Labels
Data multipathing
This tag is for issues about multiple data paths to same device (multiplexing different media, MIBs)
DMF
NUT Data/Dynamic Mapping File/Format/Functionality feature
enhancement
SNMP
Milestone
Comments
jimklimov
added
enhancement
SNMP
Data multipathing
jimklimov
added a commit
to jimklimov/nut
that referenced
this issue
Sep 5, 2023
…s#2036] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
alexwbaule
pushed a commit
to alexwbaule/nut
that referenced
this issue
Oct 4, 2023
…s#2036] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com> Signed-off-by: Alex W Baulé <alexwbaule@gmail.com>
jimklimov
added
the
DMF
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
With the argument called
mibs(plural) it could make sense to actually support a list of MIBs to try to get info from, in order of preference, e.g. both a vendor MIB and the IETF MIB for missing data points. Or even several vendor MIBs for devices from companies with a long heritage.After all, the running driver instance builds itself an in-memory list of OIDs to walk (optionally minding ways convert data) which pertain to the certain device. Why not pick lines originally stored in different
mib2nuttables?..@aquette : WDYT? Any blockers I've overlooked here? Theoretically this is something that DMF (#182, branch et al) could achieve with specially crafted mapping resource files, so why can't the core do similar with its built-in data?
The text was updated successfully, but these errors were encountered: