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