maquefel подал не плохую мысль.
Действительно, если Вы начнёте писать статью по этой теме, то это даст хороший рост. Объяснить кому-то всегда сложнее, чем взять и сделать.
Я поэтому и начал писать про buildroot. Хорошая систематизация знаний и мозный стимул начать разбираться как следует
мой опыт:
1.roofs_overlay. Удобно когда нужно иметь файл гарантированного содержания. Который не поменяется с обновлением версий.Наглядно, понятно, новый в проекте человек сходу всё видит и понимает. Ну и порядок- сразу видно, какой файл куда попадёт.
2. Вариант со скриптами. Удобно, что можно прогнать sed/awk и внести изменения в любой конфиг, который может поменяться с обновлением пакета.Я тоже так делаю.
Насчет обновления buildroot, удобно хранить в external_tree свои наработки. Это избавляет лишней работы.
Насчет прав, есть механизм BR2_ROOTFS_DEVICE_TABLE. Он позвоялет создавать файлы( в тч устройств) с нужными правами.Можно менять права на имеющиеся файлы, насколько я понял. Детально ещё не пробовал с ним работать.
Обо всех этих механизмах в дальнейших статьях напишу. Две уже готовы, ещё 2 надо дописать.
В итоге я использую оба метода. Они оба хороши по-своему.
О создании полноценной конфигурации платы, external tree и прочем — в следующей статье. От простого с ложному.
Команды «save-update-defconfig» не существует. Наверно, имелось ввиду " make linux-update-defconfig"?
Скелет файловый системы — не хотелось бы путаницы со skeleton. Так-то output/target и не совсем скелет. Это файловая система, в которой отсутвуют только файлы устройств(/dev ) и не настроены правана файлы.
Действительно, если Вы начнёте писать статью по этой теме, то это даст хороший рост. Объяснить кому-то всегда сложнее, чем взять и сделать.
Я поэтому и начал писать про buildroot. Хорошая систематизация знаний и мозный стимул начать разбираться как следует
1.roofs_overlay. Удобно когда нужно иметь файл гарантированного содержания. Который не поменяется с обновлением версий.Наглядно, понятно, новый в проекте человек сходу всё видит и понимает. Ну и порядок- сразу видно, какой файл куда попадёт.
2. Вариант со скриптами. Удобно, что можно прогнать sed/awk и внести изменения в любой конфиг, который может поменяться с обновлением пакета.Я тоже так делаю.
Насчет обновления buildroot, удобно хранить в external_tree свои наработки. Это избавляет лишней работы.
Насчет прав, есть механизм BR2_ROOTFS_DEVICE_TABLE. Он позвоялет создавать файлы( в тч устройств) с нужными правами.Можно менять права на имеющиеся файлы, насколько я понял. Детально ещё не пробовал с ним работать.
Обо всех этих механизмах в дальнейших статьях напишу. Две уже готовы, ещё 2 надо дописать.
В итоге я использую оба метода. Они оба хороши по-своему.
Поправил, добавил использование команды linux-update-defconfig
Спасибо за комментарий.
Команды «save-update-defconfig» не существует. Наверно, имелось ввиду " make linux-update-defconfig"?
Скелет файловый системы — не хотелось бы путаницы со skeleton. Так-то output/target и не совсем скелет. Это файловая система, в которой отсутвуют только файлы устройств(/dev ) и не настроены правана файлы.