Релиз встраиваемой системы реального времени Embox v0.4.0

Да, я помню. Вот только этими DSPшками управлять ещё нужно, онторфейсы громоздить, куча сопровождающих штук, которые решать придётся. А запуск в операционке может всё это сделать за тебя. Ну, да, накладные расходы операционки, но в такой операционке (гипотетицски) всё будет ориентировано на работу только с твоим симулятором. Разве это не круто?

Вот звук… не очень интересен. :)

Ну каждому, как говорится, свое :)

Гораздо более интересен сетевой стек и внезапно - подсистема хранения. Возможно на нем реализовывать аналоги OpenWRT/pfsense, желательно с интерфейсом на основе CLISH или скажем ESOS…

Возможно, реализуют.

Сетевой стек достаточно функционален, как пример работают VoIP телефон, звук понятно по сети передается. Есть версия работы Qt через VNC (VNC Qt-шный) соответсвенно тоже работа сетевого стека. Dropbear (sshd который), ну и так далее. Есть сетевые фс NFS и cifs (samba). В последнее время достаточно плотно работаем над устройствами хранения (USB, MMC, диски). Они есть работают, но порой не достаточно хорошо, развиваем улучшаем.

Так что построить какой нибудь файервол или комутатор вполне реально! правда тут надо уточнить, что для домашнего использования, все таки проще взять OpenWRT/pfsense или какую нибудь Yocto.

Да это я так, всё мечтаю о несбыточных вещах.

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

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

ну все мы играем и порой игры переходят в нечно серьезное :)

Ну, да, накладные расходы операционки, но в такой операционке (гипотетицски) всё будет ориентировано на работу только с твоим симулятором. Разве это не круто?

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

красавцы. Спарк (leon3/4) до сих пор поддерживаете?

спасибо

Leon3 поддерживаем (правда не развиваем), даже с железки (fpga) сдули пыль и проверили, что еще работает. Проверили на tsim. Плюс на qemu крутиться постоянно.

Leon4 не пробовали :(

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

Согласен, это критическая часть, но система в целом не ограничивается, обработкой звука. И как правильно отметил ChekPuk в комментарии. Embox позволяет существенно снизить накладные расходы от использования ОС.

Блин опять все перепутали сертификацию и https://ru.wikipedia.org/wiki/Формальная_верификация

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

А вы есть, хотя бы, в реестре отечественного ПО (не хочу лезть туда с поисками)?

нет, нету.

К сожалению, мы так и не определились с отношением к реестру.

Мы являемся разработчиками, то есть развиваем техническую составляющую. Проект открытый и в нем участвуют не только отечественные разработчики, хотя большинство конечно они. Реестр, это про продажи. Мы занимаемся продажами поскольку обеспечиваем поддержку и сопровождение проекта. Но пока в переговорах с заказчиками выяснялось, что им нет необходимости во включении в реестр. Основное было достижение технических характеристик систем на базе Embox.

Но если у Вас есть интерес в использовании Embox, и единственным ограничением является присуствие в реестре, сообщите :)

На самом деле мне интересны оба направления. И вообще, ковыряния в интерактивных звукопрограммных средах меня заводют. Но поскольку времени и сил нет ни на то, ни на это, то остаётся только наблюдать.

А вообще жаль, что шорох вокруг того эмулятора сошёл на нет. Куруфинвыч крут. Его бы проект, да в законченном виде бы да в железо облачённый... Кросота!

Ну и ваша ось интересная. Но возможности всем этим заниматься нет. Эх, скорее бы пенсия.

почему такое название?

Embox - Embedded Box. изначально задумывалась как такой минимальный джентельменский набор для разработки встроенных систем.

разве это не просто очередная ОС?

Если речь идет про то, что это очередной дистрибутив на базе Linux, то нет, это не оно.

Это оригинальная разработка, в ней реализован ряд идей которые (в основном) в том или ином виде встречаются и в других системах. Наример, уже опомянутая конфигурация в eCos, или возможность запускать posix ПО в NuttX, или совместимость по драйверам в CoreBoot. Но важно конечно как реализовано. Например на наш взгляд, нам, удалось найти удачное решение в виде специального языка описания модулей, которое отделено от кода. Строится модель системы генерятся всякие артифакты и потом уже собирается система. Это позволяет очень хорошо распределять ресурсы. Например, запускать Qt на stm32f7.

