| |
| 2.8, мега аноним (?), 03:06, 27/04/2014 [^] [^^] [^^^] [ответить]
| –3 +/– | |
>сраньгасподня, embedded... systemd...
Для тех кто использует openembedded(OE) это то что нужно,
не знаю почему это вас удивляет.
Раньше в OE по умолчанию шла обычная /etc/init.d с кучей скриптов,
все это грузилось мягко говоря не быстро, что критично для
некоторых embedded систем, и приходилось дорабатывать
ручками для нормальной скорости загрузки.
Теперь по умолчанию с systemd все грузиться примерно за тоже время,
плюс всякие фишки для запуска основного приложения, начиная
от того что можно одной строчкой отсрочить его запуск до появления
какого-нибудь открытого domain socket закачивая watchdog для приложения (не путать с HW watchdog).
| | |
| |
| 3.11, хм (?), 09:38, 27/04/2014 [^] [^^] [^^^] [ответить]
| +/– | |
>шла обычная /etc/init.d с кучей скриптов
с большой-прибольшой кучей.
| | |
| 3.15, Mihail Zenkov (ok), 14:09, 27/04/2014 [^] [^^] [^^^] [ответить]
| +2 +/– |
 Неужели написать свой инит скрипт для embeded разработчика непосильная задача? У меня лично ноутбук загружается за 8 секунд и занимает 23Mb памяти (kernel/drivers/x.org/dwm/st/mc/conky). Естественно без systemd/pulseaudio/dbus/etc.
