<html>
<body>
<font size=3>Jim,<br><br>
The autogen.sh comment makes sense. I had done all of that before working
on adding the second UPS to the device table in the code . (NOTE: Vendor
ID '1234' was a place-holder and not real).<br><br>
I will get things a bit further along and then run autogen.sh again to
see if that automatically corrects the device access issues I was running
into. I expect it will function without manual intervention after
that.<br><br>
Thank you,<br><br>
Bill<br><br>
At 12:30 PM 12/2/2024, Jim Klimov wrote:<br>
<blockquote type=cite class=cite cite="">Hello William,<br><br>
> > 1) Actual lack of permissions (POSIX bits in devfs) - usually
solved by `udev` or similar subsystem that handles hotplug HW for the OS.
Or by running the driver as root and not losing the privileges (user=root
in ups.conf) as a temporary fix and check that this is the case at
all;<br>
><br>
> Thank you, this seems to be the primary problem. I learned enough
about udev to find that the first UPS I was testing with had 'root nut'
ownership. The second UPS used for testing had 'root root' ownership.
When I manually changed the second UPS to 'root nut' ownership the driver
behaved as expected with the second UPS.<br>
><br>
> The question I have now is: Why did the second UPS need manual
ownership change and the first one did not? I know that I didn't do
anything down the /dev/bus/usb/xxx path until today.<br>
><br>
> I have been running the driver in the foreground for the second UPS
but I know I had run the driver "normally" on the first UPS.
Would the ownership have been changed due to the "normal"
driver run versus the "foreground" driver run? Perhaps
something that gets done using 'upsdrvctl' that doesn't get done just
running the driver by itself?<br><br>
Looking at your original post...<br><br>
> The USB device table in the driver I am working on has two entries
for the particular vendor ID I am working with, one for each of two
product IDs...0x0001 and 0x0002. The driver properly matches and can open
the device with the 0x0002 product ID. However, running the same driver
with the 0x0001 ups attached matches but fails to open.<br>
><br>
> This is the relevent output following a successful match and trying
to open the device:<br>
><br>
> 0.002511 [D2] Checking
device 2 of 5 (1234/0001)<br>
> 0.002564 [D1] Failed to
open device (1234/0001), skipping: Access denied (insufficient
permissions)<br><br>
In the main NUT codebase I see no drivers proclaiming support for
`USB_DEVICE(0x1234, <anything>)` (in your case, your driver needs
two such separate lines, with 0x0001 and 0x0002 respectively).<br><br>
These lines lead to generation of NUT's `udev.rules` and similar files
when you `autogen.sh` (or via `make` rules, possibly explicitly called,
in some build scenarios).<br><br>
Only when such an `udev.rules` file is installed into the location the OS
looks at, and activated (`systemctl restart udev` or reboot), and
possibly after the device is re-plugged (or system rebooted, or USB port
reset if conforming) to update the devfs nodes, will the `nut`-oriented
permissions get applied.<br><br>
At least, that's my best educated guess about the situation at the moment
:)<br><br>
Hope this helps,<br>
Jim Klimov<br><br>
<br><br>
<br><br>
<br><br>
On Mon, Dec 2, 2024 at 7:02 PM William R. Elliot
<<a href="mailto:bill@wreassoc.com">bill@wreassoc.com</a>>
wrote:<br>
</font>
<dl>
<dd>Jim, see two comments/questions below...<br><br>
<dd>Bill<br><br>
<dd>At 01:50 AM 11/26/2024, Jim Klimov wrote:<br>
<blockquote type=cite class=cite cite="">
<dd>Cheers,<br><br>
<dd> This error message usually deals with a couple of
situations:<br><br>
<dd>1) Actual lack of permissions (POSIX bits in devfs) - usually solved
by `udev` or similar subsystem that handles hotplug HW for the OS. Or by
running the driver as root and not losing the privileges (user=root in
ups.conf) as a temporary fix and check that this is the case at
all;</blockquote><br>
<dd>Thank you, this seems to be the primary problem. I learned enough
about udev to find that the first UPS I was testing with had 'root nut'
ownership. The second UPS used for testing had 'root root' ownership.
When I manually changed the second UPS to 'root nut' ownership the driver
behaved as expected with the second UPS.<br><br>
<dd>The question I have now is: Why did the second UPS need manual
ownership change and the first one did not? I know that I didn't do
anything down the /dev/bus/usb/xxx path until today.<br><br>
<dd>I have been running the driver in the foreground for the second UPS
but I know I had run the driver "normally" on the first UPS.
Would the ownership have been changed due to the "normal"
driver run versus the "foreground" driver run? Perhaps
something that gets done using 'upsdrvctl' that doesn't get done just
running the driver by itself?<br><br>
<br>
<blockquote type=cite class=cite cite="">
<dd>2) Someone else has hold of the device and libusb can't take it as
exclusively as NUT needs (lsof/fuser/... to check if any other programs
hold it - maybe another copy of your driver program in debugger
etc).</blockquote><br>
<dd>Didn't go here as I made progress with udev above. Plus I am the only
one running the driver on this machine.<br><br>
<br>
<blockquote type=cite class=cite cite="">
<dd>Happy Thanksgiving,<br>
<dd>Jim<br><br>
<dd>On Tue, Nov 26, 2024 at 4:37 AM William R. Elliot
<<a href="mailto:bill@wreassoc.com">bill@wreassoc.com</a>> wrote:
<dl>
<dd>Hello again.<br>
<dd>The USB device table in the driver I am working on has two entries
for the particular vendor ID I am working with, one for each of two
product IDs...0x0001 and 0x0002. The driver properly matches and can open
the device with the 0x0002 product ID. However, running the same driver
with the 0x0001 ups attached matches but fails to open.<br>
<dd>This is the relevent output following a successful match and trying
to open the device:<br><br>
<dd><font face="Courier New, Courier" size=3>
0.002511 [D2] Checking device 2 of 5 (1234/0001)
<dd> 0.002564 [D1] Failed to open
device (1234/0001), skipping: Access denied (insufficient
permissions)<br><br>
</font>
<dd>My expectation would be that either device, once matched, would be
able to be opened and then further steps can be taken to confirm that the
driver is communicating with an expected device.<br>
<dd>I would appreciate any pointers toward something I may have
missed.<br>
<dd>Thank you,<br>
<dd>Bill<br>
<dd>Happy Thanksgiving to the U.S. folks!<br>
<dd>Virus-free.
<a href="https://www.avg.com/" eudora="autourl">www.avg.com</a>
<a href="#m_6439276482505671098_m_-6725320979215136950_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2">
</a>
<dd>_______________________________________________
<dd>Nut-upsdev mailing list
<dd><a href="mailto:Nut-upsdev@alioth-lists.debian.net">
Nut-upsdev@alioth-lists.debian.net</a>
<dd>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev" eudora="autourl">
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev</a>
</blockquote>
</dl>
</dl></blockquote></body>
</html>