Re: [SPECIFICATION RFC] The firmware and bootloader log specification

[James Courtier-Dutton <james.dutton@xxxxxxxxx>]

On Sat, 14 Nov 2020 at 12:37, Nico Huber <nico.h@xxxxxx> 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