| | |
| |
| 4.17, Аноним (-), 14:56, 27/04/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
Действительно, на?ер нужны такие ембедщики, которые не могут несколько своих сервисов запустить простым скриптом.
| | |
| |
| 5.21, мега аноним (?), 15:51, 27/04/2014 [^] [^^] [^^^] [ответить]
| –2 +/– |
> Действительно, на?ер нужны такие ембедщики, которые не могут несколько своих сервисов запустить
> простым скриптом.
Как говорится напиши сначала этот простой скрипт.
Представьте себе, что вам естественно нужно смонтировать ФС, а если что-то пошло не так, то проверить ее с помощью fsck, если fsck не справилась то смонтировать в RO, и в этом режиме некоторые сервисы не запускать. Потом подмонтировать всякие procfs, sysfs, devpts, создать устройства и /dev и позаботиться о создании новых при подключении скажем флешки для сброса телиметрии.
Что каждый запущенный сервис нужно не просто запустить, но в случае падения перезапустить.
Нужно учесть все зависимости, чтобы запускать параллельно, т.к. чем быстрее устройство заработает от момента включения питания тем лучше. Плюс правильно отработать выключение, с учетом того, что после убийства процесса он автоматически перезапускается.
В итоге куча мелочей и "простым" скриптом софт реального изделия ты не запустишь.
Еще надо учесть что на все нестандартные скрипты нужна документация.
А тут бац, и в systemd все что нужно есть плюс документация.
Нахрена изобретать собственный велосипед?
| | |
| |
| 6.24, Mihail Zenkov (ok), 16:10, 27/04/2014 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Представьте себе, что вам естественно нужно смонтировать ФС, а если что-то пошло не так, то проверить ее с помощью fsck, если fsck не справилась то смонтировать в RO, и в этом режиме некоторые сервисы не запускать.
Если fsck не может исправить ошибки, то монтирование в RO ничего не даст - устройство не будет работать адекватно. Это либо аппаратная ошибка, либо баг fsck. В любом случае должно появится предложение обновить прошивку или обратится в СЦ, пытаться продолжать работу в таком состоянии - только портить репутацию фирмы производителя.
> Потом подмонтировать всякие procfs, sysfs, devpts, создать устройства и /dev и позаботиться о создании новых при подключении скажем флешки для сброса телиметрии.
devtmpfs + mdev отлично с этим справятся.
> Что каждый запущенный сервис нужно не просто запустить, но в случае падения перезапустить.
(while true; имя_часто_падучего_сервиса; sleep 10; done) &
> Нужно учесть все зависимости, чтобы запускать параллельно, т.к. чем быстрее устройство заработает от момента включения питания тем лучше. Плюс правильно отработать выключение, с учетом того, что после убийства процесса он автоматически перезапускается.
Ненужно переусложнять и не будет подобных проблем.
| | |
| 6.33, Michael Shigorin (ok), 19:34, 27/04/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Нужно учесть все зависимости, чтобы запускать параллельно, т.к. чем быстрее устройство
> заработает от момента включения питания тем лучше.
Прям-таки на тех CPU и флэшах переключение контекстов и убивание readahead дало выигрыш?
> В итоге куча мелочей и "простым" скриптом софт реального изделия ты не запустишь.
А расскажите-ка, что это за реальные изделия делаете и как давно. Бо сомнения берут.
| | |
| 6.36, Аноним (-), 21:07, 27/04/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
Так понимаю всю эту х;:?ню ты придумал почитав поттеринга? Ну раньше у большинства всё было нормально, но пришёл лёня и написал текст: смонтировать, запустить, при ошибке перезапустить, простые юниты, может даже обезьяна, етц. Ага, подумал меганоним и взяв текст лёньчика выкинул из него упоминание ситемд и всунул слова - надо для ембедед. Классно подогнана задача под решение.
| | |
|
|
| 4.20, мега аноним (?), 15:38, 27/04/2014 [^] [^^] [^^^] [ответить]
| +/– | |
>Неужели написать свой инит скрипт для embeded разработчика непосильная задача?
Нет конечно, и если вы читали мой пост, то узнали что я это и так сделал.
Но теперь этого делать не нужно. Ведь не считаете же вы, что моей задачей является писать скрипты для загрузки? Мне нужно чтобы изделие делало то, что прописано в ТЗ, и если мне часть функциональности не нужно писать самому и отлаживать я только рад.
PS
>У меня лично ноутбук загружается за 8 секунд
А теперь представьте, что у вас в ноутбуке процессор 200Mhz и не жесткий диск или SSD,
а nand работающий на 50Mhz, я думаю загрузка уже будет 8 * 10, что очень много для моего изделия.
| | |
| |
| 5.23, Mihail Zenkov (ok), 15:54, 27/04/2014 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Но теперь этого делать не нужно. Ведь не считаете же вы, что моей задачей является писать скрипты для загрузки? Мне нужно чтобы изделие делало то, что прописано в ТЗ, и если мне часть функциональности не нужно писать самому и отлаживать я только рад.
Согласен, но каков будет перерасход памяти от systemd и всего что он за собой притянет?
> А теперь представьте, что у вас в ноутбуке процессор 200Mhz и не жесткий диск или SSD, а nand работающий на 50Mhz, я думаю загрузка уже будет 8 * 10, что очень много для моего изделия.
Ноутбуку пять лет, на десктопе (в четыре раза мощнее ноутбука) стоит такая же система и грузится примерно столько же, так как все упирается не в cpu и не в io, а в задержки при инициализации железа.
Да и как сложная система инициализации, выполняющая кучу ненужных проверок, может быть быстрее чем хорошо продуманный скрипт?
| | |
| |
| 6.26, мегааноним (ok), 16:29, 27/04/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
 >Согласен, но каков будет перерасход памяти от systemd и всего что он за собой притянет?
