ОС на .Net - Открытые проекты

Здравствуйте, VladD2, Вы писали:

VD>>>2. ЖЦ.

V>>Boehm — классика

VD>В лес такие ОС! Мало того что он дерьмо полное, так еще и пол кода вашей ОС будет на С++ написана. Причем это не ОО-код, а низкоуровневневая дергатня с указателями. Багодром, короче.

Сдается мне, что GC — это такой черный ящик для нас, с очень миниатюрным АПИ. Другими словами, абсолютно фиолетово, какой именно GC будет реализовывать это АПИ.

И вообще, ты всерьез считаешь, что для начала моделирования нужен самый лучший GC? (вопрос в силе и для всего остального).

И еще, Boehm — очень неплохой GC, и небольшой по размерам исходник. Будет желание — можно будет попытаться перевести на unsafe C#.

VD>>>3. Шедулер задач.

V>>

V>>нам прямо сейчас требуется самый качественный шедуллинг??? А если подойдет "обычный", то есть море инфы и реализаций

VD>Что значит сейчас? Это нужно в принципе. Без этого будет не ОС, а МС ДОС.

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

Опять же, шедуллинг — это тоже весьма миниатюрное АПИ.

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

V>>Ротор — нет, MONO — да. По Ротору самые интересные части не показаны (в первой версии, вторую не смотрел)

VD>И каких же таких частей нет в Роторе, что есть в Моно? Единственное с чем могу согласиться, так это с тем, что можно содержит куда меньше неуправляемого кода.

В первом роторе я не увидел исходников джита. Этот момент — самый краеугольный.

V>>А зачем Барток? А на чем, интересно ngen.exe написан? И кстати, во втором Роторе исходники ngen.exe присутствуют?

VD>А что такое по твоему Барток? Это и есть ngen позволяющий получить законченный исполяемый образ, а не только скомпилированные методы которые без рантайма можно на помойку выбросить.

Угу, и я совершенно случайно про ngen спросил...

VD>В общем, ngen нужно так напильником дорабатывать, что вы костьми ляжете на этой задаче. Куда проще доработать Феникс. Там хотя бы гтовое АПИ и компонентная архитектура подразумевающая возможность модификации поведения.

VD>К тому же ты же Ротон не хотел брать в рассчет.

Вопрос был — есть исходники ngen или нет.

Если ты так настаиваешь на Bartok, давай порассуждаем.
Предназначение Bartok — разработка VM (джит) на самом C#
Далее. Я плохо представляю себе разработку на C# без mscorlib. Понимаешь, куда я клоню? Как он запихнет в бинарный образ только то, что мне надо?

Здравствуйте, VladD2, Вы писали:

VD>Ты говорил о создании эмулятора HAL-а запускаемого внутри процесса имеющейся ОС чтобы по быстрому начать работать над управляемой частью ОС. И какие тогда могет быть проблемы с компиляцией? Используй себе рантайм от Моно или дотнета.

С компиляцией действительно, проблем нет. Проблемы в исполнении. В этой ОС свой, немного "другой" рантайм. MONO я рассматриваю лишь как источник исходников.

V>>И при чем тут имеющийся C#??? Для такой ОС с плоской памятью нужен несколько другой джит (это отдельная тема). Т.е. эмулятор такой ОС — это нативное приложение, в которое загружается джит (вернее VM). Этот джит исполняет все остальное.

VD>Мозги то не компостируй. Ты говоришь о эмуляторе ХАЛ-а. Вот о нем и говори.

Да плевать на HAL, речь не о нем, а об организации процесса разработки на имеющихся ср-вах.

VD>Короче, говорит тут больше не о чем. Ты сначала сам делашь разумные предложения, а потом топишь их же в своих же догмах.

Ты очевидно не совсем понимаешь о чем речь. Я не смогу напрямую использовать имеющийся CLR (MONO или .Net), хотя бы потому, что нам нужен полный контроль над памятью процесса, в котором производится эмуляция ОС с выбранной моделью памяти. Далее. Практически основная задача разработки состоит именно в разработке особого рантайма, являющегося "сердцевиной" ОС. Этот рантайм слишком специфичен, и на мой взгляд, имеющиеся рантаймы ничем не помогут, кроме как своими исходниками.

Остальные подробности, на которые обращал внимание ты — эмуляция каких-то портов, или качественный шедуллинг... Это просто полная ерунда. Каждая ОС имеет некое внутреннее АПИ. Брать имеющиеся на данный момент решения для реализации аспектов этого АПИ — вполне нормальный подход, даже если характеристики этих решений в чем-то не очень хороши. Их главное достоинство в том, что они есть прямо сейчас и заведомо работают.

VD>Я не верю в ваши возможности. Еще раз повторюсь, тут объем работы такой, что несколько орлов собравшихся от нечего делать вряд ли что смогут сделать. И модели тут не причем. Тут прчем такие вещи как мотивация, время, знания.

