You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Szymon Janc <sz...@codecoup.pl> on 2017/04/10 13:16:13 UTC
Bluetooth 5 support - configurability
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
Re: Bluetooth 5 support - configurability
Posted by Szymon Janc <sz...@codecoup.pl>.
On Monday, 10 April 2017 22:55:46 CEST Szymon Janc wrote:
> 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.
OK, I've updated https://github.com/apache/incubator-mynewt-core/pull/224 with
what we agreed here.
--
pozdrawiam
Szymon Janc
Re: Bluetooth 5 support - configurability
Posted by Szymon Janc <sz...@codecoup.pl>.
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
Posted by will sanfilippo <wi...@runtime.io>.
+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 <lu...@codecoup.pl> wrote:
>
> Hi,
>
> On 10 April 2017 at 18:15, will sanfilippo <wi...@runtime.io> 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 <sz...@codecoup.pl> 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
Posted by Łukasz Rymanowski <lu...@codecoup.pl>.
Hi,
On 10 April 2017 at 18:15, will sanfilippo <wi...@runtime.io> 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 <sz...@codecoup.pl> 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
Posted by will sanfilippo <wi...@runtime.io>.
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 <sz...@codecoup.pl> 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