AS>>linux kernel 2.6.13 — версия ядра линуха.
P>Что это версия ядра линуха, и так понятно. Вы хотите сказать что там есть MSIL to x86 JIT compiler? Надеюсь объяснять не нужно, что это такое?
Вы напишите обработку прерываний для железа на managed code.
Ради спортивного интереса решил заняться этим вопросом. Ну, конечно, не написать обработчик (я не такой монстр). Решил найти ответ на вопрос – а как это вообще может быть: обработчик на managed code. Учитывая, что я профан во всём этом деле (теперь можно сказать-был), то начал искать с самого начала. Итак (чтоб не нарушать логическую цепочку), прерывание – это событие в системе, генерирующееся процессором на сигналы железа. Работает так: сначала проц останавливает текущую работу, потом читает адрес обр-чика из памяти (вектор прерывания), передает по этому адресу управление. После работы обр-чика продолжает остановленную работу. И вот, вопрос "как сделать обр-чик на managed cod" превращается в: "а собственно какой адрес обр-чика мы должны вписать в память, если у нас CLR, JIT, и вообще мы не знаем, где физически находятся методы того или иного класса, ведь всё компилится в момент выполнения". А как же singularity? Ведь у них это получилось? Посмотрел её исходники. А просто в ней нет JIT. Во время запуска ОС всё уже скомпилино, и их хитрый компилятор Bartok скомпилил HALClass.cs, сказал загрузчику, где там что получилось по каким адресам. И загрузчик SINGLDR тоже уже скомилен с этими сведениями.
И вот, у нас получается два пути:
1) Сложный. Путь сингулярити: заранее скомпилить части ОС, и при установке ОС ставить уже x86-образы
2) Ещё сложнее. Написать архи-компактный JIT, состоящий из 1 файла, который будет запускаться из загрузчика, компилить HAL в момент загрузки ОС, возвращать всю инфу о HAL в загрузчик, который настроит все векторы прерываний.
Простого пути нет, и на коленке это не сделать.
Для тех, кто хочет взять всё готовое, и из них что-то сделать, путь есть: качнуть Linux, Mono, и вуаля! Всё сделано без единой строчки кода!
А так, это надо брать, изучать и делать. Это сложно, но возможно!!! Есть смельчаки? Ведь проект на самом деле очень интересный. А главное-полезный!
Здравствуйте, Муравей, Вы писали:
М>Здравствуйте, AndrewVK, Вы писали:
AVK>>Здравствуйте, Муравей, Вы писали:
М>>>Это скорее не ОС а средство создания оптимизированной ОС из существующих компонентов ОС. М>>>Поправте если я не прав.
AVK>>Не прав. Вобще не пойму откуда ты взял про существующие компоненты.
М>Тогда может объяснишь и не будем играть в разведчиков и военную тайну?
осов на языках с защитой полно. на яве например. ставятся на голую железу. можно погуглить.
в основном используются в академических целях.
идея сингулярити в том, что отвергаются все прынцыпы аппаратной защиты через ринги, и как задачи пользователя, так и компоненты ос крутятся в одном адресном пространстве. это разумеется как ускоряет работу системы, так и упрощает ея.
если делать и ос, то в этом направлении.
делать очередную обычную, классическую ось — тока время тратить. есть просто тулкиты для таких развлечений.
собираете свою ось на коленке, ставите на железку.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, merk, Вы писали:
M>>идея сингулярити в том, что отвергаются все прынцыпы аппаратной защиты через ринги
AVK>Не отвергает, там можно процессы создавать и так и так.
в java тоже можно вызывать native код. вопреки концепции.
и что??
если они хотят защищаться аппаратно, значит не верят в непробиваемость свой арзитектуры.
а раз не верят — значит идея дырява, и можно закрывать всю сингулярити целиком.
Здравствуйте, merk, Вы писали:
M>если они хотят защищаться аппаратно, значит не верят в непробиваемость свой арзитектуры. M>а раз не верят — значит идея дырява, и можно закрывать всю сингулярити целиком.
Если весь код управляемый то можно без аппаратной защиты.
А если захочется запустить какойнибудь легаси написанный на С/С++ итп то тут без аппаратной защиты не обойтись.
Ну или как вариант сделать программную виртуализацию и JIT'ить машинный код вставляя проверки.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, merk, Вы писали:
M>осов на языках с защитой полно. на яве например. ставятся на голую железу. можно погуглить. M>в основном используются в академических целях.
ОСь на жабе там навсегда и останется.
Ну не приспособлена жаба к создания чегото серьезного.
По уму ей и надо было оставаться в кофеварках.
M>идея сингулярити в том, что отвергаются все прынцыпы аппаратной защиты через ринги, и как задачи пользователя, так и компоненты ос крутятся в одном адресном пространстве. это разумеется как ускоряет работу системы, так и упрощает ея.
Это всеголишь побочный эффект.
Цель была в том чтобы создать ацки надежную ОСь в которой никто не может наломать дров.
Это получилось на столько хорошо что можно даже выкинуть аппаратную защиту.
Единственная дырка которая у них осталась это DMA. Хотя если доработать железо чтобы обращение через DMA было контролируемым...
M>если делать и ос, то в этом направлении.
Тут все не просто, а очень не просто.
Главная проблема в том что на данный момент нет виртуальной машины (ну или я по крайней мере такой не видел) чья модель подходит для создания ОС.
M>делать очередную обычную, классическую ось — тока время тратить. есть просто тулкиты для таких развлечений. M>собираете свою ось на коленке, ставите на железку.
Linux?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Единственная дырка которая у них осталась это DMA. Хотя если доработать железо чтобы обращение через DMA было контролируемым...
Уже доработали, называется IOMMU. Скоро в обычных компьютерах появится — чтобы можно было ускорители в видеокартах нативно в виртуалках использовать.
WH>Главная проблема в том что на данный момент нет виртуальной машины (ну или я по крайней мере такой не видел) чья модель подходит для создания ОС.
И не будет. Рулить должна микроядерная ОСь с очень маленьким ядром (которое можно формально проверить на корректность), которое уже занимается управлением изолированых задач.
Иначе имеем проблему курицы и яйца — для реализации виртуальной машины нужен достаточно большой объём небезопасных техник (типа прямого доступа к памяти в GC или генерации маш. кода в JIT), которые НЕ МОГУТ БЫТЬ формально проверены.
Здравствуйте, Cyberax, Вы писали:
C>Уже доработали, называется IOMMU. Скоро в обычных компьютерах появится —
Тем лучше.
C>чтобы можно было ускорители в видеокартах нативно в виртуалках использовать.
Одними ускорителями дело не ограничется.
1) C>И не будет. Рулить должна микроядерная ОСь с очень маленьким ядром (которое можно формально проверить на корректность), которое уже занимается управлением изолированых задач.
2) C>Иначе имеем проблему курицы и яйца — для реализации виртуальной машины нужен достаточно большой объём небезопасных техник (типа прямого доступа к памяти в GC или генерации маш. кода в JIT), которые НЕ МОГУТ БЫТЬ формально проверены.
Тебе не кажется что эти 2 твоих утверждения противоречат друг другу?
Ибо либо нельзя доказать и то и другое либо можно доказать и то и другое.
Тк код ядра ничем не отличается от того что делает JIT.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
C>И не будет. Рулить должна микроядерная ОСь с очень маленьким ядром (которое можно формально проверить на корректность)
Что то у тебя все перепуталось. Микро и наноядра нужны, когда нет формального способа проверки, и нужно просто вылизывать код и контролировать его глазами. Если же мым ожем проверять формально (как тот же peverify, к примеру) — размер ядра значения уже не имеет, имеет значение лишь совместимость наличествующего кода с проверяльщиком.
... <<RSDN@Home 1.2.0 alpha 4 rev. 1090 on Windows Vista 6.0.6001.65536>>
