Serhii Sakhno будет жить. Поприветствуем!

Оно? https://m.habr.com/post/322592/

ага

Mikhail Mironov будет жить. Поприветствуем!

Mikhail Mironov будет жить. Поприветствуем!

привет

Подскажите, а вот если я хочу иметь свой сборочный велосипед, который берёт всякие тэги кернелов/билдрутов/юбутов, а потом патчит, то как удобно эти патчи генерить/прикладывать? Смысле, обясню кейс: для бубута того же у меня щас лежит в общей сложности патчей 8, которые никак не пересекаются, и я при сборке через git apply -R --check проверяю, наложены ли все эти патчи по принципу "еси они намана отменились — значит, никаких лишних правок тут нет". А вот упиздил с вендора патчи для ядра — их там штук 40, и шота с ними такой фокус не работает. Плюс не очень удобно потом генерить новые патчи, если ничего не коммиттить (тут я узрел git am в вендор-фреймворке, это легальный способ для поддержания своего зоопарка или как?).

посмотри как openwrt сделали

посмотри как openwrt сделали

Дык там по факту тоже самое, есть какая-то версия от апстрима, и потом просто patch на сорцы ...

и вроде отмечаются применённые, или меня уже глючит

Ну вот про отмечание я думал. В первой версии велосипеда был просто patch.history файл или кайнд оф, в котором тупо строчки названий лежали. Но после того, как кто-то повадился редактировать патчи.. да ещё и руками.. шота не нравится мне больше такой способ. х)

(если я верно понял это твоё "отмечаются")

угу

Подскажите, а вот если я хочу иметь свой сборочный велосипед, который берёт всякие тэги кернелов/билдрутов/юбутов, а потом патчит, то как удобно эти патчи генерить/прикладывать? Смысле, обясню кейс: для бубута того же у меня щас лежит в общей сложности патчей 8, которые никак не пересекаются, и я при сборке через git apply -R --check проверяю, наложены ли все эти патчи по принципу "еси они намана отменились — значит, никаких лишних правок тут нет". А вот упиздил с вендора патчи для ядра — их там штук 40, и шота с ними такой фокус не работает. Плюс не очень удобно потом генерить новые патчи, если ничего не коммиттить (тут я узрел git am в вендор-фреймворке, это легальный способ для поддержания своего зоопарка или как?).

Но зачем ты хочешь свой велосипед?

Но зачем ты хочешь свой велосипед?

Изначально моя мотивация была в том, что я не знаю, как сделать сущестующими инструментами правильно, так что лучше я нагорожу под конкретный проект конкретных костылей. А именно — мне нужно было в одном месте генерить все образы, пихать нужные мне скрипты и вообще учитывать зависимость одних образов от других.

Короче, одной кнопкой понадрать из всех кусков проекта шо мне нужно и получить деплоибл бинари.

Подскажите, а вот если я хочу иметь свой сборочный велосипед, который берёт всякие тэги кернелов/билдрутов/юбутов, а потом патчит, то как удобно эти патчи генерить/прикладывать? Смысле, обясню кейс: для бубута того же у меня щас лежит в общей сложности патчей 8, которые никак не пересекаются, и я при сборке через git apply -R --check проверяю, наложены ли все эти патчи по принципу "еси они намана отменились — значит, никаких лишних правок тут нет". А вот упиздил с вендора патчи для ядра — их там штук 40, и шота с ними такой фокус не работает. Плюс не очень удобно потом генерить новые патчи, если ничего не коммиттить (тут я узрел git am в вендор-фреймворке, это легальный способ для поддержания своего зоопарка или как?).

git am это охуенный способ.

Изначально моя мотивация была в том, что я не знаю, как сделать сущестующими инструментами правильно, так что лучше я нагорожу под конкретный проект конкретных костылей. А именно — мне нужно было в одном месте генерить все образы, пихать нужные мне скрипты и вообще учитывать зависимость одних образов от других.

ну я показывал картинку...

правильно это взять йокту

git am это охуенный способ.

А там как-то можно проверять, изменились ли патчи?

А там как-то можно проверять, изменились ли патчи?

Ты хочешь при каждом мейке перенакладывать изменённые патчи и пересобирать софт?

А там как-то можно проверять, изменились ли патчи?

всмысле? - делаешь бранч1, накладываешь патчи - делаешь бранч2, накладываешь другие патчи - git diff branch1 branch2

то есть мне нахрен не понятно накой хрен возиться с патчами если можно держать гитрепу

но если хочется извращений, то есть quilt

всмысле? - делаешь бранч1, накладываешь патчи - делаешь бранч2, накладываешь другие патчи - git diff branch1 branch2

для каждого девайса или вендора по ветке?

Я догадываюсь, что он хочет иметь *.patch’и для разного софта в одной репе, которые будут при сборке софта накладываться.

Я догадываюсь, что он хочет иметь *.patch’и для разного софта в одной репе, которые будут при сборке софта накладываться.

+

