subsys: settings: stream encoding

[nvlsianpu]

settings line is encoding directly by the settings module.

Signed-off-by: Andrzej Puzdrowski [email protected]

[Laczen]

@nvlsianpu, this is a big change to the settings module. I am uncertain if I completely understand the change. From the code I would conclude that the settings module would keep track of: name, value and also the address offset in flash. This way it can access the values quickly. Is this correct ?

[nvlsianpu]

Almost correct. 'Address offset' in an abstraction storage representation - this represent can be an offset in the flash_area as for FCB backend - it depends what is implemented under write_cb.

[Laczen]

Agreed, for file this will probably be an offset in the file. However what happens when you are rotating, then fcb has to update the settings ?

[Laczen]

@nvlsianpu, this change would make integrating NVS as a backend very easy. Address offset would become a item id for NVS, the settings_nvs part should just keep track of the next "address offset" to "distribute". The start of address offset could be set to 0x8000 and each new setting would get a new offset like 0x8001, 0x8002, ... I just need to think about how to handle deleted items (gaps in the list of address offset).

[Laczen]

@nvlsianpu, would it not be better to move the encoding to the back-end: fcb does not need encoding, file needs encoding, nvs does not need encoding, the communication layer to newtmgr needs encoding.

[nvlsianpu]

@jhedberg FYI - it is very early to look into - but line encoding sub-method is implemented.

[jhedberg]

I'm curious what kind of implications this has on the public API, since right now it seems you haven't touched it at all. The decoding part will also be tricky, I suppose, since you need a target buffer from the app, whereas with the current design set() is only called when a full value has been decoded.

[nvlsianpu]

@jhedberg For export handlers the int (*cb)(const char *name, char *value) callback will be changed to int (*cb)(const char *name, char *value, size_t value_length) - this callback will encode value so a value converting prior will be unnecessary.

For set handler I expect that 'char* val' will be replaced by a value_context + callback for fetching the value data ( something int read_cb(void* value_context, void *buf, size_t len). example:

u32_t val32;
char byte_array[32];
size_t array_cnt;

int c_handle_set(int argc, char **argv, void *value_context)
{
    int rc;

    if (argc == 1 && !strcmp(argv[0], "v")) {
        rc = read_cb(value_context, &val32, sizeof(val32));
        if  (rc == sizeof(val32)) {
            return 0;
        }
        
        return -EIO;
    }
    
    if (argc == 1 && !strcmp(argv[0], "s")) {
        rc = read_cb(value_context, byte_array, sizeof(byte_array));
        if  (rc > 0) {
            /* positive rc is equal to the result read size */
            array_cnt = rc;
            return 0;
        }
        
        return -EIO;
    }
    
    return -ENOENT;
}

[jhedberg]

@jhedberg For export handlers the int (*cb)(const char *name, char *value) callback will be changed to int (*cb)(const char *name, char *value, size_t value_length) - this callback will encode value so a value converting prior will be unnecessary.

Ok, good, however I suppose the "friendly" type (i.e. not requiring explicit type casts) would then be const void *value instead of char *value, right?

[nvlsianpu]

Right - I just typed this quickly.

[nvlsianpu]

upsteram PR zephyrproject-rtos#9521