Embox v0.5.2 Released

Спасибо, теперь понятно, согласен, потенциально это тоже баг Повесил задачу, тут нужно внимательнее посмотреть.

тут нужно внимательнее посмотреть

тут с логикой что-то не так

	if (ch == '#') {
		ch = '#';
	}

https://github.com/embox/embox/blob/master/src/compat/posix/curses/curses.c#L74

в этом условие cnt всегда false

size_t cnt;
...
	if (cnt <= 0) {
	>>>	file->flags |= cnt ? IO_ERR_ : IO_EOF_;
		return 0;
	}

https://github.com/embox/embox/blob/master/src/compat/libc/stdio/fread.c#L25

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

Вот на счет возможностей трудно не согласиться, что у Интела больше возможностей, как минимум финансовых. Но это так лирика. Но с другими пунктами есть вопросы.

• Уровень разработки - что вы под этим понимаете. Попробую пояснить. Собор и базар конечно не нужно пояснять что такое. Так вот Линукс по моему мнению развился за счет базара, а теперь удивительно красивая стабильная и так далее система. Мы не игнорируем статические анализаторы, применяли coverity. Но выяснили, что система слишком большая и пока мы правим мелкие ошибки в пользовательских утилитах, мы отстаем в ядре сетевом стеке и так далее, где статический анализатор не может найти ошибки. Но конечно, применение анализаторов так же как и другие подходы улучшения надежности и качества кода, мы постоянно пытаемся применять.
• поддержки - поддержка открытого проекта? Вы имеете в виду более развитое комьюнити? Да, мы пытаемся его развить как можно больше, удалось привлечь какое то количество промышленных предприятий, но конечно это капля в море. Но мы это понимаем и стремимся в первую очередь развить эту часть. Немного упуская из вида статические анализаторы. Но решили сосредоточится на фишках, то есть делаем демки, которые не может (трудно сделать) на zephyr и других ОС для микроконтроллеров.
• качества - тоже сомнительный пункт, в открытый проект (как минимум в некритические части) могут вносить код не только крутые инженеры. То есть я допускаю что в zephyr то же есть код приложений который разименовывает нулевые указатели в каких то случаях. Если вы про то что zephyr используется чаще, то повторюсь мы к этому стремимся, и таким образом стараемся улучшить качество кода.

Для меня выбор очевиден что использовать.

Все таки правильне говорить, для каких задач что использовать. Я уже приводил пример OpenCV который не может использовать Zephyr (и другие мелкие RTOS). Есть и ряд других фишек, конечно не всегда требуемых, но если требуется, то уже есть основания использовать Embox.

А одна из фишек Embox — механизм для включения в исходники конечного продукта только нужных для него модулей (более подробно, думаю, Антон может пояснить). У Zephyr такое есть, кстати?

По сути дела Zephyr это классическая ОС для микроконтроллеров. То есть механизм когда включается только код который используется (со статической линковкой) у него при рождении. Плюс у zephyr используется KBuild подходящий для многих задач по конфигурации и привычный для многих разработчиков ядра. Еще есть классная идея использовать описания в формате близком к devtree и статически генерить артифакты (в отличие от линукс). И да zephyr пошел от микроконтроллеров в сторону Линукс, так же как например NuttX.

Но Embox прошел по этому пути дальше причем заметно. Мы можем указывать различные параметры, например что в системе будет столько то сетевых пакетов, мы можем использовать понятие интерфейса на уровне модулей, для избавления от if def, и так далее. Плюс очень важный момент, мы совмещаем Kbuild для ядра и какую нибудь openembedded для дистрибутивов. Это позволяет нам гораздо ближе приблизится к удобству Linux. можно просто сравнить код тех же утилит, у нас они просто компилируются под Linux и вообще основная разработка ведется не за целевой платформе а на линукс. Но при этом конечно сохраняем свойства мелких RTOS.

И да, мы отлично понимаем, что делать еще одну ОС потому что это мы ее делаем, бессмысленно, она будет уступать zephyr FreeRTOS и так далее. И уж точно мы всем говорим, что всегда используйте Linux где это возможно. Он несравненно более надежен и отлажен по сравнению со всеми остальными системами