Мы все-таки говорим об embedded linux системе. Это значит мы имеем несколько мегабайт оперативки, потому что в ином случае проще взять какую-нибудь мини ОС типа eCos, FreeRTOS и подобные, чем упихивать linux скажем в 128K SRAM оперативки и 256K nor flash.
В этих условиях расходы на systemd просто смехатворны, сколько-то там килобайт.
Естественно в openembedded systemd собирается без преферанса и картинок и там на это можно влиять - есть некий аналог USE флагов в Gentoo.
Пример, во время разработки изделия плата шла с 64МБ SDRAM (столько было на отладочной плате к процессору, и не было никаких требований чтобы это поменять).
При выходе в серию изделие оснастили 128МБ, т.к. микросхема была в том же корпусе, стоила столько же, а 64МБ то ли прекратили выпускать, то ли купить было сложно.
В итоге, на этом фоне, что systemd жрет сколько-то килобайт и зависит от одной не системной либы (libdbus [возможно пока не системной]) абсолютно пофиг.
>в задержки при инициализации железа
в embedded на это обычно пофиг, т.к. свое железо знаешь и нивелировать эти задержки легко,
основные задержки это как раз IO и CPU.
| | |
| |
| 7.29, Mihail Zenkov (ok), 17:56, 27/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
> В этих условиях расходы на systemd просто смехатворны, сколько-то там килобайт.
> Естественно в openembedded systemd собирается без преферанса и картинок и там на это можно влиять - есть некий аналог USE флагов в Gentoo.
Было бы интересно узнать сколько (вместе с udev) конкретно?
> в embedded на это обычно пофиг, т.к. свое железо знаешь и нивелировать эти задержки легко, основные задержки это как раз IO и CPU.
Так я и говорю, что время загрузки увеличится не в десять раз, а может наоборот даже быстрее будет, так как не надо ждать пока винты и прочее инициализируется.
| | |
| 7.34, Michael Shigorin (ok), 19:36, 27/04/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Мы все-таки говорим об embedded linux системе. Это значит мы имеем несколько
> мегабайт оперативки, потому что в ином случае проще взять какую-нибудь мини
> ОС типа eCos, FreeRTOS и подобные, чем упихивать linux скажем в
> 128K SRAM оперативки и 256K nor flash.
> В этих условиях расходы на systemd просто смехатворны, сколько-то там килобайт.
И как, давно упихивали линукс в 128k или systemd в килобайты?
| | |
|
| 6.27, Константавр (ok), 17:30, 27/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
 Хочу себе такую же серебряную пулю, чтоб за восемь секунд грузилась. Давай раскладывай, что да как. Как говорится: - "рецепт в студию"
