[SPECIFICATION RFC] The firmware and bootloader log specification

[James Courtier-Dutton]

On Sat, 14 Nov 2020 at 12:37, Nico Huber <nico.h at gmx.de> wrote:

> > (I think
> >     newer spec versions should not change anything in first 5 bf_log
> members;
> >     this way older log parsers will be able to traverse/copy all logs
> regardless
> >     of version used in one log or another),
>
> Good point, which brings me to another good practice regarding such
> data formats: A length field for the header. In this case the length
> from the start of `bf_log` to the start of `msgs`. This would give
> us backwards compatibility in case additional fields are added in
> the future. And would also allow the various implementation to add
> custom fields (not for communication with log parser but for their
> own use).
>
> A fairly future proof approach is to use a TLV.
Type, Length, Value.
The approach can be nested, so other TLVs within the bytes of the value of
the parent TLV.
It makes it very easy for the reader of the message to skip any Types it
does not understand.
For example, the structure you describe could go in the "Value" part of the
TLV.
This is a common approach used by RADIUS, Protobuf, Avro etc.
If anyone wishes to add extra parameters, they can create a new Type, and
put the new parameters in the Value.
TLV is also already used elsewhere in the kernel, in the ALSA sound
interface to pass extra information about a sound control, e.g. dB values,
min/max values etc.

Kind Regards

James