и для чего оно?

на данный момент, мы видим нишу в областях где не очень подходит Linux. Реалтайм, сертификация, маленькие ресурсы, … При этом в Embox можно собирать и запускать ПО из Linux без больших усилий.

P.S. На Arch-е проверяли все работает

я проверил - не работает. будем и дальше втупую повторять, что всё работает? ошибки я сам придумал и руками нарисовал? детский сад, ей богу

ни в коем случае, повторять не будем. Я просто пытаюсь понять проблему.

Мне кажется, что Вы просто не разобрались.

Извините, не правильно выразился. Я имел в виду, что кто то кого то не понял. Спасибо, что потратили время на проект. Я бы очень хотелось понять, где же проблема, на arch-е в команде проекта сидят несколько разработчиков. Плюс, на всякий случай, я попросил собрать и запустить, мне подтвердили, что запускается.

По поводу кросс-компиляторов. Извините, это я затупил.

make[4]: aarch64-elf-gcc: Command not found
...
$ aarch64-linux-gnu-gcc -v
gcc version 9.2.0 (GCC) 

то есть Вы просто выкинули неинформативную часть.

В этом случае нужно, либо поставить именно aarch64-elf-gcc. Или просто поменять строчку где он задается. После конфигурации файл ./conf/build.conf соотвествено переменную CROSS_COMPILE

Если не трудно сделайте пожалуйста:

make clean cacheclean 
make confload-x86/qemu 
Config complete

make
 MKGEN mk_core_def.mk

...
 CONFIGFILE conf/mods.config
 CONFIGLINK
 BUILDMODEL
 BUILDGEN build
Error: modules dependency cycle:
	embox.arch.x86.mmu
	embox.mem.vmem_depends
	embox.mem.vmem_device_memory_full
	embox.mem.mmap
Error: modules dependency cycle:
	embox.arch.x86.mmu
	embox.mem.vmem_depends
	embox.mem.vmem_device_memory_full
	embox.mem.mmap
Error: modules dependency cycle:
	embox.arch.x86.mmu
	embox.mem.vmem_depends
	embox.mem.vmem_device_memory_full
	embox.mem.mmap
cp -r -T src/lib/debug/whereami.h build/base/include/debug/whereami.h
cp -r -T src/drivers/serial/i8250/8250.h build/base/include/drivers/serial/8250.h

...

   text	   data	    bss	    dec	    hex	filename
1156641	 228604	170800416	172185661	a43583d	build/base/bin/embox
Build complete

Вот это наши внутренние сообщения

Error: modules dependency cycle:
	embox.arch.x86.mmu
	embox.mem.vmem_depends
	embox.mem.vmem_device_memory_full
	embox.mem.mmap
Error: modules dependency cycle:
	embox.arch.x86.mmu
	embox.mem.vmem_depends
	embox.mem.vmem_device_memory_full
	embox.mem.mmap
Error: modules dependency cycle:
	embox.arch.x86.mmu
	embox.mem.vmem_depends
	embox.mem.vmem_device_memory_full
	embox.mem.mmap

Далее запуск, мой такой:

./scripts/qemu/auto_qemu
AUTOQEMU_ARCH: x86 (guessed)
...
sudo -E qemu-system-i386 -kernel ./build/base/bin/embox -m 256 -net nic,netdev=n0,model=virtio,macaddr=AA:BB:CC:DD:EE:02 -netdev tap,script=./scripts/qemu/start_script,downscript=./scripts/qemu/stop_script,vnet_hdr=no,id=n0 -nographic -device pci-ohci,id=ohci
[sudo] password for anton: 
ioctl(TUNSETIFF): Device or resource busy
Enable IP Forwarding for xenbr0
net.ipv4.ip_forward = 1

Embox kernel start
	unit: initializing embox.kernel.task.task_resource: done
	...
Default IO device[ttyS0]
>export PWD=/
>export HOME=/
>netmanager
>service telnetd
Starting service: telnetd
>service httpd
Starting service: httpd
>tish
root@embox:/#

Заранее, большое спасибо!

А вообще жаль, что шорох вокруг того эмулятора сошёл на нет.

Потому что изменений пока нет. А так вообще сегодня релиз 1.1.

