[Nut-upsdev] [nut-commits] svn commit r1073 - in trunk: .

[Arjen de Korte]

Charles Lepple wrote:

>> Well, almost. There is a theoretical possibility that a device, which
>> is not the same as the original device disconnected, matches all the
>> data in reopen_matcher, but doesn't match subdriver_matcher for some,
>> yet unimplemented, reason.
> I don't know how much of this will affect tripplite_usb, which uses
> some of these files, but some of the Tripplite rackmount UPSes have ID
> numbers that you have to retrieve through the protocol (i.e. not
> available through the standard descriptors). So all of the units would
> have the same PID/VID data, but you would have to connect to each one
> to see what its ID is.

We might solve this by choosing to run subdriver matcher function first.
By doing so, you could in the claim() function (if you find that a
particular VendorID/ProductID combination is supported) modify the
values in the HIDDevice_t struct that is passed by reference to this
function:

	uint16_t VendorID;	/*!< Device's Vendor ID */
	uint16_t ProductID;	/*!< Device's Product ID */
	char*	Vendor;		/*!< Device's Vendor Name */
	char*	Product;	/*!< Device's Product Name */
	char*	Serial;		/* Product serial number */
	char*	Bus;		/* Bus name, e.g. "003" */

In order not to wreak havoc down the line for other matchers, don't do
anything with these values if you find that this might not be the right
subdriver, so a requirement would be that at least the VendorID should
match.

It might then point them (the Vendor and Serial strings that is) to the
right values for this particular device (remember to free() the old
value first, before using strdup to insert the new value). If we append
the regex_matcher *after* the subdriver matcher, it might actually yield
something useful for devices where these items are in non-standard
locations.

This probably has a huge impact on the installed base, so we should
consider the consequences carefully.

Best regards, Arjen