[Nut-upsdev] About nut-scan library

Emilien Kia kiae.dev at gmail.com
Tue Oct 16 08:11:20 UTC 2012


Hi all,

I have started to work with the nut-scan library, to implement a
little tool to generate nut configuration
(https://github.com/balooloo/nut/tree/cliconf).

I have some remarks about the API, I would talk about them and having
your point of view:
1- API does not provide testers to known which protocols are usable
(compiled in).
Indeed, there is no dedicated function to test which protocol is
available (unitary protocol per protocol or globally with flags) nor
return error code to inform requests fail because of lack of library.
2- About function returns, when queries (nutscan_scan_*) return NULL.
The user cannot know if there is no device or if an error occurs.
Perhaps errno usage or modify API to pass "nutscan_device_t*" returns
by result parameter and return an error code can be a good idea.
3- Actually, returned "nutscan_device_t*" are list but there is no
specification of which element of the list is pointed.
In fact, it is generally the last item of the list (which is not
intuitive and not specified in doc).
4- I have also see that scan functions can returns list with multiple
item representing the same element (same driver/port couple, at least
for NSMP).
It is not a real blocker problem but it is not intuitive and not documented.
5- For possibly long time scanner with many network queries (like
SNMP), the scan success result for large network ranges is conditioned
to the system (/22 or /20 subnetwork).
There is no policy of query execution and many can be rejected by the system.
There is no documentation (just a note) about that.

My 2 cents for this morning.

Regards

Emilien



More information about the Nut-upsdev mailing list