Я доделываю редактор, по твоим замечаниям кстати все переписал. Проект намного более объемный, поэтому столько времени занимает. Но он выйдет.

Я собираюсь рулить DSP при помощи STM32F4 (для графического интерфейса экранчика и работы с сетью, загрузки прошивок и настроек в аудио-DSP).

Можно Embox запустить на STM32F4?

К тебе вообще никаких претензий :) Я говорю о том, что народ активно не втянулся, хотя твой kpp на старте лучше гитарикса. Хотя с внесением профилей на импульсах стало поплощще, для меня, «аналогового» гитариста :), но это отдельный разговор, который мы будем разговаривать позже, если у меня появятся условия для продолжения испытаний (серьёзно наигрывать руки,, всё-таки не дадут).

Можно Embox запустить на STM32F4?

Да, конечно. Поддержано нескольно демоплат. Если требуется еще что-то, свистните, постараемся помочь :)

Отлично, буду пробовать.

видео как запустить Embox на stm32 на английском, на всякий случай. :)

они не нужны, как и qt 4.8.5

Это анонимус со своими ненужнами не нужен, а Qt 4.8.* — отличная хорошо вылизанная ветка.

(Я, заметьте, не говорю, что Qt5 не нужна.)

Интересно, есть где-нибудь список графических библиотек доступных для stm'ов и похожих контроллеров? А ещё лучше их сравнение.

lvgl неплохой вариант.

спасибо.

ядро взято Linux? вы с нуля создавали или заимствовали код из других открытых проектов?

ядро взято Linux?

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

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

вы с нуля создавали или заимствовали код из других открытых проектов?

Создавали с нуля, но идеи заимствовали конечно. На каком то этапе добавили возможность своеобразного ./configure; make; make install делать. Так например Qt, dropbear, Mesa3d, OpenCV и другие замечательные проекты с открытым кодом затащили.

Нам в свое время приглянулся nuklear

Есть ли в таких embedded осях какая-нибудь поддержка крипто?

Чем эта ось лучше, чем Nuttx?

Есть ли в таких embedded осях какая-нибудь поддержка крипто?

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

Чем эта ось лучше, чем Nuttx?

вот это вопрос :)

• Когда начинали не знали о NuttX.
• Используем другой подход для обеспечения запуска ПО без MMU. Грегори Натт даже обсуждал у нас в группе подходы.
• Вроде у NuttX нет плюсов, соответственно Qt и другие либы недоступны
• Насколько я понимаю, у нас требуется меньше ресурсов, поскольку используем статическую конфигурацию на основании собственного DSL
• Ближе к Linux, по крайней мере можно сделать.
• Система сборки имеет больше возможностей.

Но вообще NuttX очень интересный проект!

Уже упомянутый портированный dropbear содержит криптографию.

Есть ли dropbear для Nuttx?

спасибо.

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

проект с Гит замечательно, но сайт? всего одна страница. и в новости здесь так скудно и сухо и ссылка не на сайт, где я, к примеру мог бы найти ответы на все эти вопросы.

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

хорошо то, что вы открыты в данной ветке и отвечаете на все вопросы (можете уже хотя бы из этой ветки форума сделать ещё одну страницу для сайта Q&A, если не хватает времени).

а так, случится то, что просто сопрут вашу разработку какие-нибудь условные «Майкрософты» и всё

то, что с лицензией неопределёность - это не очень хорошо. BSD явно не подходит, вы потеряете проект. или делайте GNU GPL или накладывайте копирайты (код при этом может оставаться открытым). по крайней мере пока не раскрутитесь - нужно защититься юридически (современное законодательство в РФ это позволяет). придётся деанонимизироваться - сделайте ссылки на свои профили или создайте профиль на том же вашем сайте (уже третья страница), расскажите о себе. так хотя бы с позиций истории люди будут знать, об основателе проекта, если даже и сопрут, - историческую справедливость легко будет восстановить.

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

с лицензии наверное, надо было начинать

А что у вас с поддержкой POSIX?

Dropbear портируется даже без POSIX?

Есть ли dropbear для Nuttx?

не уверен, но лично я таком не слышал!

А что у вас с поддержкой POSIX?

Dropbear портируется даже без POSIX?

Dropbear требует хорошей поддержки POSIX и еще много вещей за собой тянет.

Как я уже упоминал в комментарии

