OSDev

Мне вопрос про количество ядер, показался совсем детским. Не соответствующим стилю предидущих постов.

Судя по сайту у вас совсем не технические интересы. Теперь всё понятно.

Для tlx

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

Направление ИТ не занимался уже почти 10 лет, сейчас как-то
восстанавливаю понимание что тут и как. Хотя ранее был опыт
довольно длительный программирования на ассемблере
всяких интересных штучек, а одна из них имела даже какой-то
шанс превратиться в ОС узкого применения. Поэтому извиняюсь,
если иногда плыву в технических деталях.

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

Ну, насчёт вылизанности это Вы погорячились. ARM делает (и не исправляет) ляпы даже в простых микроконтроллерных ядрах, ну а высокопроизводительные Cortex-A просто набиты ими -- и это при, в общем-то, тупо-примитивном процессоре. Быдлокодеры, к сожалению, сейчас везде -- и в разработке ПО, и в разработке аппаратуры...

Скорее, нужны и динозавры, и букашки. Вон, в 1980-х все, кому не лень, обещали гибель мэйнфреймов в ближайшем будущем -- а они по-прежнему живее всех живых, в следующем году будем отмечать 50-летие IBMовской архитектуры (ибо современные их мэйнфреймы по прикладному коду по-прежнему совместимы снизу вверх с Системой 360, анонсированной ещё в 1964 году).



Никакой стандартизации даже контроллера прерываний под ARM долгое время не было, она появилась лишь в последних версиях архитектуры -- ARMv7 (ядра серии Cortex) и ARMv8 (64-разрядные процессоры). Однако до сих пор активно производятся и продаются процессоры и контроллеры предыдущих версий архитектуры вплоть до ARMv4T -- здесь дело как в инертности промышленной автоматизации, так и в том, что более высокая производительность и всякие дополнительные плюшки новых версий далеко не всегда нужны в конкретных применениях (это дубовым ОС на планшетах и телефонах сколько ни давай вычислительной мощности и памяти, им всё мало). Понятно, что о стандартных "мамах" тем более никакой речи не идёт.

Я у себя этот вопрос решаю просто. Общая часть кода системы мало зависит от конкретного процессора. Зависимость проявляется в наличии/отсутствии тех или иных команд, что решается мной с помощью условной трансляции и макросов. Например, у меня есть пара макросов _LDRD и _STRD, которые используются в случаях, если мне надо загрузить или сохранить в памяти пару регистров общего назначения. Если система транслируется под архитектуру, не поддерживающую систему команд Thumb-2 -- а это почти все старые версии архитектуры, кроме ARMv6T2, эти макросы разворачиваются в пару команд ldr или str, загружающих/сохраняющих один регистр, ну а если Thumb-2 поддерживается -- то в одну команду ldrd или strd. Благодаря этому у меня общая кодовая база под любую версию архитектуры.

Оставшаяся часть кода зависит от конкретной модели или семейства процессоров. Например, настройка процессора на конкретную тактовую частоту полностью зависит от модели процессора, ну а настройка контроллера памяти -- от процессора и платы, на которой он установлен (поскольку микросхемы памяти могут быть разными; то же самое имеет место быть и на ПК, но для обычного и даже системного программиста это не играет роли, поскольку всю настройку выполняет BIOS, который в мире АРМов отсутствует в принципе). Эти вещи решаются с помощью макросов: для каждой модели процессора и/или платы имеется свой их набор.

Наконец, периферия по понятным причинам также зависит от модели процессора и от платы. Здесь уже используются разные драйверы.

Что касается "преемственности", то она имеется лишь на уровне системы команд: совместимость "снизу вверх" сохраняется, за исключением некоторых случаев, но те случаи легко обойти, поскольку они весьма специфичны и в "нормальной жизни" просто не случаются. Ну, плюс ещё ошибки в процессорах, что тоже может создать проблемы, если их не учитывать.

Для SII

Полностью согласен с Вами, что нужны и маленькие, и динозавры.

Тут пожалуй лишь вопрос по теме форума - возможна ли архитектура ОС,
эффективно работающая и на тех и на других. Локализация естественно
потребуется, но возможно ли принципиально общее решение?

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

Тема NewOS здесь заведена не в том смысле, что кто-то сел и пишет
уже ее в деталях и подробностях. Это попытка как-то конструктивно обсудить
саму возможность создания таковой. В режиме - а давайте помечтаем, но только
в потенциально реализуемом русле.

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

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

Вопрос в том, что само наличие 100500 архитектур ничем не оправдано...
Кроме опять, же, "экономики капитализма"...

Системный подход к этому делу если когда и был, то кончился в прошлом веке А решение для разруливания "выросло", естественно, максимально дешёвое - linux.

Кстати, про Линукс. Прочитал только что книжку Линуса и можно поделиться
некоторыми соображениями и выводами. А что-то могли бы и обсудить,
например, выводы Линуса по MacOS.

Мне, как интересующемуся общей теорией систем, была
интересна сама формула успеха. Собственно ничего принципиально
нового Линус в ОС не предложил, это всего лишь "fork" с UNIX. Софт с
открытыми исходниками и соответствующие лицензии тоже не Линуса
изобретение. Но его громадная заслуга, что он соединил множество
полезных принципов и выдал на гора сбалансированное решение.

А вот дальше самое интересное. Мало ли таких талантливых
изобретателей, которых просто затоптали, так как они угрожали
каким-то более-менее крупным корпорациям. А тут пойди же...
Секрет же на мой взгляд весьма прост. Линукс как открытая ОС оказалась
очень выгодна Мелкософту. Можно вспомнить огромные иски
к Гейтсу и все шло к антимонопольному решению о разделе
компании, примерно также как в свое время разделили AT&T.
Линукс спасла Майкрософт от этого, а попутно и замочила
практически окончательно вполне конкурентоспособное
альтернативное решение - UNIX. К тому же открытые
исходники позволяют Мелкософту пользоваться бесплатным
ОКР мирового сообщества программистов.

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

Не смешите. Linux появился 98 году. До этого считай что его не было. Было нечто не жизни способное.
К этому времени Макрософт имела зоопарк ОС: DOS, OS/2, Win NT 4, Win 95, Win 98. При этом с разными архитекторами!
Да и на западе ОКР принято проводить в вузах.
Да и нет сообщества Линукс программистов. Есть с миру по нитке, которые просто смешали в кучу.
Даже есть мнение, что утекшие исходники виндоуса NT 4 и Win2k специально открыли чтобы Линуксойды смогли скопировать её.