Community
cancel
Showing results for 
Search instead for 
Did you mean: 
DPose
New Contributor II
1,651 Views

mraa_gpio_owner() yakkin' all over my syslog

Jump to solution

mraa_result_t

mraa_gpio_owner(mraa_gpio_context dev, mraa_boolean_t own)

{

if (dev == NULL) {

return MRAA_ERROR_INVALID_RESOURCE;

syslog(LOG_DEBUG, "gpio: Set owner to %d", (int) own);

dev->owner = own;

return MRAA_SUCCESS;

}

Anybody know what this is for and why it is so important for it to barf all over my syslog? Is it telling me something important?

Dallas

1 Solution
Brendan_L_Intel
Employee
116 Views

You can use the owner concept in C++ and C it's an optional constructor param in C++. It just means mraa won't clean up when you do a mraa_gpio_close or run the destructor.

https://github.com/intel-iot-devkit/mraa/blob/master/api/mraa/gpio.hpp# L118 mraa/gpio.hpp at master · intel-iot-devkit/mraa · GitHub

The concept is there in case a small mraa scriptis used to do muxing (especially in raw mode) and then the script closes (which in python/node/java would cause an auto resource cleanup) meaning muxing back to not available. Does that make any sense?

If you want to debug gdb is much better than syslog . In any case this message is set to DEBUG importance meaning it's not that important but at some point in dev someone thought he wanted to monitor that, if you really don't like it submit a PR, personally I don't see the harm in it...

View solution in original post

7 Replies
asss
Valued Contributor II
116 Views

Hi,

it is used to inform need to unexport gpio pin in sysfs or not.

BR,

xbolshe

DPose
New Contributor II
116 Views

I don't understand your answer. Can you elaborate? What does my pure C/C++ app have to do to prevent this from polluting my syslog? It it is indicative of an error of some kind? If not why is it logged at debug level?

Thanx,

Dallas

asss
Valued Contributor II
116 Views

It is just a debug message. And how about mraa_set_log_level ? Do you use it?

mraa_result_t

mraa_set_log_level(int level)

{

if (level <= 7 && level >= 0) {

setlogmask(LOG_UPTO(level));

syslog(LOG_DEBUG, "Loglevel %d is set", level);

return MRAA_SUCCESS;

}

syslog(LOG_NOTICE, "Invalid loglevel %d requested", level);

return MRAA_ERROR_INVALID_PARAMETER;

}

BR,

xbolshe

DPose
New Contributor II
116 Views

Ok I can accept that it's a debug message. What bug does it indicate that I need to "de"? I think I don't just understand the idea of "ownership" as it applies to the resources under MRAA's domain.

The whole point of this is that I have an issue that I'm trying to debug (in the true sense of the word), so when I look at the log I expect to see information that gives me clues about what my code is doing wrong. When I see some debug message come from MRAA, I think "maybe I should investigate that". Looking at where this log comes from, I don't understand what I might be doing wrong.

As for mraa_set_log_level(int level) I did see that when it found it's way into the library recently (I don't think it was in at the start), but as I'm trying to debug a problem around the Galileo's hardware abstraction layer, I don't think masking debug messages from it would be a good idea.

Looking here https://github.com/intel-iot-devkit/mraa/blob/master/include/mraa_internal_types.h mraa/mraa_internal_types.h at master · intel-iot-devkit/mraa · GitHub I see:

/**

* A structure representing a gpio pin.

*/

struct _gpio {

/*@{*/

int pin; /**< the pin number, as known to the os. */

int phy_pin; /**< pin passed to clean init. -1 none and raw*/

int value_fp; /**< the file pointer to the value of the gpio */

void (* isr)(void *); /**< the interupt service request */

void *isr_args; /**< args return when interupt service request triggered */

pthread_t thread_id; /**< the isr handler thread id */

int isr_value_fp; /**< the isr file pointer on the value */

mraa_boolean_t isr_thread_terminating; /**< is the isr thread being terminated? */

mraa_boolean_t owner; /**< If this context originally exported the pin */

mraa_result_t (*mmap_write) (mraa_gpio_context dev, int value);

int (*mmap_read) (mraa_gpio_context dev);

mraa_adv_func_t* advance_func; /**< override function table */

/*@}*/

};

Which still doesn't make it clear to me what

mraa_boolean_t owner; /**< If this context originally exported the pin */

is. However, further investigation shows what this field is set to 0 in every MRAA subsytem's context creation routine via mraa_setup_mux_mapped. Which is what generates the syslog entry in the first place. Digging even further, the only place where this is get set to true seems to be in mraa_gpio_init_internal which is not exposed to the API anywhere of course. So the only way for it to get set to anything other than 0, therefore giving the syslog entry any meaning whatsoever to the user is via mraa_gpio_owner. Which is not exposed to the C++ api at all!

So this syslog entry tells me, the user of the MRAA library, in a cryptic and arcane way, that I created a context. That's useful-not.

From what I can fathom though, what "owership" is really about is who gets to "unexport" the resource from sysfs. I suppose that keeps other pesky processes that access the boards resources via sysfs from muckin' about with them. Is that the idea? If so, how about giving me an API that lets me do that and at least change the syslog entry LOG_INFO ("Normal operational messages that require no action"). I certainly don't want uninvited guests twiddling my bits for Pitty's sake!

Pedro_M_Intel
Employee
116 Views

arfoll, what do you think about this?

Peter.

Brendan_L_Intel
Employee
117 Views

You can use the owner concept in C++ and C it's an optional constructor param in C++. It just means mraa won't clean up when you do a mraa_gpio_close or run the destructor.

https://github.com/intel-iot-devkit/mraa/blob/master/api/mraa/gpio.hpp# L118 mraa/gpio.hpp at master · intel-iot-devkit/mraa · GitHub

The concept is there in case a small mraa scriptis used to do muxing (especially in raw mode) and then the script closes (which in python/node/java would cause an auto resource cleanup) meaning muxing back to not available. Does that make any sense?

If you want to debug gdb is much better than syslog . In any case this message is set to DEBUG importance meaning it's not that important but at some point in dev someone thought he wanted to monitor that, if you really don't like it submit a PR, personally I don't see the harm in it...

View solution in original post

DPose
New Contributor II
116 Views

Thanx for the explanation arfoll, and yes it does make sense. In fact it explains a behavior I noticed awhile back. When you explained the TTYS1 muxing to me, I wrote a little test app in C which did the mux setup in a function using the C API. I just left the mraa contexts I used open and even though they fell out of execution context when the function exited, the muxes "stayed muxed" as it were. But when I took this same code over to my real deal C++ app I used the C++ API and when the method exited, the muxes came "unmuxed" because as the Gpio instances fell out of context their, destructors got called and I guess I didn't set the owner parm to 1 (???). So anyway at the time, I just made the Gpio instances static and that "fixed" it obviously because it kept the destructor from being called on exit. I'm gonna revisit that and fix it proper.

As for the syslog issue, no problem, I just don't think it is a very useful log.

Reply