На каком то этапе добавили возможность своеобразного ./configure; make; make install делать. Так например Qt, dropbear, Mesa3d, OpenCV и другие замечательные проекты с открытым кодом затащили.

Собственно это я имел в виду под приимуществами над NuttX

• Ближе к Linux, по крайней мере можно сделать.
• Система сборки имеет больше возможностей.

У нас можно прямо (.pro файлы Qt проектов ) компилировать. И другие расширенные возможности по совместимости с Linux. То есть мы выглядим «ближе к Linux» отсюда и dropbear. Он у нас тоже из коробки, а не исходники затащены.

вы проделали огромную работу и видно, что множество хороших идей вложено.

Спасибо.

правда уточню я всего лишь один из основателей проекта, участников много, и вклад вполне сопостовим с моим. На github указано 70 коммитеров :)

о всё это спрятано за отсутствием раскрутки.

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

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

За советы спасибо. Мы работаем над расширением документации она у нас тоже доступна на github и конечно открытая, возможно действительно стоит добавить раздел Q&A.

На счет GPL лицензии, не соглашусь. Дело в том, что embedded подразумевает встраивание в другие системы. Для них очень важно иметь возможность закрывать часть кода. Собственно мы это делаем для конечных системи коммерческих проектов. Кроме того, мы не боимся, что проект уведут. Если его будут шире использовать мы только рады, и всячески этому способствуем :) Ну а история, остается в git-е, кроме того уже достаточно много источников подтверждающих наши права на проект. В том числе на видео с различного рода конференций :)

а вы когда начинали работу, у вас была конкретная практическая цель? или просто была идея создать гибкую встраиваемую ОС, практическое применение которой будут находить пользователи?

грубо говоря, в начале это был прямой заказ/контракт или это чистая инициатива группы единомышленников?

А там есть интерпретатор команд? Если да, то как выглядит?

dash там

https://github.com/embox/embox/blob/986e0f5442bed7b5bcbb0fcab6462fd9e4367a24/...

2к2к-тый год на дворе

т.е., 20002000 год)

Таки 2200000 по идее. 2к2 это 2.2 тысяч, то есть 2200, а ещё одна к значит добавление ещё трёх нулей.

https://github.com/embox/embox/blob/master/src/kernel/syscall/linux_table.c системных вызовов что-то маловато. Почему я не вижу системного вызова execve? Как это у вас реализуется?

Ну и что насчет таких штук, как мьютексы, семафоры, их разве не через системные вызовы принято реализовывать?

Вообще execve есть, но зачем он не в системных вызовах? https://github.com/embox/embox/blob/01078551a7b4a2579d7106dca76e2324fbbde649/...

А еще вот тут

uint32_t mmap_create_stack(struct emmap *mmap) {
	size_t size = 4096;
	uintptr_t base = mmap_alloc(mmap, size);
	mmap_place(task_self_resource_mmap(), base, size, 0);
	vmem_map_region(mmap->ctx, base, base, size,
			PROT_WRITE | PROT_READ | PROT_EXEC | VMEM_PAGE_USERMODE);
	return base + size;
}

Нет проверки на NULL после mmap_alloc - не баг ли это? И зачем mmap_alloc возвращает uintptr_t а не void *?

Таки 2200000 по идее. 2к2 это 2.2 тысяч, то есть 2200, а ещё одна к значит добавление ещё трёх нулей.

Ну по-факту, сейчас принято говорить о тысячелетии 2к и добавлять цифру года, т.е. наступил 2к20 (20 год второго тысячелетия). Это давно везде плотно закрепилось и если ты напишешь про 2к2 год на каком-нибудь форуме, все подумают про 2002)) Вбей в гугл 2к19, к примеру.

а вы когда начинали работу, у вас была конкретная практическая цель? или просто была идея создать гибкую встраиваемую ОС, практическое применение которой будут находить пользователи?

грубо говоря, в начале это был прямой заказ/контракт или это чистая инициатива группы единомышленников?

На мой взгляд нужно разделять эти вопросы.

То есть была практическая цель, создать средства для упрощения отладки аппаратуры, в том числе и FPGA. С этой задачей тогдашний Embox который еще тогда не был ни открытым проектом ни опереционкой, вполне справился. Но это был не коммерческий продукт, заказчиками выступалимы сами. Вторая цель всплыла тоже очень быстро. Заказчик хотел сертифицировать некоторую ОС (тогда это Linux) которую мы ему делали, но там было слишком много строчек кода. Появилась идея, предложить ему ограниченный вариант, кстати тоже не за деньги. Ну и наконец, была потребность обучать студентов системному программированию.

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