| | |
| |
| 7.28, Mihail Zenkov (ok), 17:49, 27/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
> Хочу себе такую же серебряную пулю, чтоб за восемь секунд грузилась. Давай
> раскладывай, что да как. Как говорится: - "рецепт в студию"
Сильно измененный LFS:
glibc -> eglibc (в будущем хочу попробовать musl)
gnu* -> busybox
udev -> mdev
Управление пакетами - paco + собственная система сборки.
Ядро без модулей (все необходимое в ядре, лишнее отключено), без initrd.
Инициализация до старта иксов идет в последовательно - все эксперименты с параллельным исполнением на этой стадии ничего кроме усложнения не дали. Далее исполняется два скрипта: в одном последовательный запуск x.org и после его старта st/mc/conky/dwm, в другом параллельной запуск настройки сети, звука, энергосбережения.
| | |
|
| 6.40, Аноним (-), 17:25, 28/04/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
Почему ты думаешь, что systemd сожрет больше памяти, чем куча инстансов баша?
| | |
| |
| 7.48, Mihail Zenkov (ok), 13:24, 29/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
Для скриптов я использую ash из busybox. Суммарный Pss (включая locale-archive, libc-2.19.so, ld-2.19.so) - 132k. В описанной мной системе инициализации нужно два инстанса.
| | |
|
|
| 5.30, rob pike (?), 18:46, 27/04/2014 [^] [^^] [^^^] [ответить]
| +3 +/– | |
>Мне нужно чтобы изделие делало то, что прописано в ТЗ, и если мне часть функциональности не нужно писать самому и отлаживать я только рад.
Это замечательно. Особенно если это поддерживать ваш продукт кому-то другому.
Который будет выслушивать маты от заказчика, у которого оно будет падать с невнятными сообщениями об ошибках, а то и совсем без них, и ездить-летать в те далекие места где оно у заказчика работает, чтобы выяснить какой именно затык в systemd на этот раз.
| | |
| 5.37, Аноним (-), 23:34, 27/04/2014 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> А теперь представьте, что у вас в ноутбуке процессор 200Mhz и не жесткий диск или SSD,
а nand работающий на 50Mhz, я думаю загрузка уже будет 8 * 10, что очень много для моего изделия.
На процессоре 200Mhz ваш любимый systemd будет полчаса гонять туда-сюда сотню сообщений через dbus, только чтобы запустить какой-нибудь сервис, который как правило в embeded системах запускается скриптом из 5 строчек.
А уж про килобайты памяти для systemd может написать разве что совсем невменяемый человек.
В libdbus то хоть заглядывали?
| | |
| |
| 6.41, Аноним (-), 17:57, 28/04/2014 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> На процессоре 200Mhz ваш любимый systemd будет полчаса гонять туда-сюда сотню сообщений через dbus
Проц там может требоваться, разве что, на сериализацию/десериализацию (ну не на запись/чтение из сокета же), и займет ли это больше ресурсов, чем интерпретация кода на shell - это еще большой вопрос.
> А уж про килобайты памяти для systemd может написать разве что совсем невменяемый человек.
systemd на десктопе жрет RES меньше, чем один login-инстанс баша.
> В libdbus то хоть заглядывали?
Ты апеллируешь к footprint-у библиотеки, но забываешь, что потребление памяти shell-интерпретатора не сводится только к размеру кода его бинарника. Кстати, ты сам-то в исходники какого-нибудь шелла в его шапшеподобным кодом FSM заглядывал?
| | |
|
|
|
| 3.18, Аноним (-), 15:01, 27/04/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
належность работы - для Embedded systems - куда важнее, скорости загрузки/старта.
равно как и консистентность.
или управляемость.
или отсутствие анальных зондов от ЦРУ.
| | |
| |
| 4.25, мегааноним (ok), 16:14, 27/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
> належность работы - для Embedded systems - куда важнее, скорости загрузки/старта.
> равно как и консистентность.
> или управляемость.
> или отсутствие анальных зондов от ЦРУ.
Чушь. Вы назвали несколько параметров:
- скорости загрузки/старта
- належность
- управляемость
- отсутствие анальных зондов от ЦРУ
Как вы можете сказать, что для сферического embedded устройства какой-то из параметров
может быть важнее другого?
Для гражданского embedded всем насрать на зонды от ЦРУ, если
это скажется на скорости разработки или еще на каких-то параметрах
мешающих коммерческому успеху.
В военных embedded, естественно наличие/отсутствие параметра "анальные зонды от ЦРУ" имеет один из высших приоритетов.
И так для каждого из параметров.
Кому скажем нужен телефон/рация которая включается 10 минут,
если мы говорим о бытовой электронике?
Или скажем всем насрать, если ПО для какой-нибудь железке
на производстве грузиться 50 минут, если она потом по технологии не выключается годами.
и т.д. и т.п.
Каждый параметр может быть важен и не важен в embedded находится в зависимости от того для чего embedded железка нужна.
| | |
| |
| 5.43, Michael Shigorin (ok), 20:37, 28/04/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> Чушь.
Поскольку федорофанбои не поняли, пришлось наглую назойливую рекламу стереть -- этой чушью уже все уши прожужжали, а только слаще она от того не стала.
| | |
|
|
| 3.45, Anonim (??), 21:30, 28/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
> приходилось дорабатывать ручками для нормальной скорости загрузки.
> Теперь по умолчанию с systemd все грузиться примерно за тоже время
Значит ручки из ж..ы растут. busybox init на скриптах (!) которые у вас так тормозят у меня работает ~3 раза быстрей чем то же самое на systemd. Доработанная система (скорость в основном упирается в инит модулей ядра) загружается меньше секунды.
| | |
|
|
| 1.12, Аноним (-), 10:13, 27/04/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> Edgerouter (замена для routerstationpro);
Не понял юмора автора этой мысли. В каком месте оно замена?
| | |
| |
| 2.19, Аноним (-), 15:02, 27/04/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
это не замена, а скорее алычные мечты неосиляторов-проприерастов, увы.
| | |
|
| 1.44, Аноним (-), 21:03, 28/04/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
rpm для встройки? На 4-х метрах ipk некуда распаковывать. Для малых обьемов может и прокатит - но qnx по прежнему интереснее.
| | |
|
