After doing a little digging, I tracked it down to a line in the USB library; sure enough, IOHIDDeviceOpen returns a "privilege violation" error. And just to confirm, if I run NaviServer as root, it all works fine. So thanks again Gustaf for pointing me in the right direction.
Now I just need to puzzle out why there's no privilege violation when I run the code via tclsh from the command line. Hopefully that will give me some ideas for a fix since running NaviServer as root isn't really a practical option. Regards, Matt On Sat, Jun 29, 2024 at 8:48 AM < naviserver-devel-requ...@lists.sourceforge.net> wrote: > Date: Fri, 28 Jun 2024 12:41:30 -0400 > From: Matthew Burke <mmb1...@gmail.com> > To: naviserver-devel@lists.sourceforge.net > Subject: Re: [naviserver-devel] Problem with a Tcl extension and NaviServer > Message-ID: > < > cacax+mmgr5xwy2vy5joswjszcqefda1w_5ykyoq0updtluh...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi Gustaf, > > Thanks for the reply. I'll start looking into permissions issues and see if > anything there looks promising. I should also instrument the USB library > and try to get a better sense of what, exactly, is failing. > > Regards, > > Matt > > > On Thu, Jun 27, 2024 at 9:15?AM < > naviserver-devel-requ...@lists.sourceforge.net> wrote: > > > > > Dear Mathew, > > > > The answer for your this problem is probably in the call of > > blink1_openById(devid); > > > > Without looking into this call, I would suspect first from my experience > > with NaviServer IoT projects a permission problem when accessing the > > hardware interface. > > For security reasons, NaviServer switches to a nonprivileged user ... > > > > all the best -g > > > > On 25.06.24 16:18, Matthew Burke wrote: > > > Hello! > > > > > > I am writing a Tcl extension in C to wrap a driver for a USB LED > > > status light. The extension runs fine from tclsh but there are issues > > > running it from a Tcl ?page under NaviServer. > > > > > > The extension implements one command via Tcl_CreateObjCommand. The > > > command proc implements a number of sub-commands broken into two > > > categories: device-independent functionality, e.g. count the number of > > > status lights that are plugged in, and device-dependent functionality, > > > e.g. attach to a status light, display a particular color, etc > > > > > > The device-independent sub-commands work when run in a Tcl page. For > > > example, this page runs fine when served from NaviServer: > > > > > > > > > package require blink > > > > > > set n [blink enumerate] > > > > > > ns_return 200 text/html " > > > There are <strong>$n</strong> devices plugged in. > > > " > > > > > > > > > In order to have a device display a color, etc., you first have to run > > > the "open" command. And that's not working. So here's an example Tcl > > page: > > > > > > > > > package require blink > > > > > > set d [blink open 0] > > > set q [ns_conn query] > > > set s [ns_parsequery $q] > > > > > > set red [ns_set get $s red 255] > > > set green [ns_set get $s green 0] > > > set blue [ns_set get $s blue 0] > > > > > > blink set $d $red $green $blue > > > > > > ns_return 200 text/html " > > > ? ? <p>Query: [ns_conn query]</p> > > > > > > ? ? <ul> > > > ? ? <li>Red: $red</li> > > > ? ? <li>Green: $green</li> > > > ? ? <li>Blue: $blue</li> > > > ? ? </ul> > > > " > > > > > > > > > When this page is served, I get an error in the line: set d [blink > > > open 0]. > > > > > > There is a C struct, Blinker, ?that contains data about the attached > > > device. My C code first allocates > > > memory for the struct > > > > > > > > > blinkPtr = (Blinker *)Tcl_Alloc(sizeof(Blinker)); > > > > > > > > > and this seems to work -- blinkPtr is non-NULL after the assignment. > > > Then there is a function from the driver library that actually > > > attaches to the device: > > > > > > blinkPtr->device = blink1_openById(devid); > > > > > > It should return the memory address of an allocated structure that's > > > part of the USB library. But the?function?returns NULL. (Just to > > > reiterate, this works fine when run from tclsh and returns a non-NULL > > > value.) > > > > > > I'm assuming there is some sort of memory protection or similar that I > > > need to take into account. Any suggestions on what to look at would be > > > greatly appreciated. > > > > > > Thanks, > > > > > > Matt > > > > > > P.S. This is on macOS 14.3. I'm compiling the extension as follows: > > > > > > clang -dynamiclib -DUSE_TCL_STUBS -I/usr/local/ns/include > > > -L/usr/local/ns/lib -ltclstub8.6 -o blink.dylib blink.c > > > -L/usr/local/lib -lBlink1 > > > > > > > > > > > > > > > _______________________________________________ > > > naviserver-devel mailing list > > > naviserver-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > > > > > > > > ------------------------------ > > > > > > > > ------------------------------ > > > > Subject: Digest Footer > > > > _______________________________________________ > > naviserver-devel mailing list > > naviserver-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > > > > > > ------------------------------ > > > > End of naviserver-devel Digest, Vol 162, Issue 3 > > ************************************************ > > > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > naviserver-devel mailing list > naviserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > > > ------------------------------ > > End of naviserver-devel Digest, Vol 162, Issue 4 > ************************************************ >
_______________________________________________ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
