Generic logging utilities

[yevagorbachev]

Utilities to conveniently use non-volatile storage for configs and logged data

Minimally,

• add data to file
• read back file
• hide filesystem initialization

Additionally,

• file data
• file size limiting
• non-volatile key-value
• active filesystem backend for logging

Function standards

• Each function should be prefixed with l (L as in Launch). Allows us to distinguish which functions we wrote ourselves vs Zephyr functions (which normally uses k in most cases). This goes for all core library functions
• Every function should return an integer. These would normally be status values from Zephyr itself and it would be good to propogate those errors up. Positive values (or 0) normally signify successful values so no issues with this for things like get_entry_size
• Log errors within the function. State what operation failed and the Zephyr errno code (return value). Can reference these values in Zephyr documentation

[yevagorbachev]

Should more be "utilities"

[yevagorbachev]

Description to follow from @AarC10

[AarC10]

Most functionality should be straightforward in Zephyr it seems that utilities may not need to be as comprehensive based on https://docs.zephyrproject.org/latest/services/file_system/index.html but that is TBD. Don't have enough experience with Zephyr file system library to be completely specific. Should also confirm if the filesystem does the caching and buffering for you.

Some good helper functions to to include would be along these lines

• Initializing the filesystem (any setup that needs to be done to get it to work in the first place)
• write (open file with write and append mode) - Need to evaluate whether if we should open/close on every write, keep it open until we flush periodically and then close when we want, etc. Could also have boolean arguments and multiple functions for doing both. Give the user multiple options. (see device_utils for similar flexibility)
• read - Should specify the offset to read from as well and open with correct flags
• get_entry_size - Gets a file/directory size using fs_readdir and returning the struct value that gets modified specifying size

Function Requirements

• Each function should be prefixed with l (L as in Launch). Allows us to distinguish which functions we wrote ourselves vs Zephyr functions (which normally uses k in most cases). This goes for all core library functions
• Every function should return an integer. These would normally be status values from Zephyr itself and it would be good to propogate those errors up. Positive values (or 0) normally signify successful values so no issues with this for things like get_entry_size
• Log errors within the function. State what operation failed and the Zephyr errno code (return value). Can reference these values in Zephyr documentation

[yevagorbachev]

Helpers

• Initalizing is actually done automatically based on the automount devicetree flag. I think init would be good, to check that automount worked and take care of making new files. Probably, it will look like a struct logfile that has some extra information.
• makes sense
• makes sense
• makes sense

Functions

• makes sense, I like this idea
• makes sense
• might be good to make sure the same error isn't logged at high frequency and clog the file

Do you care if I use a C++ class for this?

[yevagorbachev]

Minimum working example on feature/Yev/lfs-utils. I'm using C++ instead because otherwise there is not really much to improve on the VFS API (without hackily re-creating objects using the PASTE2 pattern Zephyr seems to like).