Comments 42
Шикарно!
Это для развлечения или есть какие то далеко идущие планы?
p.s. без драйверов, любая затея разработать операционную систему к сожалению обречена на провал
Даже если удастся получить доступ к сенсорному экрану, то остается радиомодуль (а это не только мобильные сети но и wifi), звуковая карта, видеоускоритель.. да тут вопрос, можно ли хотя бы усыпить железку корректно.
В первую очередь для развлечения, а там буду пробовать ковырять дальше, пока сил хватит. Конечно, я не претендую на создания "убийцы андроида"). В теории, этот проект переносим на какие-то одноплатные ПК, например, raspberry pi. Так что, вполне можно придумать какое-то прикладное применение.
Кстати, по поводу выключения железки. Под боком есть исходники загрузчика и ядра. Сам по себе загрузчик реализован не сложно. Значит это должна быть посильная задача.
Очень круто! Я на такие низкоуровневые штуки смотрел как тёмную магию, а оказывается не так уж и сложно.
подождите. а bluetooth? там же есть отличный bluetooth. гальванически развязанный. это он чего может тогда делать. прошивку чтоли обновлять. с ардуиной общаться. но зачем. а он вам нафига? примерно. retrofit чтоли какой-то делать. (к станку присобачить) Educational ? "Забить Мике баки". была же RTLinux. и сплыла. но код то остался, пальчики-то работу помнят. VAX был. ну Educational в общем.
Блин, прикольно! Я не ковырял квалки на настолько низком уровне, но не ожидал что там всё относительно просто - по крайней мере для вывода картинок, общения через UART и возможно дерганья GPIO откуда-нибудь :)
Я тоже выкидывал Android, но оставлял Linux и писал прям так.
Раз уж подпаялся к uart то неплохо бы и вывод при старте смарта выложить (или URL где посмотреть). И да, меня вполне классические инструменты типа GCC и tcc устраивают. Если надо высокоуровневый - пожалуйста: vala, nim lang. А слобво Безопасность, уж извините, вызывает аллергию (всё ради вашей безопасности)
Какой ужасный синтаксис у этого вашего Rust.
Вкусовщина же, не?
Разумеется. Только мне его не осилить даже под гипнозом.
Мне наоборот он нравится, синтаксис явный, что написано, то и будет, никаких скрытых махинаций, преобразований или непонятных порядков вызова убойного набора конструкторов, и даже почти LL(1)
скрытые махинации в нем все же присутствуют, за что Торвальдс его ругал. сам никак не соберусь детальнее разобраться
Я попытался вспомнить всё неявное в Rust, пока ехал с работы , времени было полно повспоминать, нашёл только три случая:
1) создание копии через маркерный трейт Copy, это когда он сам создаст вам копию переменной, чтобы передать её в функцию/замыкание, работает на простых типах, которые можно дешево скопировать, либо на выведенных через derive/руками реализованных алгебраических типах, это легко понимается просто из соображений с каким типом работаем и как быстро его можно скопировать
2) автоматическое разыменовывание ссылок/умных указателей, тут тоже легко понять что сырой указатель в safe rust не имеет смысла
3) неявный вызов drop, всё, что выходит за область видимости или при потере владения он будет немедленно уничтожать
Если найдёте ещё что-то - готов обсудить
По сути все три случая просто синтаксический сахар в том смысле, что вы можете и явно их выполнить, первую через трейт Clone, вторую руками разыменовать, третью так же руками вызвать drop в любом удобном вам месте, но почему они существуют? Очевидно уменьшить бойлерплейт, ибо в любом контексте итак понятно, что другой вариант не имеет смысла вообще, разве что у вас прям в этой критической секции нельзя копировать или освобождать память, там какие-то важные операции паралельно начались, но тогда вызывайте явно где удобно,в чем проблема, Rust примет к сведению и вашу копию и что объект уже дропнут раньше, чем там гражданин Линус не доволен не знаю, может вы его не так поняли и он наезжал на что-то другое?
Есть ещё неявный вывод типа... Но это не совсем операция, которая попадет в бинарник, поэтому не знаю стоит ли считать, в любом случае если компилятор хоть немного не уверен что правильно понял ваш тип он вам об этом сообщит и ничего не соберёт, я бы это не считал за неявную операцию
вроде всё, всё остальное там явно, это уберегает от многих сюрпризов при отладке, в проде или чтении листинга неизвестной вам программы. Вопросы в стиле "а что выведет вот эта программа" как принято в C++ там не уместны, не нужно собирать конференции, где десяток гиков будут до хрипоты спорить какой же конструктор тут вызовется, что к чему будет неявно преобразовываться и в каком приоритете произойдут операции, взглянув на текст программы вы можете однозначно сказать чем кончится дело
По поводу LL(1):
Если на пальцах, вот возьмём строчку
(x) * y
В термах C/C++ это может значить три разных операции
Привести к типу x значение из адреса y
Помножить x на y
Объявить указатель на y типа x,
А может быть и 4 вариант - если * перегружена для x,y, зависит от контекста
В LL(1) языках такого нет, там нет неоднозначности, всё явно, в Rust привести y к x - это y as x
Помножить x * y
Объявить - let y:x
Мне не нужно много контекста и листать код туда сюда выясняя как определена операция для данного случая
Это все не то. В принципе, быстрогуглкопилотенье, дает ответ на вопрос. Спросил про "hidden calls in Rust language", " hidden panic calls", " hidden memory allocations" и " when memory allocator fails".
Tldr: пока что ОС на Rust нельзя применять если памяти может не хватить. Упадет внезапно и ты никак не контролируешь процесс.
Не знаю о чём вы, но аллокаторов много разных бывает, хотите свой пишите, Rust явно не ограничивает вас, это не относится к языку вообще никак, пишите no_std и он не будет выделять в куче вообще ничего сам, как и в Си вообще никакого аллакатора нет и что? В ядре ОС никто в здравом уме не будет пользоваться динамическим распределением памяти, это приведёт к жёсткой дефрагментации
Kmalloc и vmalloc видимо какая то шутка
Ну я же дал как спрашивать, как раз про самостоятельное аллокирование в каких случаях производится. Там все развернуто
Отключайте аллокатор, в чём проблема, он не будет ничего аллоцировать, как в чистом Си, проблема аллакатора не имеет отношения к языку
Глянул повнимательнее - все, что может аллоцировать, выкидывается при #![no_std] , как и написано в документации. Другой дороги нет.
Как при этом возможно писать (без Rc, String etc), я не особо понимаю, пусть специальные люди занимаются. Вот есть замена для std, возможно поможет.
В Rust есть модули core, alloc и std. std включает в себя core и alloc. В no_std окружении никто не запрещает использовать то что есть в core, а если есть возможность динамического выделения памяти - то и alloc добавляется, вместе со всеми своими Rc, String, Vec и т.д. А даже если alloc нет (может на микроконтроллерах каких так получится что нет возможности задействовать аллокатор), то часто можно обойтись крейтами типа heapless.
А что в нем ужасного, на ваш взгляд? Я дотнетчик, но для меня раст по читабельности вполне симпатичен. У того же го, на мой вкус и цвет, сильно хуже читабельность.
На вкус и цвет, для системного программирования где цена ошибки высока, такая ужасная многословность и строгость скорее благо, чем недостаток)
Зачетная статья. Жду продолжения :)
надеюсь, в следующей статье телефон сможет выполнять хотя бы самые базовые функции - звонить по зашитому в код номеру
Для современного смартфона это, конечно, базовые функции, но с точки зрения реализации, работа с радио модулем очень сложная задача.
получается sms тоже?
В смартфонах, то что касается устройств типа: bluetooth, wi-fi или радиомодуль имеет свои закрытые проприетарные части. У этих контроллеров есть даже свои отдельные ОС. В отличие от самоделок, типа модулей подключаемых к ардуино, где все задокументировано, открыто, и все интегрируется на более высокоуровневом интерфейсе.
Честно говоря, я вообще пока понятия не имею как конкретно это можно реализовать, и можно ли вообще.
Я видел, что Redox пытались запустить на телефоне, можно попытаться повторить: https://redox-os.org/news/this-month-250930/.
Как думаете, можно ли такое провернуть на яблочных девайсах?
Скорее всего на современном Айфоне такое провернуть будет практически невозможно: заблокированный загрузчик, проверка подписей, отсутствие открытой документации по железу.
Можно, если вы найдете zero-day уязвимость в самом первом, зашитом в ROM загрузчике)
Такие уязвимости находили для старых айфонов (например, checkm8), и это позволяло запускать свой код. Но для современных устройств это задача практически нереальная
На 3GS вроде Linux заводили. На современных пока даже джейлбрейка нет.
Практической пользы от этого конечно никакой, но как образовательный проект - 10 из 10. Собрали неплохой такой тренажер по системному программированию, прям от ассемблерной загрузочной вставки до парсинга DTB и вывода на фреймбуфер
Где вы этому научились? Есть какая-нибудь классная книжка на эту тему или это результат многолетнего собирания информации по крупицам?
Общее поверхностное понимание архитектуры ОС: Эндрю Таненбаум - Современные операционные системы. Когда-то еще игрался с x86. По этой архикетуре много информации в интернете. Например, известный ресурс https://wiki.osdev.org/. ARM во многом отличается от x86, но общие принципы схожи.
Исследование загрузки ядра - результат реверс-инжиниринга ядра ОС, и TWRP загрузчика. Так же на github есть исходники загрузчика ABL. По нему можно понять требования к формату ядра.
Драйвера устройств и DTB - исходники ядра Linux. Там же есть описание процесса бута Linux aarch64.
Конечно, не обошлось без ИИ. ИИ помог разобраться с нюансами, и отладкой ошибок.
P.S. На самом деле на подготовку этой части и частично второй части по выходным ушло около 4 месяцев
А код где-нибудь выложен? Было бы интересно поиграться.
Не хотел публиковать код первой части, потому что тут все еще хрупкое. Во второй части хотя бы будет поддержка QEMU. Но если хотите, то я выложил на гитхаб. https://github.com/AlexanderShirokih/rustos/
а был ли смысл писать на Rust c таким количеством ассемблера и unsafe секций...
Лучше бы Armbian туда засунул, был бы карманный пк
Пишем свою мобильную ОС с нуля на Rust