Спасибо!

Нет проверки на NULL после mmap_alloc - не баг ли это?

Да, Вы совершенно прави, проверку стоит добавить, мы были бы очень благодарны, если бы Вы сделали RP.

И зачем mmap_alloc возвращает uintptr_t а не void *?

Насколько я помню мы тут наравались при портировании на Эльбрус, что void * приводить к целочисленным не хорошо. Нам прямо указали пункт в стандарте, где сказано что поведение зависит от реализации. и следует использовать intptr_t.

Вообще execve есть, но зачем он не в системных вызовах?

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

https://github.com/embox/embox/blob/master/src/kernel/syscall/linux_table.c системных вызовов что-то маловато. Почему я не вижу системного вызова execve? Как это у вас реализуется?

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

Ну и что насчет таких штук, как мьютексы, семафоры, их разве не через системные вызовы принято реализовывать?

Все реализовано, pthread.h почти полный. Принято, но у в Embox есть несколько оригинальных идей, по сути дела мы очень много экспериментируем. В итоге основная идея использовать статическую сборку и проверку, таким образом не обязательно использовать системные вызовы, можно достаточно безопастно вызывать код ядра из пользовательского пространства. Но в принципе, можно использовать и классическую модель, если так сконфигурировать систему. Правда не знаю насколько это оправдано, ведь тогда нет приимуществ по сравнению с Linux.

А там есть интерпретатор команд? Если да, то как выглядит?

Да, есть. Написали парочку совсем простых shell ов. В основном используется tish. В принципе выглядит также как и обычные консоли, с добивкой команд и так далее, правда нет циклов и всяких | пайпов. Думаем расширить, или расширить опционально.

Плюс у нас есть несколько скриптовых языков (lisp, lua, tcl, python, ..) в принципе были прицеденты когда их использовали в качестве интерпретатора.

Затащили dash, но это скорее для демонстрации работы без MMU, особо не пользуемся.

это правда, что немалую часть кода написали студенты? это была их курсовая или дипломная? или итоговая работа для экзамена/зачёта?

все их имена упомянуты где-то как контрибьюторов?

тот преподаватель - это вы? или кто-то другой из вашей команды?

это правда, что немалую часть кода написали студенты?

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

это была их курсовая или дипломная? или итоговая работа для экзамена/зачёта?

Вот кода за курсовую (диплом) точно очень незначительное количество. У нас всегда был принят другой подход, за работу могли поставить зачет, а не наоборот.

Сейчас есть курс на ММ СПбГУ там как раз классический подход, студентам ставится задача, на семестр и они что то должны сделать. Результат близок к нулю, максимум могут пофиксить какие нибудь мелкие баги. Ведь как я уже сказал, сначала они должны влиться в проект научится системному программированию, не в универе же они этому научатся :)

все их имена упомянуты где-то как контрибьюторов?

Да естественно, можно посмотреть список контрибъютеров у проекта на github. Мы допускаем участие только кодом, документация тоже на гитхабе, есть правила проекта, и автоматом все идет в ваше резюме.

тот преподаватель - это вы? или кто-то другой из вашей команды?

извините, «тот преподаватель» это который? От имени которого формально ставятся зачеты? Официально я никогда не был сотрудником СПбГУ :) только аспирантом. Но вернемся к первому пункту, нет, не студенты писали Embox :) . Но Embox (и подобные проекты) позволяет очень эффективно обучать студентов.

Да, Вы совершенно прави, проверку стоит добавить, мы были бы очень благодарны, если бы Вы сделали RP.

Нет. По крайней мере не сейчас. Тут надо разбираться.

Я например не очень понимаю такой момент - ваша ОС умеет работать на микроконтроллерах без MMU, верно? Функция execve_syscall() вызывает mmap_create_stack() которая в свою очередь вызывае vmem_map_region(). Название функции явно намекает на виртуальную память, в реализации функции vmem_map_region() https://github.com/embox/embox/blob/2103f04ac4e6223ed92895f993ac0c3e5ce64ef2/... упоминается структура mmu_entry т.е. у вас для execve нужно чтоб было MMU?

