Re: Bluetooth 5 support - configurability

[Szymon Janc]

Hi,

On Monday, 10 April 2017 22:42:53 CEST will sanfilippo wrote:
> +1 on opt-in for BT5 although I do think there are quite a few configuration
> variables for features that are on by default. Not sure there is a rhyme or
> reason, other than possibly the thought that “most people would be enabling
> this, so let’s have it on by default”.

OK, lets go with opt-in. We can always change it to opt-out if feature is 
widely used and doesn't require huge amount of memory.

-- 
pozdrawiam
Szymon Janc

Re: Bluetooth 5 support - configurability

[will sanfilippo]

+1 on opt-in for BT5 although I do think there are quite a few configuration 
variables for features that are on by default. Not sure there is a rhyme or 
reason, other than possibly the thought that “most people would be enabling 
this, so let’s have it on by default”.


> On Apr 10, 2017, at 11:50 AM, Łukasz Rymanowski 
>  wrote:
> 
> Hi,
> 
> On 10 April 2017 at 18:15, will sanfilippo  wrote:
> 
>> I think #3 is fine as well. If, for some reason, folks do not want to
>> claim 5.0 support they can always use release 1.0.0 of Mynewt.
>> 
>> 
>> 
>> On Apr 10, 2017, at 6:16 AM, Szymon Janc  wrote:
>>> 
>>> Hello Community,
>>> 
>>> We are currently upstreaming Bluetooth 5 functionality into Apache
>> Mynewt.
>>> Sine all of the new features are optional to support (excluding internal
>>> dependencies) we could make Mynewt code configurable per feature. It
>> shouldn't
>>> be too much hasle to support this via syscfg.yml with MYNEWT_VALs.
>>> 
>>> There are few possible paths and I'd like to gather some feedback.
>>> 
>>> 1. Always claim 5.0 (LL version) support and leave all features
>> configurable.
>>> 2. Same as 1. but also allow to configure 4.2 vs 5.0 support.
>>> 3. Same as 1. but always enable triavials (Privacy Erratas, High Duty Un-
>>> Directed Advertising) and leave other features configurable.
>> 
>> 4. Always enabled everything.
>>> 
>>> Personnally I'd opt for 3. Mostly due to fact that it doesn't increse
>> code
>>> size comparing to 4.2 and reduces number of configuration variables. So
>> it
>>> feels to be a good compromise between configurability and complexity.
>>> 
>> 
> 
> That looks good to me as well.
> 
>> There is also open point of opt-in vs opt-out configruation. I think we
>> should
>>> go with opt-in ie. optional feature needs to be explicitly enabled in
>> syscfg.
>>> 
>> 
> 
> I think other features  (e.g. LE CoC) are opt-in so we should follow that.
> 
> 
>>> Comments?
>>> 
>>> --
>>> pozdrawiam
>>> Szymon Janc
>> 
>> 
> Best
> Łukasz

Re: Bluetooth 5 support - configurability

[Łukasz Rymanowski]

Hi,

On 10 April 2017 at 18:15, will sanfilippo  wrote:

> I think #3 is fine as well. If, for some reason, folks do not want to
> claim 5.0 support they can always use release 1.0.0 of Mynewt.
>
>
>
> On Apr 10, 2017, at 6:16 AM, Szymon Janc  wrote:
> >
> > Hello Community,
> >
> > We are currently upstreaming Bluetooth 5 functionality into Apache
> Mynewt.
> > Sine all of the new features are optional to support (excluding internal
> > dependencies) we could make Mynewt code configurable per feature. It
> shouldn't
> > be too much hasle to support this via syscfg.yml with MYNEWT_VALs.
> >
> > There are few possible paths and I'd like to gather some feedback.
> >
> > 1. Always claim 5.0 (LL version) support and leave all features
> configurable.
> > 2. Same as 1. but also allow to configure 4.2 vs 5.0 support.
> > 3. Same as 1. but always enable triavials (Privacy Erratas, High Duty Un-
> > Directed Advertising) and leave other features configurable.
>
> 4. Always enabled everything.
> >
> > Personnally I'd opt for 3. Mostly due to fact that it doesn't increse
> code
> > size comparing to 4.2 and reduces number of configuration variables. So
> it
> > feels to be a good compromise between configurability and complexity.
> >
>

That looks good to me as well.

> There is also open point of opt-in vs opt-out configruation. I think we
> should
> > go with opt-in ie. optional feature needs to be explicitly enabled in
> syscfg.
> >
>

I think other features  (e.g. LE CoC) are opt-in so we should follow that.


> > Comments?
> >
> > --
> > pozdrawiam
> > Szymon Janc
>
>
Best
Łukasz

Re: Bluetooth 5 support - configurability

[will sanfilippo]

I think #3 is fine as well. If, for some reason, folks do not want to claim 5.0 
support they can always use release 1.0.0 of Mynewt.


> On Apr 10, 2017, at 6:16 AM, Szymon Janc  wrote:
> 
> Hello Community,
> 
> We are currently upstreaming Bluetooth 5 functionality into Apache Mynewt. 
> Sine all of the new features are optional to support (excluding internal 
> dependencies) we could make Mynewt code configurable per feature. It 
> shouldn't 
> be too much hasle to support this via syscfg.yml with MYNEWT_VALs.
> 
> There are few possible paths and I'd like to gather some feedback.
> 
> 1. Always claim 5.0 (LL version) support and leave all features configurable.
> 2. Same as 1. but also allow to configure 4.2 vs 5.0 support.
> 3. Same as 1. but always enable triavials (Privacy Erratas, High Duty Un-
> Directed Advertising) and leave other features configurable.
> 4. Always enabled everything.
> 
> Personnally I'd opt for 3. Mostly due to fact that it doesn't increse code 
> size comparing to 4.2 and reduces number of configuration variables. So it 
> feels to be a good compromise between configurability and complexity.
> 
> There is also open point of opt-in vs opt-out configruation. I think we 
> should 
> go with opt-in ie. optional feature needs to be explicitly enabled in syscfg.
> 
> Comments?
> 
> -- 
> pozdrawiam
> Szymon Janc