Спасибо. Ага странное что то!

Спасибо, согласен

Мы не игнорируем статические анализаторы

size_t blksize;
...
       if (blksize < 0) {
                return blksize;
        }

https://github.com/embox/embox/blob/master/src/drivers/block_dev/block_dev.c#...

https://github.com/embox/embox/blob/master/src/drivers/block_dev/block_dev.c#...

https://github.com/embox/embox/blob/master/src/drivers/block_dev/block_dev.c#...

Спасибо! Вот блочные устройства все время хотим переписать. Они работают, но там конечно…

все время хотим переписать

переписывайте на расте уж тогда - хоть какая-то изюминка у проекта будет :)

переписывайте на расте уж тогда - хоть какая-то изюминка у проекта будет :)

Ну Rust мы действительно давно хотим попробовать, но только для написания отдельных модулей. Переписывание ради языка мягко говоря не добавляет новых фишек, а любой новый код содержит ошибки.

К тому же операционок на Rust уже не мало, так что в качестве изюминки как то не учень. Ну и главное, пару фишек Embox я выше в комментариях перечислил, нам бы качество кода через массовое использование и развитие комьюнити :)

Это позволяет нам гораздо ближе приблизится к удобству Linux.

а такое у вас есть?

Build Zephyr as native Linux application 
Enable large scale simulation of network or Bluetooth tests without involving HW
Improve test coverage of application layers
Use any native tools available for debugging and profiling
Develop GUI applications entirely on the desktop
Optionally connect to real devices with TCP/IP, Bluetooth, and CAN
Reduce requirements for HW test platforms during development

Enable large scale simulation of network or Bluetooth tests without involving HW
Improve test coverage of application layers
Use any native tools available for debugging and profiling
Develop GUI applications entirely on the desktop
Optionally connect to real devices with TCP/IP, Bluetooth, and CAN
Reduce requirements for HW test platforms during development

В полный рост и даже покруче чем у них (статья про сложное приложение с графикой и профелированием кучи на линуксе ну или эта на английском только пока что. Единственное CAN не поддержан, просто не спрашивали пока для реальных задач

А есть подобная ОС, но без цели совместимости с линуксом, а просто чтобы был свой API, минимальный футпринт и тд. На Rust, конечно.

В полный рост и даже покруче чем у них

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

Build Zephyr as native Linux application

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

На Rust, конечно.

https://www.redox-os.org/ На rust вот например.

Если

А есть подобная ОС, но без цели совместимости с линуксом, а просто чтобы был свой API, минимальный футпринт и тд

То это Embox, то есть совместимость по API это фишка которую можно не использовать, и тогда влезть можно в очень мелкие платформы см статью

На Rust, конечно
То это Embox

про раст видимо случайно потерялось, опять

https://github.com/tock/tock

Да, спасибо, согласен.

Да ты со всем спасибо-согласен. Он реальных читателей по теме назвал третьими людьми, подчеркнув приоритет. А анонов во всём виновными, хотя набросил-то рег.

Да, спасибо, согласен.

Это типа корпоративной этики? Здесь она не нужна. Тут срачи и угар правят балом. Если твой продукт не обсирает другой, то он ненужен.

тут с логикой что-то не так

	if (ch == '#') {
		ch = '#';
	}

Всё вполне логично. Если это решётка, то пусть решёткой и будет.

Build Zephyr as native Linux application

Можно собрать usermode

make confload-usermode/debug
make

Но по опыту оптимальный путь заключается, отладка приложений (бизнес логики) на линукс, со всему фичами типа valgrind. Затем отладка на qemu. Все тоже самое, просто прописываются строчки в конфигах и небольшие файлы описаний делаются. В остальном можно добиться окружения типа Linux И наконец, отладка на целевой платформе. Вроде в статьях именно такоей подход. Он же как я понял описан в приведенных фичах zephyr то есть максимально отлаживаем все части не на целефой платформе.

а первая строка видимо случайно потерялась Да, возможно. Я имел в виду, что у нас даже более удобно чем в zephyr. Допускаю конечно что мне просто привычнее наш подход, но действительно делал и там и там и удивлялся насколько Embox в этом плане удобнее. Похожее мнение наши пользователи высказывают. Но первое мнение, конечно близко к вашему, да зачем мне оно вообще нужно :)

