You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@mynewt.apache.org by GitBox <gi...@apache.org> on 2018/10/25 20:59:35 UTC

[GitHub] ccollins476ad commented on issue #221: logcfg: Allow logs to be defined in `syscfg.yml`

ccollins476ad commented on issue #221: logcfg: Allow logs to be defined in `syscfg.yml`
URL: https://github.com/apache/mynewt-newt/pull/221#issuecomment-433203711
 
 
   > Just few things to consider:
   > 
   > * what about some "don't care" (`-1`?) module id which means "first available value" (from some predefined range)?
   
   Good idea.
   
   > * this could also generate file with `id` -> `name` mappings so these can be returned by e.g. `newtmgr` and perhaps also used for some pretty-printing later
   
   I think this is good also.  I was actually thinking something similar after I submitted this PR.  This would remove the need to manually register module names in the application.
   
   > * I'm not sure about the `guest` field. 
   
   I am not sure about `guest` either.  I don't remember what I was thinking exactly.  I think there may be the desire for two different packages to log to the same module, but both packages need their own macros so that they can be disabled independently at build time.  This may not be a real case after all.  I am fine with removing `guest` to simplify the feature.  We can re-add it later if necessary.
   
   > perhaps if we want to reuse id of some other module we could have some other field to reference this by name? my concern is that if we change module id of "host" module then it needs to be updated by all "guests"... if we reference by name, this is not a problem.
   
   We can already reference a module by name if there is a dedicated syscfg setting (e.g., `PKG1_LOG_MODULE`).  If PKG2 wants to use PKG1's log module, it can just specify `MYNEWT_VAL(PKG1_LOG_MODULE)` as its module ID.  This requires a bit of extra work; each package needs to define syscfg settings for its module IDs, but I think this is desirable, as that lets the target override all module IDs in the system.
   
   > and I guess eventually we'll be able to remove hardcoded values from `log_common.h` and replace with this new feature?
   
   Yes, I think that will be a good thing.  We can also remove the distinction between "system modules" and "user modules" that exists today (system module IDs are in the range 0-63).

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services