7 Replies Latest reply on Nov 21, 2015 7:38 PM by xthunderheartx

    mraa_gpio_owner() yakkin' all over my syslog

    xthunderheartx
      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. Re: mraa_gpio_owner() yakkin' all over my syslog
          xbolshe

          Hi,

           

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

           

          BR,

          xbolshe

          • 2. Re: mraa_gpio_owner() yakkin' all over my syslog
            xthunderheartx

            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

            • 3. Re: mraa_gpio_owner() yakkin' all over my syslog
              xbolshe

              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

              • 4. Re: mraa_gpio_owner() yakkin' all over my syslog
                xthunderheartx

                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 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! 

                • 5. Re: mraa_gpio_owner() yakkin' all over my syslog
                  Intel_Peter

                  arfoll, what do you think about this?

                   

                  Peter.

                  • 6. Re: mraa_gpio_owner() yakkin' all over my syslog
                    arfoll

                    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.

                    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...

                    • 7. Re: mraa_gpio_owner() yakkin' all over my syslog
                      xthunderheartx

                      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.