Понял, спасибо.

Всё вполне логично. Если это решётка, то пусть решёткой и будет.

В точку. А на всякий случай сделаем его все таки решеткой. :)

Но по опыту оптимальный путь заключается, отладка приложений (бизнес логики) на линукс

и как отлаживать не Linux приложение на Linux?

чет скриншотов системы нет нигде. кто-нить завезите им кнопку принтскрин.

Это экономия на туалетной бумаге. Проще лицуху купить.

с платной лицензией никакие посторонние кулибины не нужны

https://www.qt.io/product/develop-software-microcontrollers-mcu

с платной лицензией никакие посторонние кулибины не нужны

https://www.qt.io/product/develop-software-microcontrollers-mcu

Цена у них указана только для приложений https://www.qt.io/webshop/ А Qt для микроконтроллеров уже под вопросом.

Хотя лучше вообще не париться и пользовать LVGL.

Хотя можно и бесплатно украсть Qt и концы в воду. На китайском рынке никто не будет беспокоится о какие-то там правах. Главное не наглеть, берега не путать.

Ну вот, а говорил, чего обсуждать, я думаю, теперь тебе в Embox присвоят звание «тестер года» :)

Ну так make confload-usermode/debug собирает Embox как пользовательское прилоежние Linux. Дальше просто запускаем, там есть сеть (через тунтаб интерфейс) есть консоль.

Да POSIX порой не нужен, например когда используем легкие потоки (невытесняющюю многозадачность) или используем напрямую, а не через файловую систему, обращение к устройствам. Но это случай когда у Embox, если и есть преимущества, то не сильно выраженые. Да можно запустить даже на 4кб ОЗУ. И кстати, там можно запускать обычные приложения использовать printf и так далее. Но то же самое можно сделать за сопостовимое (а может и меньшее) время как на FreeRTOS.

Я предположу, что zephyr не удалось так круто обрезать стандартную библиотеку. Это наша фишка, что все в том числе и стандартная библиотека конфигурируется. И получается да, когда hobbit говорил про только используемый код, то был прав, zephyr менее конфигурируемый (хотя бы в плане стандартной библиотеки) чем Embox.

Собственно, это тоже одно из преимуществ. Разработчик может использовать тот инструментарий который ему ближе, или который лучше подходит для задачи.

чет скриншотов системы нет нигде. кто-нить завезите им кнопку принтскрин.

Ага и не скучные обои, как же без них в специализированных системах :)

Ну вот, а говорил, чего обсуждать, я думаю, теперь тебе в Embox присвоят звание «тестер года» :)

Ну может не тестер года, но точно очень благодарны spbob за найденные проблемные места:)

дело не столько в наличии ошибок - дело в их игнорировании.

Поправили несколько замечаний, на другие issues завели в трекере. Спасибо большое, за баг репорты!

там есть сеть (через тунтаб интерфейс) есть консоль

zephyr эмулирует намного больше

https://docs.zephyrproject.org/latest/boards/posix/native_posix/doc/index.htm...

Поправили несколько замечаний, на другие issues завели в трекере

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

				oldpatharg =
						calloc(strlen(oldpath) + diritemlen + 2, sizeof(char));
				newpatharg =
						calloc(strlen(newpath) + diritemlen + 2, sizeof(char));
				if (NULL == oldpatharg || NULL == newpatharg) {
					SET_ERRNO(ENOMEM);
					return -1;
				}

https://github.com/embox/embox/blob/master/src/fs/syslib/kfsop.c#L593

Спасибо за баг репорт!

Но почему показушные и почему продолжаем игнорировать?

zephyr эмулирует намного больше

Допускаю, но глянул туда и например там таймер эмулируется, зачем, есть прекрасное qemu, в котором можно гораздо больше аппаратуры получить.