Здравствуйте, Marty, Вы писали:

M>Текстовый формат в любом случае не подходит. Различные подсистемы хотят на старте получить указатель на свою двоичную структуру, чтобы потом во время работы туда напрямую писать.
M>И конфиг хранится не во флеше, а епроме, там всего 16Кб

Так это тогда ни разу не "конфиг". RIFF (TLV) нормальный вариант, это работает десятилетиями, и проще сложно что-то придумать IMHO.

В тэг можно тип struct-а писать (StructX structY, etc), и номер ее версии например (X1, Y1, ну и т.п.)
Чтобы проще парсить, я бы запретил изменения, только дополнения блоков.

Т.е. "Y2" это "Y1" с дополнительными полями.
Тогда код код который парсит Y1 можно использовать для парсинга Y2 тоже.
А если нужно поменять поле в структуре, заводишь новое.
Но в принципе опционально, просто код который это парсит должен быть сложнее.

Здравствуйте, Marty, Вы писали:

M>Текстовый формат в любом случае не подходит. Различные подсистемы хотят на старте получить указатель на свою двоичную структуру, чтобы потом во время работы туда напрямую писать.
M>И конфиг хранится не во флеше, а епроме, там всего 16Кб

Так это тогда ни разу не "конфиг". RIFF (TLV) нормальный вариант, это работает десятилетиями, и проще сложно что-то придумать IMHO.

В тэг можно тип struct-а писать (StructX structY, etc), и номер ее версии например (X1, Y1, ну и т.п.)
Чтобы проще парсить, я бы запретил изменения, только дополнения блоков.

Т.е. "Y2" это "Y1" с дополнительными полями.
Тогда код код который парсит Y1 можно использовать для парсинга Y2 тоже.
А если нужно поменять поле в структуре, заводишь новое.
Но в принципе опционально, просто код который это парсит должен быть сложнее.

Длина блока там нужна чтобы перепрыгивать "неизвестные" блоки.
Т.е. код читающий конфиг должен читать только то что понимает, а что не понимает — пропускать до следующего заголовка.