Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, _Oswald_, Вы писали:
_O_>>Вот наткнулся на такой вот проект: Cosmos. На рсдне ссылок не нашел. _O_>>Кто что думает?
kuj>Думаю: зачем?
Написать Linux .NET
Здравствуйте, _Oswald_, Вы писали:
_O_>Здравствуйте, kuj, Вы писали:
kuj>>Ясно одно — проект мертворожденный.
_O_>С чего такие выводы?
Интересно, как там будет сделана работа с железом (прерывания), работа в различных режимах привилегированности процессора и свопинг виртуальной памяти?
Вот пример: работа .net требует работы виртуальной машины, работа VM требует памяти, происходит прерывание (для подгрузки страницы с диска), срабатывает обработчик — на .net конечно, что требует VM... Курица и яйцо.
Здравствуйте, Aviator, Вы писали:
A>Здравствуйте, kuj, Вы писали:
kuj>>Здравствуйте, _Oswald_, Вы писали:
_O_>>>Вот наткнулся на такой вот проект: Cosmos. На рсдне ссылок не нашел. _O_>>>Кто что думает?
kuj>>Думаю: зачем? A>Написать Linux .NET
Здравствуйте, _Oswald_, Вы писали:
_O_>C# Open Source Managed Operating System.
_O_>Кто что думает?
В принципе, ничто не мешает делать на цэшарп операционки (хотя встаёт вопрос, как они добираются к железу, будучи managed?).
Однако ж, не факт, что сама .NET есть идеальная платформа для реализации. Почему бы ребятам не велосипедить, а поддержать,
например, Oberon?
Здравствуйте, Andrbig, Вы писали:
A>Интересно, как там будет сделана работа с железом (прерывания), работа в различных режимах привилегированности процессора и свопинг виртуальной памяти?
A>Вот пример: работа .net требует работы виртуальной машины, работа VM требует памяти, происходит прерывание (для подгрузки страницы с диска), срабатывает обработчик — на .net конечно, что требует VM... Курица и яйцо.
Не совсем так.Тут есть их интервью
Это ведь не первая VM OS. Та же Singularity, например.
Let's go a bit deeper into the "basic" design. In Singularity v 1.0, the lowest-level x86 interrupt dispatch code is written in assembly language and C. After that part has completed its goals, it summons the kernel, whose runtime and garbage collector are written in C# and its extensions and run in unsafe mode. The hardware abstraction layer is written in C++ and runs in safe mode. How can you describe your own "basic" design in that sequence.
Chad Hower : Our hardware abstraction layer is C#. Only items such as emitting values to ports which we map to op codes are written in assembly in Cosmos. The number of lines of assembly that exist outside of our compiler is probably less than 10. One of our major goals was that developers, even low level kernel developers could stay purely in C# and not have to resort to using multiple languages.
Scott Balmos : As with all VM-based operating systems, the first step after being handed boot control by the boot loader is a precompiled image — a native blob, if you will. Its purpose is to initialize the platform-specific hardware with sane defaults (e.g. load temporary ISRs, set up memory and other defaults), prepare the JIT compiler for the runtime, and do other native housekeeping tasks.
Afterwards, the rest of the kernel is loaded from its bytecode file, and the JIT compiler starts its job. At this point, the rest of the kernel, through normal bytecode and unsafe pointer memory access, performs the rest of the system initialization, loads device drivers, and gets things going from a userspace standpoint. It's a gross simplification, but the main idea is that, like all other VM OSs, we have a very small native code nanokernel, if you will, which initializes just enough of the system in order to load the kernel proper, which is in platform-independent VM bytecode form.
Unlike Singularity, and discussed previously, all of our code is in pure C#. We have a namespace (eventually a separate assembly) for each target platform in IL2CPU, which exposes various classes that correspond to that platform's assembler opcodes (e.g. mov, cmp, jnz, and so on). And while we haven't completely written it, our ISR routines are also written in C#, using a fixed ISR dispatch method and a fixed, static ISR "needs processing" flag map.
Здравствуйте, _Oswald_, Вы писали:
_O_>>>С чего такие выводы?
kuj>>По опыту многих предшественников.
_O_>Вот если бы вы были одним из этих предшественников, я бы согласился.
Здравствуйте, Andrbig, Вы писали:
A>Интересно, как там будет сделана работа с железом (прерывания), работа в различных режимах привилегированности процессора и свопинг виртуальной памяти?
A>Вот пример: работа .net требует работы виртуальной машины, работа VM требует памяти, происходит прерывание (для подгрузки страницы с диска), срабатывает обработчик — на .net конечно, что требует VM... Курица и яйцо.
Для написания основы ядра OS нужен компилятор, который позволяет на языке писать так, чтобы генерировался бинарный код без обращений к любым библиотекам, которые обращаются к API операционной системы.
Возьмем для примера C++ и windows:
Операция выделения памяти new приводит к вызову соответствующих функций из рантайма, который в свою очередь обращается к win32 api, а они уже к native api ядра. Поэтому на C++ написать ядро будет сложновато (избегать всех обращений к рантайму). Си-компиляторы в этом смысле более чистый код могут сгенерить.
С .NET в винде тоже самое: виртуальная машина будет обращаться к API ядра.
Что нужно, чтобы писать свою OS на .NET:
Надо написать основу ядра (именно так, как я написал выше, т.е. например функция выделения памяти _своя_), которая предоставляет API для работы с железом (память, видео, винчестер итд) и делать виртуальную машину на основе этого API, т.е. везде где виртуальной машине нужна память мы подставляем нужную функцию ядра для выделения памяти (также делают моно и ротор).
Тоже самое, если сделать компилятор C++ со своим рантаймом, который обращается к API вашего ядра, то можно писать дальше ядро на полноценном C++ с классами, new итд
Ещё пример: если мы реализуем основные библиотеки Win32 API, заменив внутренности вызовами собственного ядра (не секрет, что большинство win32 функций имеют можно сказать одинаковую реализацию: генерация прерывания, означающего вызов функции из ядра OS), то сможем запускать многие виндовые программы на своей OS
В общем это всё достаточно очевидно, как и то, что это огромная и по сути неблагодарная работа.
Здравствуйте, matumba, Вы писали:
M>Однако ж, не факт, что сама .NET есть идеальная платформа для реализации.
.NET вобще для ОС ну очень с трудом подходит.
M>Почему бы ребятам не велосипедить, а поддержать, например, Oberon?
ОберонОС не выдерживают вобще никакой критики.
Они в реальном мире вобще работать не смогут. Они работают только в тепличных условиях где весь код пишется одной конторой и параноидально тестируется.
В прочем это тут уже обсуждалось. В поиск.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, matumba, Вы писали:
M>>Однако ж, не факт, что сама .NET есть идеальная платформа для реализации. WH>.NET вобще для ОС ну очень с трудом подходит.
Полагаю, что суть вопроса немного в другом — можно ли построить ОС на базе управляемого кода?
Согласен, не факт что для такой системы .net хороший выбор. Ну а какая есть альтернатива?
Здравствуйте, _Oswald_, Вы писали: _O_>Кто что думает?
Думаю, что проект прикольный. Понятия не имею, ждет ли успех его конкретно, зато вижу, что сингулярщики старались не зря.
В том смысле, что задачей Singularity никогда не было превратиться в настоящую промышленную ось.
Ее задачей было привлечение внимания коммунити к идее программной изоляции процессов.
И она со своей задачей справилась: вот народ уже всерьез задумывается о том, чтобы реализовать-таки ось промышленного уровня, основываясь на идеях Singularity.
Судя по комментариям, 99.5% народу полагает что Managed OS — это оксюморон. "А как же она будет обращаться к железу" и т.п. Точно так же в свое время народ считал, что системы с автоматическим управлением памятью непригодны для "настоящего" программирования. Эволюция софта — это прежде всего эволюция мышления разработчиков. И вот мы ее наблюдаем своими глазами.
Лично я сильно глубоко в космос вдаваться не буду — мне интересны решения для конечных пользователей, а такой платформенный хардкор от них слишком далек. Но искренне желаю парням удачи — по крайней мере, опенсорсная природа проекта даст большому количеству народа доступ к тем граблям, на которые они еще наступят. Эти грабли, возможно, лягут в основу того софта, который мы будем видеть повсеместно в двадцатые годы.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, _Oswald_, Вы писали:
_O_>Согласен, не факт что для такой системы .net хороший выбор. Ну а какая есть альтернатива?
На данный момент я ни вижу хорошей ВМ для создания подобной ОС.
Уж очень другой она должна быть чем те что делают сейчас.
Сейчас есть либо .NET, Java итп в них нет вобще никакой формализации системы. По тому в них постоянно возникают всякие тупые проблемы типа того что невозможно использовать арифметические операторы в генериках.
Либо хаскель и компания эти построены на математических теориях которые не учитывают то что ресурсы компа весьма конечны, также они игнорируют имеративщину (а значит огромное колличество крйне эффективных алгоритмов и структур данных) и любой компонент системы может отвалится в любой момент. Также они игнорируют компонентность (ну не дружат хаскелевские классы типов с компонентностью) что тоже есть плохо.
Поделки тапа оберона где одно объектное пространство на всех и любой объект в системе может получить прямую ссылку на любой другой объект вобще рассматривать не имеет смысла.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