но при обилии вендоров и патчей, от разбора ручками и вникания в чудокод особо не уйти.

И при изменении самих *.patch'ей он хочет перенакладывать их и не с нуля собирать

(во всяком случае я так понял)

для каждого девайса или вендора по ветке?

непонятно, о каких патчах тут идет речь

если это бсп от вендора накладывающаяся на ваниллу - да, бранч

Это хорошо, что патчи в виде патчей! А не в виде скриншотов чудо-утилит китайских вендоров, которые могут тоже присылать.

если это бсп от вендора накладывающаяся на ваниллу - да, бранч

Я такое в докер-контейнер пакую.

если это похожие но немного разные девайсы местной разработки, то если для них нужны разные патчи то у кого-то руки из жопы и он не умеет в devicetree и аналогичные вещи

А в контейнере уже сама система сборки, на основе sdk с патчами к чему угодно.

вон, у вайренборда поддержка целого зоопарка железок на трех разных SoC (правда, одного вендора и довольно похожих) живет в одних и тех же репах и даже бранчах, и вся настройка на уровне конфигов/дт

Ты хочешь при каждом мейке перенакладывать изменённые патчи и пересобирать софт?

Да-п, именно так. При этом какие-то кастомные config.h файлы или какие-то фиксы, которые делаем мы сами под себя, тоже хранить в виде .patch'ей. И чтобы не держать у себя на гите копию ветки официальной версии, и чтобы можно было если што не особо болезненно апдейтнуть версию софта и просто подредачить кастомные патчи (я так как раз с бубутом сделал, когда нашёл в более свежей версию фичу, которая нужна была). И при этом, ога, проблема в том, что наши собственные патчи время от времени могут меняться и как бы их так удобно редачить.

Народ привет. Сильно не пинайте, задам вопрос по CRC. Не знаю, какой алгоритм применяется обычно? Допустим для датчика DS18B20 - это crc8. А если у меня(которй я буду обрабатывать в смысле) протокол самопальный из 4х байт (два слова - 32 бита), каким алгоритмом проверять лучше? От чего это может зависить?

Ты хочешь при каждом мейке перенакладывать изменённые патчи и пересобирать софт?

Перенакладывать только в том случае, если они поменялись. А если добавились новые — накладывать их. Я подумал, что в тот же патч.хистори можно просто складывать таймстемпы. Если таймстемп поменялся — перенакладываем патч и усё. Ну или по принципу того же мейкфайла сравнить таймстемп патч.хистори и самого патча, ога. Так даже проще будет, вестимо.

Перенакладывать только в том случае, если они поменялись. А если добавились новые — накладывать их. Я подумал, что в тот же патч.хистори можно просто складывать таймстемпы. Если таймстемп поменялся — перенакладываем патч и усё. Ну или по принципу того же мейкфайла сравнить таймстемп патч.хистори и самого патча, ога. Так даже проще будет, вестимо.

просто проверяй m_tim у хистори и патчей

Да-п, именно так. При этом какие-то кастомные config.h файлы или какие-то фиксы, которые делаем мы сами под себя, тоже хранить в виде .patch'ей. И чтобы не держать у себя на гите копию ветки официальной версии, и чтобы можно было если што не особо болезненно апдейтнуть версию софта и просто подредачить кастомные патчи (я так как раз с бубутом сделал, когда нашёл в более свежей версию фичу, которая нужна была). И при этом, ога, проблема в том, что наши собственные патчи время от времени могут меняться и как бы их так удобно редачить.

Я не знаю. Мне кажется, редактировать патчи, которые находятся в виде .patch-файла, — это такое себе развлечение. Я в свою очередь имел просто репозитории всех тех компонентов, которые мне действительно нужно было как-то править, и хранил там теги / брэнчи, просто потому что это намного проще мэйнтейнить.

Я не знаю. Мне кажется, редактировать патчи, которые находятся в виде .patch-файла, — это такое себе развлечение. Я в свою очередь имел просто репозитории всех тех компонентов, которые мне действительно нужно было как-то править, и хранил там теги / брэнчи, просто потому что это намного проще мэйнтейнить.

Я прекрасно понимаю, насколько это такое себе развлечение. Но вот то же ядро. Я хочу просто прикрутить к нему пару кастомных дт-файлов и правки тех драйверов, которые мне по каким-то причинам нужны. В общей сложности это получается дай боже строчек.. ну-у-у.. 200? И ради 200 строчек мне создавать репу с ядром на сколько там строчек? :D Тот же билдрут, насколько я знаю, работает именно по этому принципу: он выкачивает исходники, а потом прост применяет патчи, которые хранятся в репе, если надо под него какую-нибудь условную систему сборки подфиксить. А если бы под каждый пакет он держал отдельную репу.. ой-ой-ой.

