You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Jacob Rosenthal <ja...@gmail.com> on 2017/02/21 17:34:53 UTC

Config id package

Im trying to build a DIS service with identification strings like bsp and
app name from config/id package with conf_get_value

I think Im using the api correctly?

    char *val;
    int rc;
    uint16_t uuid16;
    char tmp_buf[32 + 1]; ///hwid is only one that needs some tmp buffer

    if(ctxt->op != BLE_GATT_ACCESS_OP_READ_CHR)
    {
        return BLE_ATT_ERR_UNLIKELY;
    }
    uuid16 = ble_uuid_u16(ctxt->chr->uuid);
    assert(uuid16 != 0);

    switch (uuid16) {
        case BLE_SVC_DIS_CHR_SYS_ID_UUID16:
            val = conf_get_value("id/hwid", tmp_buf, sizeof(tmp_buf));
            console_printf("hwid %s\n", val);
            rc = os_mbuf_append(ctxt->om, val, strlen(val));
            return rc == 0 ? 0 : BLE_ATT_ERR_INSUFFICIENT_RES;

But I cant seem to get anything other than a empty string at runtime...

Are there any syscfg configurations that I need, or need to make sure I
dont disable?

.. Oddly enough this works in gdb ???

set $foo = conf_get_value("id/app", (void *)0, 0)
p $foo
$1 = 0x2215f "bleprph"


So Im super lost :)

Re: Config id package

Posted by marko kiiskila <ma...@runtime.io>.
> On Feb 21, 2017, at 11:45 AM, Christopher Collins <ch...@runtime.io> wrote:
> 
> On Tue, Feb 21, 2017 at 11:35:53AM -0800, marko kiiskila wrote:
> [conf_get_value()]
>> Note that this routine was not meant to be exported, but if it’s useful,
>> we should continue doing that :)
> 
> Is there a preferred method of reading a config var?

The plan was to have config stay within the package which owns the
variable. If you need config from other package, you’d ask for it
with an API call to that package.

I.e. names used for config variables were not meant to be part
of package API.
—
M


Re: Config id package

Posted by Christopher Collins <ch...@runtime.io>.
On Tue, Feb 21, 2017 at 11:35:53AM -0800, marko kiiskila wrote:
[conf_get_value()]
> Note that this routine was not meant to be exported, but if it\u2019s useful,
> we should continue doing that :)

Is there a preferred method of reading a config var?

Chris

Re: Config id package

Posted by marko kiiskila <ma...@runtime.io>.
> On Feb 21, 2017, at 10:10 AM, Christopher Collins <ch...@runtime.io> wrote:
> 
> Hi Jacob,
> 
> On Tue, Feb 21, 2017 at 10:34:53AM -0700, Jacob Rosenthal wrote:
>> Im trying to build a DIS service with identification strings like bsp and
>> app name from config/id package with conf_get_value
>> 
>> I think Im using the api correctly?
>> 
>>    char *val;
>>    int rc;
>>    uint16_t uuid16;
>>    char tmp_buf[32 + 1]; ///hwid is only one that needs some tmp buffer
>> 
>>    if(ctxt->op != BLE_GATT_ACCESS_OP_READ_CHR)
>>    {
>>        return BLE_ATT_ERR_UNLIKELY;
>>    }
>>    uuid16 = ble_uuid_u16(ctxt->chr->uuid);
>>    assert(uuid16 != 0);
>> 
>>    switch (uuid16) {
>>        case BLE_SVC_DIS_CHR_SYS_ID_UUID16:
>>            val = conf_get_value("id/hwid", tmp_buf, sizeof(tmp_buf));
>>            console_printf("hwid %s\n", val);
>>            rc = os_mbuf_append(ctxt->om, val, strlen(val));
>>            return rc == 0 ? 0 : BLE_ATT_ERR_INSUFFICIENT_RES;
>> 
>> But I cant seem to get anything other than a empty string at runtime...
> [...]
> 
> This is indeed a bummer.  The problem is that the conf_get_value()
> function expects the setting name to be a mutable string.  String
> literals (e.g., "id/hwid") are constant, and cause the setting lookup to
> fail.  The reason the name needs to be mutable is that the lookup
> routine calls strtok_r on the string, which replaces instances of '/'
> with \0.
> 
> Anyway, the immediate fix is to put the setting name in a char array,
> rather than pass a string literal to conf_get_value().  For example:
> 
>    char conf_name[] = "id/hwid";
> 
>    val = conf_get_value(conf_name, tmp_buf, sizeof(tmp_buf));
> 
> In my view, this aspect of the conf API isn't particularly obvious.  We
> should either change the API such that it works with constant strings or
> clearly document this requirement.
> 

Note that this routine was not meant to be exported, but if it’s useful,
we should continue doing that :)

We could add another routine which makes a copy of the conf_name,
and then does the operation. As well as for setting a value.



Re: Config id package

Posted by Christopher Collins <ch...@runtime.io>.
Hi Jacob,

On Tue, Feb 21, 2017 at 10:34:53AM -0700, Jacob Rosenthal wrote:
> Im trying to build a DIS service with identification strings like bsp and
> app name from config/id package with conf_get_value
> 
> I think Im using the api correctly?
> 
>     char *val;
>     int rc;
>     uint16_t uuid16;
>     char tmp_buf[32 + 1]; ///hwid is only one that needs some tmp buffer
> 
>     if(ctxt->op != BLE_GATT_ACCESS_OP_READ_CHR)
>     {
>         return BLE_ATT_ERR_UNLIKELY;
>     }
>     uuid16 = ble_uuid_u16(ctxt->chr->uuid);
>     assert(uuid16 != 0);
> 
>     switch (uuid16) {
>         case BLE_SVC_DIS_CHR_SYS_ID_UUID16:
>             val = conf_get_value("id/hwid", tmp_buf, sizeof(tmp_buf));
>             console_printf("hwid %s\n", val);
>             rc = os_mbuf_append(ctxt->om, val, strlen(val));
>             return rc == 0 ? 0 : BLE_ATT_ERR_INSUFFICIENT_RES;
> 
> But I cant seem to get anything other than a empty string at runtime...
[...]

This is indeed a bummer.  The problem is that the conf_get_value()
function expects the setting name to be a mutable string.  String
literals (e.g., "id/hwid") are constant, and cause the setting lookup to
fail.  The reason the name needs to be mutable is that the lookup
routine calls strtok_r on the string, which replaces instances of '/'
with \0.

Anyway, the immediate fix is to put the setting name in a char array,
rather than pass a string literal to conf_get_value().  For example:

    char conf_name[] = "id/hwid";

    val = conf_get_value(conf_name, tmp_buf, sizeof(tmp_buf));

In my view, this aspect of the conf API isn't particularly obvious.  We
should either change the API such that it works with constant strings or
clearly document this requirement.

Chris