Regarding the follow-up, IIRC `open` walks a device list returned by libusb, checks each entry against the matcher, and tells libusb if it wants to claim the device described by a particular entry. I don't think it walks further entries after a successful match and claim? We can't use the matcher directly, because its fields can be a regex geberally (e.g. `vendor=A*` instead of `APC` or `Aardwark` specifically), and because libusb device descriptors are a black box for us (FD, struct, blob - whatever the token we pass to library methods is on a platform and lib version). Also matching can involve callbacks, so a driver can probe the device in more detail (okay, you're APC - but do you talk USB HID or Modbus or microsol?) Hope this helps, Jim Klimov On Tue, Nov 26, 2024, 15:53 William R. Elliot <bill at wreassoc.com> wrote:> Jim, > > Thanks for the quick reply. > > I'll try number 1 below but I don't have the understanding as to why that > would be for this UPS and not the other UPS in the family. > > For number 2, kind of the same comment. Why would someone else hold this > device and not the other vendor ups that is working. I am running the > driver in the foreground and not through a debugger. > > A follow up question that hit me this morning even though I have seen the > evidence for weeks: If there is a successful Regex Match, why does the > "open" command walk through the five or so available USB devices? Why is > "open" not just opening what is in the matcher structure? I'm clearly > missing something here about how all the USB stuff works. > > Thanks, > > Bill > > At 01:50 AM 11/26/2024, Jim Klimov wrote: > > Cheers, > > This error message usually deals with a couple of situations: > > 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; > > 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). > > Happy Thanksgiving, > Jim > > On Tue, Nov 26, 2024 at 4:37 AM William R. Elliot <bill at wreassoc.com> > wrote: > > Hello again. > > 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. > > This is the relevent output following a successful match and trying to > open the device: > > 0.002511 [D2] Checking device 2 of 5 (1234/0001) > 0.002564 [D1] Failed to open device (1234/0001), skipping: Access > denied (insufficient permissions) > > 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. > > I would appreciate any pointers toward something I may have missed. > > Thank you, > > Bill > > Happy Thanksgiving to the U.S. folks! > > Virus-free. www.avg.com > <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> > > <#m_-5248667457445858416_m_-6725320979215136950_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > _______________________________________________ > Nut-upsdev mailing list > Nut-upsdev at alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20241126/3e360b30/attachment-0001.htm>
Thinking of it, we can't conjure a libusb descriptor from thin air because the library can have internal state associated with it (allocated buffers, open-close count, etc.) On Tue, Nov 26, 2024, 21:06 Jim Klimov <jimklimov+nut at gmail.com> wrote:> Regarding the follow-up, IIRC `open` walks a device list returned by > libusb, checks each entry against the matcher, and tells libusb if it wants > to claim the device described by a particular entry. I don't think it walks > further entries after a successful match and claim? > > We can't use the matcher directly, because its fields can be a regex > geberally (e.g. `vendor=A*` instead of `APC` or `Aardwark` specifically), > and because libusb device descriptors are a black box for us (FD, struct, > blob - whatever the token we pass to library methods is on a platform and > lib version). > > Also matching can involve callbacks, so a driver can probe the device in > more detail (okay, you're APC - but do you talk USB HID or Modbus or > microsol?) > > Hope this helps, > Jim Klimov > > On Tue, Nov 26, 2024, 15:53 William R. Elliot <bill at wreassoc.com> wrote: > >> Jim, >> >> Thanks for the quick reply. >> >> I'll try number 1 below but I don't have the understanding as to why that >> would be for this UPS and not the other UPS in the family. >> >> For number 2, kind of the same comment. Why would someone else hold this >> device and not the other vendor ups that is working. I am running the >> driver in the foreground and not through a debugger. >> >> A follow up question that hit me this morning even though I have seen the >> evidence for weeks: If there is a successful Regex Match, why does the >> "open" command walk through the five or so available USB devices? Why is >> "open" not just opening what is in the matcher structure? I'm clearly >> missing something here about how all the USB stuff works. >> >> Thanks, >> >> Bill >> >> At 01:50 AM 11/26/2024, Jim Klimov wrote: >> >> Cheers, >> >> This error message usually deals with a couple of situations: >> >> 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; >> >> 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). >> >> Happy Thanksgiving, >> Jim >> >> On Tue, Nov 26, 2024 at 4:37 AM William R. Elliot <bill at wreassoc.com> >> wrote: >> >> Hello again. >> >> 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. >> >> This is the relevent output following a successful match and trying to >> open the device: >> >> 0.002511 [D2] Checking device 2 of 5 (1234/0001) >> 0.002564 [D1] Failed to open device (1234/0001), skipping: Access >> denied (insufficient permissions) >> >> 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. >> >> I would appreciate any pointers toward something I may have missed. >> >> Thank you, >> >> Bill >> >> Happy Thanksgiving to the U.S. folks! >> >> Virus-free. www.avg.com >> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> >> >> <#m_-887649569300041980_m_-5248667457445858416_m_-6725320979215136950_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >> _______________________________________________ >> Nut-upsdev mailing list >> Nut-upsdev at alioth-lists.debian.net >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20241126/102d949d/attachment.htm>
Sorry for typo in regex example, should have been `vendor="A.*"` :) Jim On Tue, Nov 26, 2024, 21:06 Jim Klimov <jimklimov+nut at gmail.com> wrote:> Regarding the follow-up, IIRC `open` walks a device list returned by > libusb, checks each entry against the matcher, and tells libusb if it wants > to claim the device described by a particular entry. I don't think it walks > further entries after a successful match and claim? > > We can't use the matcher directly, because its fields can be a regex > geberally (e.g. `vendor=A*` instead of `APC` or `Aardwark` specifically), > and because libusb device descriptors are a black box for us (FD, struct, > blob - whatever the token we pass to library methods is on a platform and > lib version). > > Also matching can involve callbacks, so a driver can probe the device in > more detail (okay, you're APC - but do you talk USB HID or Modbus or > microsol?) > > Hope this helps, > Jim Klimov > > On Tue, Nov 26, 2024, 15:53 William R. Elliot <bill at wreassoc.com> wrote: > >> Jim, >> >> Thanks for the quick reply. >> >> I'll try number 1 below but I don't have the understanding as to why that >> would be for this UPS and not the other UPS in the family. >> >> For number 2, kind of the same comment. Why would someone else hold this >> device and not the other vendor ups that is working. I am running the >> driver in the foreground and not through a debugger. >> >> A follow up question that hit me this morning even though I have seen the >> evidence for weeks: If there is a successful Regex Match, why does the >> "open" command walk through the five or so available USB devices? Why is >> "open" not just opening what is in the matcher structure? I'm clearly >> missing something here about how all the USB stuff works. >> >> Thanks, >> >> Bill >> >> At 01:50 AM 11/26/2024, Jim Klimov wrote: >> >> Cheers, >> >> This error message usually deals with a couple of situations: >> >> 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; >> >> 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). >> >> Happy Thanksgiving, >> Jim >> >> On Tue, Nov 26, 2024 at 4:37 AM William R. Elliot <bill at wreassoc.com> >> wrote: >> >> Hello again. >> >> 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. >> >> This is the relevent output following a successful match and trying to >> open the device: >> >> 0.002511 [D2] Checking device 2 of 5 (1234/0001) >> 0.002564 [D1] Failed to open device (1234/0001), skipping: Access >> denied (insufficient permissions) >> >> 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. >> >> I would appreciate any pointers toward something I may have missed. >> >> Thank you, >> >> Bill >> >> Happy Thanksgiving to the U.S. folks! >> >> Virus-free. www.avg.com >> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> >> >> <#m_-887649569300041980_m_-5248667457445858416_m_-6725320979215136950_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >> _______________________________________________ >> Nut-upsdev mailing list >> Nut-upsdev at alioth-lists.debian.net >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20241126/45c914ff/attachment.htm>