Мне как раз кажется, что запустить работающее "нечто" не так сложно. Пусть это даже трудно будет назвать полноценной ОС, фан не в том

Здравствуйте, VladD2, Вы писали:

4wd>>Во-вторых, что делать с драйверами? На каком коде писать драйвера? Делать их модулями ядра?

VD>Ну, ты крут. BSD не позволит тебе это сделать. Она микроядерная!

NetBSD — это ОС для embedded-устройств, монолитная. Работает с плоской моделью памяти.
Кстати, ядро поганое. Я бы присмотрелся к ucLinux.

Здравствуйте, vdimas, Вы писали:

V>В первом роторе я не увидел исходников джита. Этот момент — самый краеугольный.

Плохо искал. Ротор собирается и работает, что, как сам понимаешь, без JIT невозможно.

... << RSDN@Home 1.2.0 alpha rev. 624 on Windows XP 5.1.2600.131072>>

Здравствуйте, vdimas, Вы писали:

V>Сдается мне, что GC — это такой черный ящик для нас, с очень миниатюрным АПИ. Другими словами, абсолютно фиолетово, какой именно GC будет реализовывать это АПИ.

Фиг там. На ЖЦ слишком многое опирается. И сам ЖЦ опирается на джит и среду исполения. Так что это очень важная и сильно интегрированная часть системы. Сменить простой ЖЦ на сложны — это значит переделать всю.

V>И вообще, ты всерьез считаешь, что для начала моделирования нужен самый лучший GC? (вопрос в силе и для всего остального).

Я считаю, что для начала вообще можно обойтись эмуляцией внутри процесса (Mono/CLR).

V>И еще, Boehm — очень неплохой GC,

Как минимум он требует наличия виртуальной пмяти. И думаю, что по скорости он будет просто никакой по сравнению с ЖЦ интегрированными с компилятором. Плюс проблема фрагментации. В общем, не ясно зачем связываться с хрен знает чем когда и в Моно и Роторе уже есть готовые ЖЦ. ВОт только они опять же онменеджед (на С/С++).

V> и небольшой по размерам исходник. Будет желание — можно будет попытаться перевести на unsafe C#.

Для этого сначала нужно создать аналог Бартока.

VD>>Что значит сейчас? Это нужно в принципе. Без этого будет не ОС, а МС ДОС.

V>Не все так просто с шедуллингом. Например в виндах шедуллинг напрямую корректируется состоянием окошек процесса, что позволило в свое время реализовать адекватный ГУЙ даже на машинах прошлых лет.

Вообще-то это не так. Единственное что есть — это отем времени при вызове некоторых системных функций (Sleep, GetMessage и т.п.). А "окошки" живут на банальной кооперативной многозадачности. В общем, к проблеме ОС это не имеет никакого отношения.

V>Опять же, шедуллинг — это тоже весьма миниатюрное АПИ.

АПИ — может быть. А вот объем кода это наипервейший. Если и он будет анменеджед и из другой ОС скомунизжен, то я уже не знаю что в этой ОС будет управляемым.

V>В общем, акценты не на том стоят. Надо прорабатывать общие архитектурные решения и протоколы взаимодействия частей ОС.

А что прорабатывать то? Процессы, птоки, компилятор, ХАЛ ты вроде уже отбросил. А что остается то?

V>В первом роторе я не увидел исходников джита. Этот момент — самый краеугольный.

Значит хреново смотерл. Ключевое слово fjit. Там есть С++-ные и ассемблерные части. Плюс куча всего генерируется при инсталляции с помощью скритов и макросов.

Джит в Роторе приметивнейший, но насколько я знаю есть исслеования замещающие его более мощьными.

V>Вопрос был — есть исходники ngen или нет.

Вроде есть. Но это не важно. Для затравки хватит и дижита. А чтобы получить аналог Бартока повкалывать придется нехило. Тут уж лучше все же Феникосом воспользоваться.

V>Если ты так настаиваешь на Bartok, давай порассуждаем.

Я вообще не верю, что этот трёд во что-то выльется. Но если и выльется, то без аналока Бартока никуда.

V>Предназначение Bartok — разработка VM (джит) на самом C#

Барток — это компилятор из МСИЛ в нэйтив код. Почти нген, но позволяющий обходиться без CLR.

V>Далее. Я плохо представляю себе разработку на C# без mscorlib. Понимаешь, куда я клоню? Как он запихнет в бинарный образ только то, что мне надо?

А зачем "без"? Это проскомпилятор. К тому же он по определению сам себя обязан уметь компилировать. Причем росплатформно. Чтобы из под Виндовс-версии можно было скопилировать любую другую. Ну, и на оборот соответсвенно.

... << RSDN@Home 1.2.0 alpha rev. 620>>

Своя ось конечно лучше чем ничего...

Я вот на второй год изучения программирования немного занимался AI, шашки, шахматы и пр.
И после этого забыл про все оси вместе взятые, да простит меня Бил Гейтс.
Тем более там можно одному, но интеллектом оказался слаб

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