sys/stats and sys/log

[marko kiiskila <ma...@runtime.io>]

Hi,

at the moment it is not very easy to get rid of all code
related to logging and/or statistics.
I ran across this when trying to see how small I can
make an image while keeping BLE and OIC.

Therefore, I was going to create stub packages for
sys/stats and sys/log.

Then, within the app you can choose between a stub or
an actual implementation. We have this same model for
picking up implementation of console.

Alternative would be to make syscfg knobs for these.
However, I think I prefer the stub packages, I believe
that will make the code easier to read (less #ifdef's).

What do you guys think?

Re: sys/stats and sys/log

[marko kiiskila <ma...@runtime.io>]

Ok, (mostly) done.

I named the full implementation and stub similarly to console.
I.e. sys/log is now under sys/log/full. And stats sys/stats/full.

Unfortunate side-effect of this is that the app dependencies
will have to adjusted.
Previously, app might not have even needed to explicitly list
sys/stats, as this gets brought in by net/nimble/host, for example.

Now, either sys/stats/full or sys/stats/stub should be picked in
the app pkg.yml file. And the same is true for sys/log.

I’ll make another sweep through the packages and try to make sure
that they compile, regardless of whether using stub or not. Most of
them should be ok by now, but I noticed few are still not.

> On Jan 17, 2017, at 3:41 PM, will sanfilippo <wi...@runtime.io> wrote:
> 
> I think the stub approach is fine as well.
> 
>> On Jan 17, 2017, at 1:43 PM, Kevin Townsend <ke...@adafruit.com> wrote:
>> 
>> I don't have any issues with the stub approach myself, and it's easy to switch back and forth (no more work than changing syscfg.yml)
>> 
>> 
>> On 17/01/17 22:07, marko kiiskila wrote:
>>> Hi,
>>> 
>>> at the moment it is not very easy to get rid of all code
>>> related to logging and/or statistics.
>>> I ran across this when trying to see how small I can
>>> make an image while keeping BLE and OIC.
>>> 
>>> Therefore, I was going to create stub packages for
>>> sys/stats and sys/log.
>>> 
>>> Then, within the app you can choose between a stub or
>>> an actual implementation. We have this same model for
>>> picking up implementation of console.
>>> 
>>> Alternative would be to make syscfg knobs for these.
>>> However, I think I prefer the stub packages, I believe
>>> that will make the code easier to read (less #ifdef's).
>>> 
>>> What do you guys think?
>> 
> 

Re: sys/stats and sys/log

[will sanfilippo <wi...@runtime.io>]

I think the stub approach is fine as well.

> On Jan 17, 2017, at 1:43 PM, Kevin Townsend <ke...@adafruit.com> wrote:
> 
> I don't have any issues with the stub approach myself, and it's easy to switch back and forth (no more work than changing syscfg.yml)
> 
> 
> On 17/01/17 22:07, marko kiiskila wrote:
>> Hi,
>> 
>> at the moment it is not very easy to get rid of all code
>> related to logging and/or statistics.
>> I ran across this when trying to see how small I can
>> make an image while keeping BLE and OIC.
>> 
>> Therefore, I was going to create stub packages for
>> sys/stats and sys/log.
>> 
>> Then, within the app you can choose between a stub or
>> an actual implementation. We have this same model for
>> picking up implementation of console.
>> 
>> Alternative would be to make syscfg knobs for these.
>> However, I think I prefer the stub packages, I believe
>> that will make the code easier to read (less #ifdef's).
>> 
>> What do you guys think?
> 

Re: sys/stats and sys/log

[Kevin Townsend <ke...@adafruit.com>]

I don't have any issues with the stub approach myself, and it's easy to 
switch back and forth (no more work than changing syscfg.yml)


On 17/01/17 22:07, marko kiiskila wrote:
> Hi,
>
> at the moment it is not very easy to get rid of all code
> related to logging and/or statistics.
> I ran across this when trying to see how small I can
> make an image while keeping BLE and OIC.
>
> Therefore, I was going to create stub packages for
> sys/stats and sys/log.
>
> Then, within the app you can choose between a stub or
> an actual implementation. We have this same model for
> picking up implementation of console.
>
> Alternative would be to make syscfg knobs for these.
> However, I think I prefer the stub packages, I believe
> that will make the code easier to read (less #ifdef's).
>
> What do you guys think?