Я прекрасно понимаю, насколько это такое себе развлечение. Но вот то же ядро. Я хочу просто прикрутить к нему пару кастомных дт-файлов и правки тех драйверов, которые мне по каким-то причинам нужны. В общей сложности это получается дай боже строчек.. ну-у-у.. 200? И ради 200 строчек мне создавать репу с ядром на сколько там строчек? :D Тот же билдрут, насколько я знаю, работает именно по этому принципу: он выкачивает исходники, а потом прост применяет патчи, которые хранятся в репе, если надо под него какую-нибудь условную систему сборки подфиксить. А если бы под каждый пакет он держал отдельную репу.. ой-ой-ой.

Тем не менее, компромиссное решение — хранить копии репозиториев тех компонентов, которые ты будешь менять чаще, чем один раз (ядро, например), а всё остальное хранить так же, как хранит Buildroot.

Да-п, именно так. При этом какие-то кастомные config.h файлы или какие-то фиксы, которые делаем мы сами под себя, тоже хранить в виде .patch'ей. И чтобы не держать у себя на гите копию ветки официальной версии, и чтобы можно было если што не особо болезненно апдейтнуть версию софта и просто подредачить кастомные патчи (я так как раз с бубутом сделал, когда нашёл в более свежей версию фичу, которая нужна была). И при этом, ога, проблема в том, что наши собственные патчи время от времени могут меняться и как бы их так удобно редачить.

редачить патчи - это пиздец. не понимаю чем тебе не нравится держать у себя клон вендорской репы с локальными патчами

пиздец, потому что вносить изменения неудобно, пиздить фичи из апстрима неудобно, да все неудобно

читать диффы диффов в истории коммитов это отдельный пиздец

пиздец, потому что вносить изменения неудобно, пиздить фичи из апстрима неудобно, да все неудобно

Почему фичи пиздить неудобно? Вот говорю, юбут переносил, просто приложил свои патчи и.. там вроде один не приложился. Его быстро фиксанул и был таков. Но тут правда я целиком пиздил апстрим.

Но что касается остального я не спорю. Я первый раз когда про такую технологию услышал ахуел. И сейчас еще больше ахуел от её делания. Соу..

git remote add upstream git.denx.de/blah tig upstream /huita S-C профит

плюс портировать на новые версии с тухлой орочьей сильно легче

когда ты просто git rebase и чинишь конфликты по дороге

Sounds like опять переделывать. Но чай не долго должно быть, ага.

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

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

И с тех пор ты решил, чо лучше держать репу?

потом у меня был гнусмас, где был патчсет в 400 патчей поверх ванильки

они хранились в Великой Корпоративной VCS, но вся работа с ними производилась путем скармливания их в git am

вообще, это здравый смысл

зачем возиться с патчами руками, если все то же самое только удобно делает гит

а еще гит умеет в MERGE

и в blame

и в bisect

и еще в кучу всякой херни

люблю запах свежих мержей по утрам

ничто так не бодрит как сотня конфликтов в файле

Я знал, что рано или поздно мы перейдем и на эту дрянь

вообще, это здравый смысл

Ну. Окей, я убедился. Спасибо.

@Klukonin будет жить. Поприветствуем!

@Klukonin будет жить. Поприветствуем!

Странно, в списке висел уже)

Бывает

@RazorKalfren будет жить. Поприветствуем!

Art будет жить. Поприветствуем!

https://vk.com/wall-113107360_3506 оох заряд бодрости

и в коммеетариях уде началось кукарекание «оой да 110 вольт через электрод на кожу это хуйня»

не хотел бы получить 110 вольт на череп

не хотел бы получить 110 вольт на череп

Вскрой чакры!

фыр на тебя чугунный

Господи, это просто ГЕНИАЛЬНО! Радиовыключатель со встроенным харвестером! Энергия накапливается в момент нажатия и ее хватает чтобы передать сообщение (или даже два сообщения). Называется это чудо Zemismart ERC310. Стоит, вы не поверите, 1к деревянных за комплект "выключатель + исполнительный блок". Можно управлять с телефона и даже интегрировать с Alexa, гугловским сервисом или просто с вашим домашним сервером. Это просто "Прощай Noolite"! Короче, я в восторге. Закажу себе с зарплаты. https://www.youtube.com/watch?v=KabXDcTAdMM UPD. Надо покурить можно ли интегрировать это чудо с Sonoff bridge. Тогда же совсем круто получается. Сверхдешевые кастомизируемые исполнительные модули (эти тоже не особо дорогие. но нагрузка меньше) под управлением безбатарейных выключателей + Wi-Fi (MQTT). P.S. Выключатель с радиоканалом, мать его, БЕЗ БАТАРЕЕК! НЕУЖЕЛИ Я ДОЖИЛ ДО ЭТОГО!!! #wireless, #устройства, #selfpowered, #iot, #futureishere

Буду заказывать на пробу)

Интересно сколько такой механизм может дать мощности)

товарищ рассказывал, что в аварийной радиокнопке какого-то погрузчика тоже был харвестер

харвестер ня, наконец-то

Тибериум!

нужно больше золота

харвестер ня, наконец-то

Закажем с коллегами таких несколько штук