Есть развесистые вложенные структуры. Хранится, допустим, просто в файле, как снимок памяти с корневой структурой. Всё структуры состоят из примитивных типов, вроде даже float'ов нет. Есть массивы, в тч и структур, исключительно фиксированного размера.
В любой новой версии софтины могут быть добавлены поля в какую-нибудь вложенную структуру, и, соответственно, вся двоичная раскладка поедет. Также поля могу быть удалены, перемещены, или переименованы.
В общем, такое вот, историческое легаси.
Требуется придумать какой-то механизм, который позволяет вычитать старую версию конфига, всё, что можно — перенести в новый конфиг, если чего-то в старом конфиге нет — установить значение по умолчанию.
Вроде бы, protobuf что-то умеет в версионность, но: нам нужно уметь для каждого поля любой структуры получить его смещение относительно начала файла, чтобы писать непоредственно по этому смещению.
Как вам такое?
ЗЫ Задача со звёздочкой — сделать на чистейшей сишечке.
ЗЫЫ Внешние инструменты не очень приветствуются, но можно попробовать написать что-то на питоне, и к питону наверное даже можно доустановить каких-то библиотек, помимо того, что идёт в базе, если это не слишком гемморно.
Здравствуйте, Marty, Вы писали:
M>Есть развесистые вложенные структуры. Хранится, допустим, просто в файле, как снимок памяти с корневой структурой. M>Требуется придумать какой-то механизм, который позволяет вычитать старую версию конфига, всё, что можно — перенести в новый конфиг, если чего-то в старом конфиге нет — установить значение по умолчанию.
Если снимок в памяти не имеет версии, придётся рядом ложить еще один файл с информацией о структуре или ссылку где можно эту информацию получить.
M>ЗЫ Задача со звёздочкой — сделать на чистейшей сишечке.
Дык написать можно на любом языке. Или вам надо уже готовое?
M>ЗЫЫ Внешние инструменты не очень приветствуются, но можно попробовать написать что-то на питоне, и к питону наверное даже можно доустановить каких-то библиотек, помимо того, что идёт в базе, если это не слишком гемморно.
Если надо на чистой сишечке, то нафиг питон используйте lua
Здравствуйте, kov_serg, Вы писали:
_>Если снимок в памяти не имеет версии, придётся рядом ложить еще один файл с информацией о структуре или ссылку где можно эту информацию получить.
Гениально
Осталось придумать, что и как хранить в метаданных, и как это описать, очень желательно не описать и нагенерить новое, а описать на базе существующего.
И да, никаких json/yaml и тп, у нас памяти всего несколько десятков килобайт на всю программу.
M>>ЗЫ Задача со звёздочкой — сделать на чистейшей сишечке. _>Дык написать можно на любом языке. Или вам надо уже готовое?
Лучше готовое, но можно и просто идей.
M>>ЗЫЫ Внешние инструменты не очень приветствуются, но можно попробовать написать что-то на питоне, и к питону наверное даже можно доустановить каких-то библиотек, помимо того, что идёт в базе, если это не слишком гемморно. _>Если надо на чистой сишечке, то нафиг питон используйте lua
Питон уже используется, и все скажут, что нафик ещё что-то в проект присовывать
Здравствуйте, Marty, Вы писали:
M>В любой новой версии софтины могут быть добавлены поля в какую-нибудь вложенную структуру, и, соответственно, вся двоичная раскладка поедет. Также поля могу быть удалены, перемещены, или переименованы.
Хорошо иметь семантику полей, определенную таким образом, что пропущенное поле автоматически имеет разумное дефолтное значение.
M>Требуется придумать какой-то механизм, который позволяет вычитать старую версию конфига, всё, что можно — перенести в новый конфиг, если чего-то в старом конфиге нет — установить значение по умолчанию.
JSON?
M>Вроде бы, protobuf что-то умеет в версионность, но: нам нужно уметь для каждого поля любой структуры получить его смещение относительно начала файла, чтобы писать непоредственно по этому смещению.
У вас там НАСТОЛЬКО памяти мало, что надо уметь всё делать in place?
IMHO, сам код protobuf сожрёт больше памяти, чем сэкономит на данных.
M>ЗЫ Задача со звёздочкой — сделать на чистейшей сишечке.
Ну мы ж не будем тебе прям тут код писать, так что какая разница, какой язык обсуждать?
Здравствуйте, Pzz, Вы писали:
M>>В любой новой версии софтины могут быть добавлены поля в какую-нибудь вложенную структуру, и, соответственно, вся двоичная раскладка поедет. Также поля могу быть удалены, перемещены, или переименованы.
Pzz>Хорошо иметь семантику полей, определенную таким образом, что пропущенное поле автоматически имеет разумное дефолтное значение.
Хорошо там, где нас нет
M>>Требуется придумать какой-то механизм, который позволяет вычитать старую версию конфига, всё, что можно — перенести в новый конфиг, если чего-то в старом конфиге нет — установить значение по умолчанию.
Pzz>JSON?
Нет конечно
M>>Вроде бы, protobuf что-то умеет в версионность, но: нам нужно уметь для каждого поля любой структуры получить его смещение относительно начала файла, чтобы писать непоредственно по этому смещению.
Pzz>У вас там НАСТОЛЬКО памяти мало, что надо уметь всё делать in place?
Миикроконтроллер
Pzz>IMHO, сам код protobuf сожрёт больше памяти, чем сэкономит на данных.
M>>ЗЫ Задача со звёздочкой — сделать на чистейшей сишечке.
Pzz>Ну мы ж не будем тебе прям тут код писать, так что какая разница, какой язык обсуждать?
Разница большая.
На плюсах можно написать библиотеку так, что кучу черной работы она будет делать незаметно для пользователя, сведя к минимуму пользовательские телодвижения.
Хотелось бы:
1) Идей, как вообще это сделать в условиях ограниченных ресурсов
2) Идей, как это сделать на плюсах
3) Идей, как плюсовую магию повторить на сишечке, или, хотя бы, жалкое подобие сделать. По этому пункту на самом деле решение может быть совсем не таким, как на плюсах, с учетом убогих возможностей сишечки.
Здравствуйте, Marty, Вы писали:
Pzz>>JSON?
M>Нет конечно
Почему?
Бывают бинарные форматы, по сути своей близкие к JSON-у. JSON, кстати, весьма компактен, если в одну строчку и без незначимых пробелов.
Pzz>>У вас там НАСТОЛЬКО памяти мало, что надо уметь всё делать in place?
M>Миикроконтроллер
Слушай, я вписывал полноценный стек TCP в резидент под DOS. Это десятка полтора K кода, и под пакеты я завёл себе 8К.
Мииии — это когда тебе обещали 128 байт памяти данных, а оказалось, что их там только 64, а ты, дурак, поленился вовремя проверить, и стек после буквально пары-тройки вложенных вызовов наехал на твои три с половиной статические переменные. И ты с изумлением узнаёшь, что gcc для AVR-ки стремится использовать все доступные регистры, и все их сохраняет в стеке при каждом вызове, сука. Потому, что у тебе нет столько стека, а регистров у AVR-ки много.
А десятки килобайт — это уже норм. Есть, где развернуться.
M>Хотелось бы: M>1) Идей, как вообще это сделать в условиях ограниченных ресурсов
Pzz>Бывают бинарные форматы, по сути своей близкие к JSON-у. JSON, кстати, весьма компактен, если в одну строчку и без незначимых пробелов.
А кто разбор будет этого, пусть и бинарного, JSON? Ну, допустим, пять килобайт, пусть даже десять, под либу выделить можно. Что влезет в эти десять килобайт?
Pzz>>>У вас там НАСТОЛЬКО памяти мало, что надо уметь всё делать in place?
M>>Миикроконтроллер
Pzz>Слушай, я вписывал полноценный стек TCP в резидент под DOS. Это десятка полтора K кода, и под пакеты я завёл себе 8К.
Я писал HTTP-сервер на Turbo C, на TCP-стеке, который кем-то написал до меня, под 186ой процессор. Но я не хочу потратить несколько месяцев на сабжевую задачу.
Pzz>Мииии — это когда тебе обещали 128 байт памяти данных, а оказалось, что их там только 64, а ты, дурак, поленился вовремя проверить, и стек после буквально пары-тройки вложенных вызовов наехал на твои три с половиной статические переменные. И ты с изумлением узнаёшь, что gcc для AVR-ки стремится использовать все доступные регистры, и все их сохраняет в стеке при каждом вызове, сука. Потому, что у тебе нет столько стека, а регистров у AVR-ки много.
Pzz>А десятки килобайт — это уже норм. Есть, где развернуться.
Или нет. Железяка тащит на себе дофига задач, будет развиваться, будут новые задачи. Просто так местом разбрасываться не стоит. Если бы работа с конфигом была единствекнной задачей, то это да, можно себе ни в чем не отказывать... Но это просто задача по облегчению текущей жизни, тут надо балансировать между местом, которое займет решение, и удобством использования, и насколько решение облегчит жизнь.
M>>Хотелось бы: M>>1) Идей, как вообще это сделать в условиях ограниченных ресурсов
Pzz>Как бинарный JSON.
Ну, хотелось бы более конкретных идей. При чем тут бинарный JSON, кстати, не очень понятно. Зачем вообще ориентироваться на какой-то существующий формат, если всё равно либо для его обработки с высокой степенью вероятности будет не втащить в проект?
Ну и "бинарный JSON" — это как-то не ответ. Хоть бинарный SQL. Он ничего не говорит, что хранить в этом бинарном JSON/SQL.
Здравствуйте, Marty, Вы писали:
M>Гениально M>Осталось придумать, что и как хранить в метаданных, и как это описать, очень желательно не описать и нагенерить новое, а описать на базе существующего.
Тогда храни аля RIFF, LBM
TAG,SIZE [DATA]
Или asn.1
M>И да, никаких json/yaml и тп, у нас памяти всего несколько десятков килобайт на всю программу.
Фигасе и питон помещается?
Вам никто не мешает хранить метаданные например в kaitai на github
А версию указывать как url ссылку на используемую версию
M>Лучше готовое, но можно и просто идей.
Идея простая представь данные в самоописывающемся формате
M>Питон уже используется, и все скажут, что нафик ещё что-то в проект присовывать
lua это чистый C ~ 300кб. А python это лютый оверхед и потом еще и геморой с совместимостью на платформах которые питон не желает поддерживать.
Здравствуйте, Marty, Вы писали:
Pzz>>Бывают бинарные форматы, по сути своей близкие к JSON-у. JSON, кстати, весьма компактен, если в одну строчку и без незначимых пробелов.
M>А кто разбор будет этого, пусть и бинарного, JSON? Ну, допустим, пять килобайт, пусть даже десять, под либу выделить можно. Что влезет в эти десять килобайт?
Ну, например, ты
Чего там париться, это работы на 1-2 дня. Ну или библиотеку готовую найди.
M>Или нет. Железяка тащит на себе дофига задач, будет развиваться, будут новые задачи. Просто так местом разбрасываться не стоит. Если бы работа с конфигом была единствекнной задачей, то это да, можно себе ни в чем не отказывать... Но это просто задача по облегчению текущей жизни, тут надо балансировать между местом, которое займет решение, и удобством использования, и насколько решение облегчит жизнь.
Конфиг — важная вещь. Вы потом потонете, когда у вас будет с десяток разных релизов и не будет никакой совместимости между конфигами.
Pzz>>Как бинарный JSON.
M>Ну, хотелось бы более конкретных идей. При чем тут бинарный JSON, кстати, не очень понятно. Зачем вообще ориентироваться на какой-то существующий формат, если всё равно либо для его обработки с высокой степенью вероятности будет не втащить в проект?
Я имею ввиду, идею JSON-а: именованные, немного типизованные атрибуты, поддержка массивов и вложенных объектов.
Такой формат легко расширяется просто путём добавления новых аттрибутов.
Здравствуйте, DiPaolo, Вы писали:
DP>Как вариант – такое https://kaitai.io
Не кажется хорошим вариантом:
1) Не умеет генерить в сишечку
2) Надо описывать структуры на этом языке, а не описывать существующие. У меня структуры описаны в сишечном хидере и в зависимости от разных дефайнов, которые задаются для проекта, поля многих структур определяются по разному, и могут вообще отсутствовать
3) Как я понял, в двоичную структуру он (де)сериализует, постоянно сериализовать всю здоровую структуру — совсем не вариант, разные части софта хотят писать в конкретные места, и очень часто, на сериализации всё умрёт.
4) Для сериализации используются плюсовые потоки. Даже если бы у меня были плюсы, потоков у меня всё равно бы не было.
DP>Ну и неясно, почему нельзя просто задефайнить структуру и читать ее прямо из памяти? Ну и разруливать разные версии ифами.
Что значит — нельзя? Именно так сейчас оно и сделано. И это боль. Проблема возникает при смене версии структур данных — когда в структурах что-то удаляется/добавляется/меняется. Новый софт должен уметь считать старую структуру и сконвертировать её в новую.
DP>Окей, можно просто парсер свой написать, типа как для всяких протоколов/спецификаций.
Можно. Есть какие-нибудь идеи?
DP>Ты б хоть привел пример структур своих. А то не очень понятно, в чем сложность
Да обычные плоские структуры данных, с накопленными значениями всякой телеметрии
Да хоть бы как BMP-шные — https://formats.kaitai.io/bmp/
Представь, что раз в несколько месяцев они меняются, что-то вставляется, что-то удаляется или переезжает. И нет никаких полей, в которых лежит номер версии конкретной подструктуры, чтобы всякими if'ами в коде проверять (да и никто не будет имеющийся код дорабатывать, если что-то понадобилось — просто фигачат новое поле, а о совместимости со старой версией никто не думает).
Здравствуйте, kov_serg, Вы писали:
M>>Гениально M>>Осталось придумать, что и как хранить в метаданных, и как это описать, очень желательно не описать и нагенерить новое, а описать на базе существующего. _>Тогда храни аля RIFF, LBM _>TAG,SIZE [DATA]
А TAG — что там?
Интересны как раз не общие рассуждения, а более конкретные мысли, как поступить в ситуации с существующими ограничениями
_>Или asn.1
M>>И да, никаких json/yaml и тп, у нас памяти всего несколько десятков килобайт на всю программу. _>Фигасе и питон помещается?
Нет, конечно, питон используется при сборке зачем-то, и если пилить какую-то тулзу самому, которая подготавливает метаданные для устройства, то лучше на питоне
_>Вам никто не мешает хранить метаданные например в kaitai на github _>А версию указывать как url ссылку на используемую версию
И как это мне поможет?
M>>Лучше готовое, но можно и просто идей. _>Идея простая представь данные в самоописывающемся формате
Но приходится работать с тем, что есть
M>>Питон уже используется, и все скажут, что нафик ещё что-то в проект присовывать _>lua это чистый C ~ 300кб. А python это лютый оверхед и потом еще и геморой с совместимостью на платформах которые питон не желает поддерживать.
Тут не в размере дело. В любом случае, у меня в девайсе 256 Кб вообще на всё, если не меньше.
На питоне можно попробовать написать что-то вспомогательное для сборки, потому что он уже используется, и некоторые в команде с ним работали. Луа присунуть даже в сборку никто не даст.
Здравствуйте, Pzz, Вы писали:
Pzz>>>Бывают бинарные форматы, по сути своей близкие к JSON-у. JSON, кстати, весьма компактен, если в одну строчку и без незначимых пробелов.
M>>А кто разбор будет этого, пусть и бинарного, JSON? Ну, допустим, пять килобайт, пусть даже десять, под либу выделить можно. Что влезет в эти десять килобайт?
Pzz>Ну, например, ты
Pzz>Чего там париться, это работы на 1-2 дня. Ну или библиотеку готовую найди.
Или не на два дня, если соответствовать спеке какой-нибудь официальной. Библиотека — легко может быть, что размер будет недопустимо большой. И, скорее всего, будет использовать динамическую память. Всё, это сразу нет.
Суть вопроса не в том, в каком формате хранить, можно своё наколбасить. А что хранить, и как это использовать для конвертации между версиями конфигов
M>>Или нет. Железяка тащит на себе дофига задач, будет развиваться, будут новые задачи. Просто так местом разбрасываться не стоит. Если бы работа с конфигом была единствекнной задачей, то это да, можно себе ни в чем не отказывать... Но это просто задача по облегчению текущей жизни, тут надо балансировать между местом, которое займет решение, и удобством использования, и насколько решение облегчит жизнь.
Pzz>Конфиг — важная вещь. Вы потом потонете, когда у вас будет с десяток разных релизов и не будет никакой совместимости между конфигами.
Потонете, хаха. Уже буль-буль. Этому легаси не первый год, и, возможно, не первый даже десяток лет. Уже два с лишним десятка версий, и для каждой вручный с болью написанный конвертер. Поэтому и есть желание это как-то сделать не так больно, но расхреначивать существующую системы и переделывать всё с нуля никто не даст. В том числе и потому, что сишечка. Если плюсы просто не скомпилировали бы, сишечка кушает и причмокивает.
Pzz>Я имею ввиду, идею JSON-а: именованные, немного типизованные атрибуты, поддержка массивов и вложенных объектов.
Pzz>Такой формат легко расширяется просто путём добавления новых аттрибутов.
Здравствуйте, Marty, Вы писали:
_>>Тогда храни аля RIFF, LBM _>>TAG,SIZE [DATA]
M>А TAG — что там?
Тип блока данных. Тэг по которому программа узнает что там. RIFF в прошлом веке был очень популярным: дёшево и сердито. Есть в Вики, или любого бота спроси он объяснит что это такое.
Ещё можно версию структуры хранить вместе с размером, а в твоём коде уже разбираться. Микрософт так сто лет делает, правда они в основном добавляют поля, в этом случае меньше мороки и безопаснее это.
Сам tag может быть индикатором типа (ну там, int/string) или идентификатором атрибута.
_>>Вам никто не мешает хранить метаданные например в kaitai на github _>>А версию указывать как url ссылку на используемую версию
M>И как это мне поможет?
Это товарищь XML, наверное, начитался. В XML URL используется, как идентификатор namespace (при этом маловероятно, чтобы по этому URL-ю что-то осмысленное находилось). URL хорош тем, что можно добиться его глобально-уникальности без централизованного выделения.
Но тебе это никак не поможет.
M>Тут не в размере дело. В любом случае, у меня в девайсе 256 Кб вообще на всё, если не меньше.
Богатая железка. 256 Кб — совсем не мало. CM-4 имело 256 Кб, и тянула на себе целых класс студентов, которые чего-то там учились программировать на Фортране.
Да, я куда-то в эту сторону тоже думаю. Но за ссылку — спс, не знал, как это называется
Pzz>Сам tag может быть индикатором типа (ну там, int/string) или идентификатором атрибута.
Угу, тоже так думаю
M>>Тут не в размере дело. В любом случае, у меня в девайсе 256 Кб вообще на всё, если не меньше.
Pzz>Богатая железка. 256 Кб — совсем не мало. CM-4 имело 256 Кб, и тянула на себе целых класс студентов, которые чего-то там учились программировать на Фортране.
Я условно сказал. Железка такая: RISC-V К1986ВУ024 (NRTS32M)
Нашел его в инете. Памяти программ там даже 512, но там ППЦ сколько он тащит
32-битное ядро RISC-V (тип N308)
Максимальная рабочая частота 144 МГц
Операции с плавающей точкой
DSP-инструкции
512 КБ флэш-памяти
144 КБ ОЗУ
4 АЦП (12 бит с частотой 5 МВыб/сек)
4 операционных усилителя
7 компараторов
2 ЦАП (12 бит с частотой 1 МВ/сек)
UART, I2C, SPI, QSPI, CAN
Здравствуйте, Marty, Вы писали:
M>А TAG — что там? M>Интересны как раз не общие рассуждения, а более конкретные мысли, как поступить в ситуации с существующими ограничениями
Всё очень просто TAG это уникальный идентификатор типа данных, длинна это длинна значения (если не умеет просто может скипнуть)
И да можно кодировать не фиксированной длинной (особенно если мало памяти) хоть побитно.
_>>Или asn.1 M>
На самом деле там такая же схема, просто моного лишнего.
M>>>И да, никаких json/yaml и тп, у нас памяти всего несколько десятков килобайт на всю программу. _>>Фигасе и питон помещается?
И что? Это более чем достаточно в ZX Spectrum было 48Кб и было норм
В некоторых контроллерах вообще десятки байт RAM
M>Нет, конечно, питон используется при сборке зачем-то, и если пилить какую-то тулзу самому, которая подготавливает метаданные для устройства, то лучше на питоне
Так ишо? Кто мешает еще м lua добавить, причем собрав из исходников.
_>>Вам никто не мешает хранить метаданные например в kaitai на github _>>А версию указывать как url ссылку на используемую версию M>И как это мне поможет?
Очень просто в начале храните номер версии или url ссылку или её часть или её-hash. По этим данным можете получить из своего хранилища полную информацию о строение файла или даже сам сериализатор.
Зависит от вашей фантазии.
M>>>Лучше готовое, но можно и просто идей. _>>Идея простая представь данные в самоописывающемся формате M>Но приходится работать с тем, что есть
Тогда внешний описатель или ссылка на него.
M>Тут не в размере дело. В любом случае, у меня в девайсе 256 Кб вообще на всё, если не меньше.
Так не надо это делать в контроллере. Вы можете получать конфиг и преобразовать его в заданный. Если это возможно :-P
M>На питоне можно попробовать написать что-то вспомогательное для сборки, потому что он уже используется, и некоторые в команде с ним работали. Луа присунуть даже в сборку никто не даст.
И очень зря. тогда perl
Здравствуйте, kov_serg, Вы писали:
M>>А TAG — что там? M>>Интересны как раз не общие рассуждения, а более конкретные мысли, как поступить в ситуации с существующими ограничениями _>Всё очень просто TAG это уникальный идентификатор типа данных, длинна это длинна значения (если не умеет просто может скипнуть) _>И да можно кодировать не фиксированной длинной (особенно если мало памяти) хоть побитно.
Это-то понятно. Я вот думаю, ну окей, базовым типам я захардкожу тэги, а как быть со структурами? Там хардкодить не хочется, думаю, может как-то генерить на базе имени
M>>Нет, конечно, питон используется при сборке зачем-то, и если пилить какую-то тулзу самому, которая подготавливает метаданные для устройства, то лучше на питоне _>Так ишо? Кто мешает еще м lua добавить, причем собрав из исходников.
И то. Никто зоопарк разводить не будет
M>>И как это мне поможет? _>Очень просто в начале храните номер версии или url ссылку или её часть или её-hash.
Это решает только задачу сравнения версий на эквивалентность, и всё
_>По этим данным можете получить из своего хранилища полную информацию о строение файла или даже сам сериализатор. _>Зависит от вашей фантазии.
Сериализатор надо сделать. В этом задача. И не просто сериализатор, а мигратор
M>>Тут не в размере дело. В любом случае, у меня в девайсе 256 Кб вообще на всё, если не меньше. _>Так не надо это делать в контроллере. Вы можете получать конфиг и преобразовать его в заданный. Если это возможно :-P
Это не возможно. Конфиг не должен покидать устройство
M>>На питоне можно попробовать написать что-то вспомогательное для сборки, потому что он уже используется, и некоторые в команде с ним работали. Луа присунуть даже в сборку никто не даст. _>И очень зря. тогда perl
Pzz>>Конфиг — важная вещь. Вы потом потонете, когда у вас будет с десяток разных релизов и не будет никакой совместимости между конфигами.
M>Потонете, хаха. Уже буль-буль. Этому легаси не первый год, и, возможно, не первый даже десяток лет. Уже два с лишним десятка версий, и для каждой вручный с болью написанный конвертер. Поэтому и есть желание это как-то сделать не так больно, но расхреначивать существующую системы и переделывать всё с нуля никто не даст. В том числе и потому, что сишечка. Если плюсы просто не скомпилировали бы, сишечка кушает и причмокивает.
А в чём проблема с конверторами? Я примерно так версионность конфигов и делал. Правда формат был XML, а не бинарный, но подход от этого не меняется.
У каждой структуры есть версия (я в namespace ее вписывал), соответственно версия конфига определяет версии всех внутренних структур.
Вместе с новой версией конфига добавляется конвертер из предыдущей. Т.о. можно прочитать из любой старой версии в последнюю.
Единственное неудобство, что новая версия любой внутренней структуры требует подъема версии структур ее включающих.
Ну и все предыдущие версии структур должны присутсвовать в коде.
И я исхожу из того, что алгоритм конвертации в новою версию должен явным образом описываться разработчиком.