Притом для вызова fork у вас есть явно безMMU-шный вариант: https://github.com/embox/embox/blob/986e0f5442bed7b5bcbb0fcab6462fd9e4367a24/...

Кажется, тут что-то не так.

Если бы я заболел (в плохом смысле) написанием своей ОС, я бы выбрал весьма извращённый путь. Устанавливаем minecraft, forge, мод OpenComputers + OpenComponents + по желанию сопутствующие моды на технологии. Суть в том, что в OC есть предустановленная OpenOS (можно менять на полностью свою ОС) с примитивными фс, драйверами, пакетным менеджером и даже примитивными аналогами wget и pastebin. Один человек с русского ютуба (EliteClubSessions) упоролся и написал свою ОС с мимикрией под макось. Вообще ВСЁ пишется на луа, рантайм по умолчанию оригинальный, написанный на си, все программы (даже сама ось) интерпретируются, а не компилируются - получаем гибкость генту вместе с простотой и скоростью установки как у бинарных дистров.

Правда все юз кейсы огарничены только майнкрафтом. Зато можно самому не паритья с драйверами, а проектировать дизайн ОС, всякие важные штуки типа формат пакетов, стандарты ipc, event loop’ы для серверного ПО, программ с гуем… Там есть и десктопы, и серверы, и переносные планшеты, и передвигающиеся роботы, и мониторы от 1х1м до «на всю стенку». Можно автоматизировать фермы, шахты, строительство мегапостроек, управлять ядерными реакторами через программы, управлять 3d голограммами, на 3d принтере печатать разные модели и использовать их как декор. При этом надо оптимизировать программы, на каждый виртуальный комп серьёзные ограничения по ОЗУ и ЦПУ.

Если упёрся в ограничения мода - опенсорсный OpenComputers, в отличие от проприетарного ComputerCraft, позволяет править исходники «под себя» (вроде как написан на скале).

Работы хватит на много месяцев даже в режиме «8 часов в день».

Есть небольшое community. Можно троллить «да я целую ОС написал на луа, зачем мне ваш си с указателями?».

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

Невзирая на извращённость Пути, вывод вполне серьёзен:

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

Думаю, для получения этого результата есть и более гуманные методы. :)

Тут надо разбираться.

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

Конкретно в приведенном случае mmap_alloc есть только один. он может вернуть по идее ошибку,если не нашлось подходящего куска в адресном пространстве процесса. При этом не важно как устроены адресные пространства изолированные адреса или единое адресное пространство для всей системы. Но опять же в приведенном случае, execv_syscall только с виртуальной памятью и подргузкой из образа в отдельное пространство.

Если все таки хочется узнать как реализован exec без виртуальной памяти, точнее с единым пространством, то нужно посмотреть в файл src/compat/posix/proc/exec.c ну и вокруг него. vfork() например

По поводу функции mmap_create_stack есть еще два три важных замечания:

uint32_t mmap_create_stack(struct emmap *mmap) {
	size_t size = 4096; // а почему тут, почему нет какого-нибудь дефайна STACK_SIZE чтоб была конфигурируемость ?
	uintptr_t base = mmap_alloc(mmap, size);
	mmap_place(task_self_resource_mmap(), base, size, 0);
	vmem_map_region(mmap->ctx, base, base, size,
			PROT_WRITE | PROT_READ | PROT_EXEC | VMEM_PAGE_USERMODE); // правильно ли назначать PROT_EXEC для стека? Это чтоб трамполины из GCC работали?
	return base + size; // А разве стек всегда снизу вверх растет?
}

И еще по поводу стека

static inline uint32_t stack_push_str(uint32_t *stack, const char *str) {
	*stack -= strlen(str) + 1;
	memcpy((void *) (*stack), str, strlen(str) + 1);
	return *stack;
}

static inline uint32_t stack_push_int(uint32_t *stack, uint32_t val) {
	*stack -= 4;
	memcpy((void *)(*stack), &val, 4);
	return *stack;
}

Функция stack_push_str может записать строку произвольной длинны т.е. значение stack может быть не кратно 4 байтам - нехоршо.

Да и вызов функции memcpy несколько настораживает, я б использовал что-то типа __builtin_memcpy хотя вы наверно не только совместимые с GNU __builtin компиляторы поддерживаете.