Здравствуйте, Pzz, Вы писали:
Pzz>Прошу прощения за занудливость, но все же, на каких именно идеях Pzz>микроядерной архитектуры идеях была основана NT?
У меня все больше складывается ощущение, что участники беседы по-разному представляют себе цели и задачи выполняемые ядром, подчас путая ядро с самой ОС. Попытка связать микроядерную архитектуру с HAL — показательный пример.
Речь шла о драйверах. Драйверы — не являются частью ядра ОС (!!! даже монолитной, не спешим возражать — идем далее). Драйвер — это ПО адаптации устройства к некоему универсальному АПИ (обычно, "внутреннему" АПИ ОС). Соответственно, драйвер может относится к чему угодно, к подсистеме ввода/вывода, например (чаще всего).
Откуда возникла путаница понятий "ядра" и "вообще всей ОС"? Из-за системы защиты памяти, реализованной на большинстве современных процессоров. Многие подсистемы ОС: ввода/вывода, планировщик, сситема управления виртуальной памятью, системы мониторинга и даже загрузчик (!!!) выполняются на некоем уровне исполнения (с т.з. терминов конкретного процессора), на котором выполняется и ядро ОС. Непонятно с чей легкой руки, механизм исполнения на уровне ядра стали отождествлять с самим ядром. Задача ядра ОС — это координация подсистем ОС. Даже за запуск/поддержание/уничтожение пользовательских процессов отвечают сразу несколько подсистем, которые традиционно не относят к ядру (я уже молчу об оконной системе виндов, которая развалила ту саму микроядерную архитектуру NT, странно, что здесь сразу не ответили на этот вопрос — что именно нарушило первоначальные микроядерные задумки в NT? Быстродействие тогдашних железок банально все нарушило и оконную подсистему впихнули в низкий уровень исполнения... а затем пошло-поехало и туда же впихнули все что могли ).
Попытки упростить "внутренее" АПИ ОС привели к идее микроядра. Суть — сделать "внутреннее" АПИ ядра открытым, минимальным, а значит предоставить возможность более легкого и независимого развития остальных подсистем ОС. Однако, за это приходится платить, а именно — защищать само ядро ОС. Какой набор подсистем ОС все-таки будет исполняться в "процессе" ядра (если слово "процесс" вообще применимо здесь) в микроядерной архитектуре? Это, разумеется, не специфируется, оставлено на усмотрение разработчиков. Остальные подсистемы работают в процессах за барьером механизма защищенной/виртуальной памяти.
Именно описанную хрень и обозвали "микроядром". Если в Сингулярити ядро и сами их т.н. "процессы" работают в едином адресном пространстве, то понятие "микроядра" здесь как-то не клеится. Давайте назовем это "слоеным ПО", будет ближе. Насколько я понял, Влад приписал наличие микроядра этой ОС из-за того, что встретил упоминание об использовании HAL там же (вот курьез ) В сочетании с собственным представлением о HAL как об аттрибуттике именно микроядерной архитектуры сделал такой странный вывод, ИМХО.
vdimas wrote: > > Откуда возникла путаница понятий "ядра" и "вообще всей ОС"? Из-за > системы защиты памяти, реализованной на большинстве современных > процессоров. Многие подсистемы ОС: ввода/вывода, планировщик, сситема > управления виртуальной памятью, системы мониторинга и даже загрузчик > (!!!) *выполняются* на некоем уровне исполнения (с т.з. терминов > конкретного процессора), на котором выполняется и ядро ОС. Непонятно с > чей легкой руки, механизм исполнения на уровне ядра стали отождествлять > с самим ядром. Задача ядра ОС — это координация подсистем ОС. Даже за
Хорошо, давай попробуем определить понятие ядра.
Я предлагаю примерно следующее определение:
1. Программой называется совокупность кода и данных, размещающиеся в
процессе выполнения в едином адресном пространстве.
2. "Самая главная" программа называется ядром.
В этом смысле, драйвера в традиционных ОС все же часть ядра. А
прикладные программы — нет. ОС состоит не только из ядра, но и
некоторого набора прикладных программ.
То, что драйвера от ядра как-бы отделены, не делают их не частью ядра.
Не надо путать модульность с микроядерностью.
> запуск/поддержание/уничтожение пользовательских процессов отвечают сразу > несколько подсистем, которые традиционно не относят к ядру (/я уже молчу > об оконной системе виндов, которая развалила ту саму микроядерную > архитектуру NT, странно, что здесь сразу не ответили на этот вопрос — > что именно нарушило первоначальные микроядерные задумки в NT? > Быстродействие тогдашних железок банально все нарушило и оконную > подсистему впихнули в низкий уровень исполнения... а затем пошло-поехало > и туда же впихнули все что могли / ).
Так все же, в чем заключается микроядерность NT? Не путаем ли мы ее с
модульностью?
> Попытки упростить "внутренее" АПИ ОС привели к идее микроядра. Суть — > сделать "внутреннее" АПИ ядра открытым, минимальным, а значит > предоставить возможность более легкого и независимого развития остальных > подсистем ОС. Однако, за это приходится платить, а именно — защищать > само ядро ОС. Какой набор подсистем ОС все-таки будет исполняться в > "процессе" ядра (если слово "процесс" вообще применимо здесь) в > микроядерной архитектуре? Это, разумеется, не специфируется, оставлено > на усмотрение разработчиков. Остальные подсистемы работают в процессах > за барьером механизма защищенной/виртуальной памяти.
Важно скорее не наличие механизма защиты памяти, а наличие у програм
собственного контекста исполнения.
Пример minix — микроядерная ОС для 16-битного 8086, где никакой защиты
памяти вообще не было предусмотрено.
Здравствуйте, vdimas, Вы писали:
V>Браво, начал с того, что стал доказывать, что HAL присущь только микроядерной архитектуре, закончил своими предположениями по поводу того, как это работает в Сингулярити. Браво. Но сначала согласись, что не понимал роль HAL в произвольных архитектурах.
Микроядро это и есть ХАЛ. Что до предположений, то ты только ими и сыплешь.
V>Конкретно по твоему вопросу. Ставлю 5 баксов, что таймер они все-таки включат в HAL а не в драйвер, невзирая на легкость вызова в среде единого адресного пространства
Нда, серьезные деньгий.
V>Есть такая фигня как целессобразность, я почему-то уверен, что разработчики обсуждаемого сабжа этим понятием пренебрегать не станут.
Согласен, что простую задачу можно и в ядро всунуть. Вопрос только в том, что для сегодняшних ОС выбор того куда запихнуть таймер определяется проблемами производительности возникающими в следствии аппоратной изоляции адрессных пространств, а в ОС вроде Сингулярити и Оберон в основном архитектурные соображениями. Так что несомненно целесообразностью, но она родимая, может быть ой какой разной.
VD>>Ага колосальная проблема. Ведь на сегодны все серверы забиты 5 и более гигами памяти, а 64-битных процессоров не видно даже в подзорную трубу. Согласен. Надо будет ее обсудеть... в "Колегах".
V>Обсуди. У меня в студии плагины типа Решарпера + Rational XDE + весьма большие проекты. В общем, 2-3 студии с разными солюшинами открыл и 2 гига памяти под завязку.
У меня постоянно 3-5 студий и никаких проблем в 1 гиге. При этом еще куча софта, а память около 600 метров отедено. РеШарпера правда нет. Он глючит еще, а мне и того что есть хватает. Но это все лирика.
А правда жизни такая. Памяти у меня 1 гиг. Процессор у меня АМД 64. Так что проблем с 10 и более гигами не будет. Были бы они нужны. К тому же времени когда ОС вроде Сингулярити решатся пустить на поток, ну, в смысле, использовать ее как пилотную, но все же коммерческую ОС, пройдет еще лет 5-10 и компов без 10 гиг и не с 64-битной архитектурой просто не будет. Так что это не вопрос.
Если же сделать менее прожерливый ЖЦ, то глядишь можно будет даже сэкономить на памяти.
V> А когда отлаживаешь работу дизайнеров в этих же проектах (т.е. запускаешь саму студию как процесс для отладки), и используешь отладку unmanaged+managed — то вообще труба.
Может у тебя с ХДЕ проблемы?
VD>>Насколько я понял прикладные процессы в Сингулярити приципиально обязаны быть безопасными.
V>Т.е. и драйверы тоже, правда же?
Да. Но само ядро может содержать небезопасный код. Тот же ансэйф шарповский проходит на ура. Так что особо тонкие места общения с железом можно будет оптимизировать. Вроде как ЖЦ использует ансэйф-код.
V>OK, здесь действительно возможны решения (насчет pre-JIT).
И я о том же. А у них в руках Барток — оптимизирующий компилятор из исил-а в машинный код. Так что это у них уже есть.
V>Вообще-то мы "зацепились" после моего предположения, что с их концепцией им потребуется довольно высокая абстракция от железки, т.е. некий приличный базис "unsafe" должен будет существовать для конкретной железки.
Вопрос сколько того ансэйфа. Согласен, что для доступа к портам, ДМА, прерываниям и реализации ЖЦ им без ансэфа будет туго. Но это если код минимизировать не так уж много. Темболее, что ансэйф != анменеджед, т.е. 80% кода все же будет безопастным, а опасные куски будут все в коде как на ладони и их проконтролировать будет не сложно.
Я конечно понимаю, что все это легко в теории... Но на то у них и иследование. Не факт, что не найдется одна гадость которая все испортит, но если все выгорит (а соудя по тому, что они рассказали о проекте у них такая уверенность уже есть), то возможно это действительно станет следующим шагом.
V>Почему я делаю такое предположение? Глядя на происходящее в мире Java-встраиваемых устройств. Речь идет о переносимости, причем переносимости не только пользовательстких приложений, но и кода самой ОС (который немаленький).
Разработчики Сингулярити как раз постоянно акцентируют внимание на том, что у них все совсем не как во встраеваемых Явах. Они указывают только на какую-то одну реализацию (какю не помню) и то говорят, что там мол не все честно.
V>Стараться сделать ВСЕСЬ КОД ЯДРА управляемым элементарно НЕЦЕЛЕСООБРАЗНО (т.е. опуститься до уровня inp()/outp() и не выше).
Ну, этот уровень это уже неплохо. Согласись! К тому же что говорить о чем-то в разрезе предположений когда есть четкие заявления, что в ОС даже ансэйф применяется в очень ограниченных количествах, а все драва исключительно безопасные (в том числе и драйвер консоли/видюхи).
V> Опускание на такой уровень абсолютно ничего не дает управляемой ОС, чей фокус заострен все-таки на немного других моментах. После прочтения последних их отчетов (до этого последний раз читал более полугода назад), мне кажется, что я скорее прав, чем нет.
Ну, мне кажется что скрее неправ. Тут скорее другая проблема будет. ОС может оказаться медленной относительно традиционных. Они слишком подчеркивают, что не производительность для них не главное. Ну, да исследования не делаются ради получения работающего результата. Важнее получаемые данные. В конечной ОС возможно будет учтен опыт и Синкулярити и традиционных микроядерных ОС вроде БСД и в итоге получится очередной гибрид, но на новом уровене. По крайней мере хочется в это верить, так как сегоднящние NT и Линкус — это дырявые колоши с доисторической архитекрутрой.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Мне пофиг какой там язык будет (ASM/C/C++) или твой Барток (или как его там). Я говорил о невозможности сделать часть задач на C#, пользуясь своими знаниями об этом языке.
Может тебе и пофигу. Но нет ни одной задачи которую можно решить на С и нельзя на Шарпе. Что до асма, то мы с тобой вроде сошлись на мнении, что его можно оставить в микроскопических количествах, а то и просто заменить бинарными кусками написанными в маш.кодах. Думаю понятно, что чем меньше анменеджед-кода и ансэйфа тем предсказуемее и надженее будет ОС. В конце концов насколько я понимаю, ХАЛ то й же NT тоже на ассемблере нибусь написан.
V>А вот твое выше (ты отвечал mrozov): V>
V>Кстати, ты все же ошибашся. Есть таки очень разумные и весьма дальновидные люди которые пишут драйверы на C#.
V>Ты про драйверы, я же сделал замечание про ядро. Если тебе не понравились мои примеры (ASM/C/C++), то уж извини — я не зря не уточнил, т.к. не могу знать подробности. Мне вообще-то все-равно, на чем это будет написано, но это должен быть язык, который позволяет ЭТО написать, и который уж никак не может быть использован для пользовательских приложений этой же ОС.
Единственный язык позволяющий обращаться к портам без библиотек — это ассемблер. Хотя я уже повторяюсь. Потому и не понравилось.
V>Я тебе привел свою цитату из начала обсуждения. Не помню, чтобы я чего-то там не считал невозможным. Я обсуждаю долю unmanaged кода. Заодно unsafe (спасибо за поправки).
Code in Singularity is either verified or trusted. Verified code’s type and memory safety is
checked by a compiler. Unverifiable code must be trusted by the system and is limited to the
hardware abstraction layer (HAL), kernel, and parts of the run-time system. Most of the kernel is
verifiably safe, but portions are written in assembler, C++, and unsafe C#.
All other code is written in a safe language, translated to safe Microsoft Intermediate
Language (MSIL)4, and then compiled to x86 by the Bartok compiler [20]. Currently, we trust
that Bartok correctly verifies and generates safe code. This is obviously unsatisfactory in the long
run and we plan to use typed assembly language to verify the output of the compiler and reduce
this part of the trusted computing base to a small verifier [36]
V>Вроде мы пришли уже к тому, что в их драйверах никакого unsafe и близко быть не может из-за плоской модели памяти самой ОС. (Кстати, в "плоском" режиме даже ввод/вывод происходит гораздо эффективней, так что, кое-какие бенефиты от плоской модели разумеется есть.)
Кстати, при всем при том, что они говорят о защите на уровне безоспасного кода... все же они же говорят и о страничной подкачке. Это уже и в мою буйную на фантазию голову войти не может.
В общем, нужно читать этот документ. Он вроде как многое проясняет.
V>Я говорил имено про unmanaged код в том первом абзаце. В принципе, если ты напираешь на "дыру" в С++ в виде возможности произвольной реинтерпретации памяти в С++, то твой unsafe позволяет точно такое же.
Такой же, да не такой же. В нем все опасные точки специфицируются и могут быть проконтролированны. Плюс это дает возможность все же большую часть кода создавать без опасных конструкций.
V>-------- V>Кстати, насчет моих "или по фиксированным адресам памяти?". Ты там позже прошелся по этой фразе, что я недостаточно знаю C# раз такое написал. Прочитай в той же фразе чуть дальше. Имелась ввиду фиксированная "плоская" память и реализация механизма виртуального режима (суть его одинакова как для портов так и для памяти). Насчет работы Сингулярити в едином адресном пространстве я прочел уже позже.
А я тебе про это сразу говорил. Я это поня еще до того как они это явно сказали. Ну, просто все что они наобещали практически не реально без единого адрессного пространства. Да и нахрена связываться с безопасным кодом если защита аппаратная. Сделать сторую БСД не виликого ума дела. Это, на сегодны, работа не для ученых, а для очень хороших инжинеров/программистов. Собсвтенно идеи витают в воздухе нужно только приложить несколько светлых голов и много моного пошлых баксов.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ничего она не повторяет. Там сказано то что было на самом деле. ОС проектировалась как микроядерная, но в ходе разработки в ядро засовавались все большие и большие куски тем самым уводя ОС в сторону монолитных. На сегодня это гибрид.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>А что собственно "бррр"? И тем более чем не угодил первый вариант? И наконец, может есть третий вариант, который лучше их обоих?
using
(
MyRAII1 r1 = new MyRAII1(),
MyRAII2 r2 = new MyRAII2(),
MyRAII3 r3 = new MyRAII3(),
MyRAII4 r4 = new MyRAII4()
)
{
}
Согласно ECMA 334 (15.13). Но С++ лучше всех Однозначно.
Сорри за запоздалый ответ.
В общем, все немного не так, несмотря на то, что мне понятны рассуждения.
Сама ОС состоит из множества компонент. Ядро — это лишь одна из компонент. Назначение ядра — связать остальные подсистемы ОС. Например, в пакетных ОС основной алгоритм — это как раз бесконечный цикл ядра ОС, который последовательно вызывал планировщик, а затем задачи спланированного пакетаи т.д. бесконечно.
В многозадачных "выталкивающих" ОС этот алгоритм изменился не сильно, но теперь управляется прерываниями. Однако суть все та же — бесконечный цикл, в котором вызывается планировщик и затем выделяется квант выбранному процессу.
В классике именно этот основной цикл, и все, что связано с его обслуживанием и зовется ядром. Ни сам шедуллер ни подсистемы ввода/вывода к нему не относятся.
Далее. Драйвера. Я уверен, что мне трудно будет убедить не рассматривать понятие "драйвер" так, как это делается в WinNT или Linux. Понятие драйвер не имеет ничего общего ни с HAL, ни с ядром. И даже тот факт, что драйвера WinNT работают на уровне ядра — это всего лишь очень частный пример реализации драйверов. На самом деле не существует каких-либо требований на "единственность" АПИ драйверов в конкретной ОС. В WinNT имеющеся АПИ, доступное через DDK — это АПИ для драйверов, предназначенных для работы на уровне ядра. Однако, у тебя нет абсолютно никаких ограничений на разработку драйверов пользовательского уровня. Обрати на эти факты внимание.
Далее. Еще один важный момент. Ввод/вывод. Так уж получилось, что качественный шедуллинг в "выталкивающих" многозадачных ОС невозможен без учета состояний подсистем ввода/вывода. Т.е., само ядро должно знать о том, что приложение находится в ожидании и не переключать на него напрасно управление, ибо это дорогого стоит в системах с аппаратной защитой памяти. Т.е. я опять обращаю внимание на компроммиссы и перекосы в толкованиях терминов, внесенные в результате разработке ОСей, основанных на аппаратной защите памяти.
Далее все должно быть уже более понятно. Подавляющая масса драйверов — это драйвера ввода/вывода. В ОС типа WinNT вынужденно эти драйвера запихивают на системный уровень исполнения. Поэтому и сформировалось мнение, что драйвер — часть ядра (в большинстве ОС). Дудки, даже в WinNT — это просто модуль, который исполняется на уровне ядра, но это не значит, что является его частью.
vdimas wrote: > > Сорри за запоздалый ответ. > В общем, все немного не так, несмотря на то, что мне понятны рассуждения.
Насколько я помню, спор шел о том, является ли NT микроядерной системой.
> Далее. Драйвера. Я уверен, что мне трудно будет убедить не рассматривать > понятие "драйвер" так, как это делается в WinNT или Linux. Понятие > драйвер не имеет ничего общего ни с HAL, ни с ядром. И даже тот факт, > что драйвера WinNT работают на уровне ядра — это всего лишь очень > частный пример реализации драйверов. На самом деле не существует > каких-либо требований на "единственность" АПИ драйверов в конкретной ОС. > В WinNT имеющеся АПИ, доступное через DDK — это АПИ для драйверов, > предназначенных для работы на уровне ядра. Однако, у тебя нет абсолютно > никаких ограничений на разработку драйверов пользовательского уровня. > Обрати на эти факты внимание.
Я согласен с тем, что возможна архитектура ОС, в которой драйвера не
являются частью ядра. Собственно, любая микроядерная ОС так устроена.
Однако в Виндовсе это не так. В Виндовсе "драйвер" можно рассматривать
как одно из двух:
1) компонент, который имеет доступ к ядерному API
2) компонент, который может создать DEVICE_OBJECT
Ни то не другое не возможно в Виндовсе из user space. И то и другое
требует исполнения в контексте ядра. Поэтому, все же, драйвера в Windows
— часть ядра, а не самостоятельные сущности. И тем самым, Windows не
микроядерная ОС (по-моему, спор шел именно об этом).
> Далее. Еще один важный момент. Ввод/вывод. Так уж получилось, что > качественный шедуллинг в "выталкивающих" многозадачных ОС невозможен без > учета состояний подсистем ввода/вывода. Т.е., само ядро должно знать о > том, что приложение находится в ожидании и не переключать на него > напрасно управление, ибо это дорогого стоит в системах с аппаратной > защитой памяти. Т.е. я опять обращаю внимание на компроммиссы и перекосы > в толкованиях терминов, внесенные в результате разработке ОСей, > основанных на аппаратной защите памяти.
Scheduller'у, по большому счету, ничего не надо знать про ввод-вывод.
Ему надо знать только про примитивы синхронизации/ожидания.
Именно благодаря этому в микроядерный ОС весь ввод-вывод можно убрать из
ядра. Ядро в таком случае предоставляет лишь некоторый набор примитивов
для синхронизации, разделения ресурсов и коммуникации между процессами.
> Далее все должно быть уже более понятно. Подавляющая масса драйверов — > это драйвера ввода/вывода. В ОС типа WinNT вынужденно эти драйвера > запихивают на системный уровень исполнения. Поэтому и сформировалось > мнение, что драйвер — часть ядра (в большинстве ОС). Дудки, даже в WinNT > — это просто модуль, который *исполняется *на уровне ядра, но это не > значит, что является его частью.
Если что-то исполняется на уровне ядра, работает в контексте ядра,
располагается в адресном пространстве ядра и т.п., то по-моему, это
часть ядра, даже если она и грузится из одного файла.
Но в общем, это не важно. Я хочу сказать, что между Windows и UNIX нет
содержательной разницы в том, как ядро соотносится с драйверами. Поэтому
нельзя, пользуясь одними и теми же аргументами, утверждать, что Windows
— микроядерная система, а UNIX — нет.
Здравствуйте, Pzz, Вы писали:
Pzz>Пример minix — микроядерная ОС для 16-битного 8086, где никакой защиты Pzz>памяти вообще не было предусмотрено.
Pzz>У minix'а, кстати, по-моему нет HAL'а
А зачем ей HAL? Априори, если ОС ориентируется на конкретную аппаратную платформу и фиксированное окружение, то всякие абстракции ей и на фиг не сдались.
И зачем вообще повторять ошибку Влада и пытаться связать микроядерность и HAL? У любой абстракции может быть только одна причина — требование той самой абстракции.
Здравствуйте, Pzz, Вы писали:
Pzz>Если что-то исполняется на уровне ядра, работает в контексте ядра, Pzz>располагается в адресном пространстве ядра и т.п., то по-моему, это Pzz>часть ядра
И опять мы упорно навязываем частный случай общим понятиям. Забудь про контекст исполнения и адресное пространство. Вспомни, что полно железок и ОСей с единым адресным пространством. Следуя твоей логике, любое прикладное приложение в таких системах является частью ядра. Блин, ну как вообще можно пытаться проводить границы в ПО по физическим принципам? Это уже даже не смешно.
V>>Обсуди. У меня в студии плагины типа Решарпера + Rational XDE + весьма большие проекты. В общем, 2-3 студии с разными солюшинами открыл и 2 гига памяти под завязку.
VD>У меня постоянно 3-5 студий и никаких проблем в 1 гиге. При этом еще куча софта, а память около 600 метров отедено. РеШарпера правда нет. Он глючит еще, а мне и того что есть хватает.
Тебе описали реальную ситуацию, при которой виртуальные 2 гига набиты под завязку. Я охотно соглашусь лишь с тем, что у тебя лично ситуация обстоит по другому.
VD>Может у тебя с ХДЕ проблемы?
Он не на много более прожорлив, чем решарпер. Реально выходит — "сладкая парочка", пожирающая память на более-менее больших солюшинах (десятки проектов в солюшене). И самое забавное — абсолютно никаких альтернатив на данный момент.
VD>>>Насколько я понял прикладные процессы в Сингулярити приципиально обязаны быть безопасными.
V>>Т.е. и драйверы тоже, правда же?
VD>Да. Но само ядро может содержать небезопасный код. Тот же ансэйф шарповский проходит на ура. Так что особо тонкие места общения с железом можно будет оптимизировать.
Вот не могу добиться уточнения твоей т.з. на этот момент. Еще раз. Unsafe код в Сингулярити допустим только внутри "пояса безопасности". В этот пояс безопасности входит только сама VM и микроядро. Драйвера НЕ МОГУТ содержать небезопасный код. И мне уже прямо сейчас нетерпиться узнать, пойдут они на компроммиссы или нет к моменту выпуска коммерчесского варианта. Невзирая на мощность техники к тому моменту. А тож блин опять введут нечто вроде: "подписанный unsafe-драйвер", и будет всем смешно.
VD>Вроде как ЖЦ использует ансэйф-код.
Разумеется. Он же памятью оперирует.
V>>Вообще-то мы "зацепились" после моего предположения, что с их концепцией им потребуется довольно высокая абстракция от железки, т.е. некий приличный базис "unsafe" должен будет существовать для конкретной железки.
VD>Вопрос сколько того ансэйфа. Согласен, что для доступа к портам, ДМА, прерываниям и реализации ЖЦ им без ансэфа будет туго. Но это если код минимизировать не так уж много. Темболее, что ансэйф != анменеджед, т.е. 80% кода все же будет безопастным, а опасные куски будут все в коде как на ладони и их проконтролировать будет не сложно.
Я плохо представляю себе, как может быть безопасным unsafe-код. Произвольная реинтерпретация памяти, она и в Африке грабля. И в чем отличие unsafe от unmanaged? Только лишь в отличие байт-кода от нативного? Это непринципиально при прямом доступе к памяти или другим частям железки.
VD>Разработчики Сингулярити как раз постоянно акцентируют внимание на том, что у них все совсем не как во встраеваемых Явах. Они указывают только на какую-то одну реализацию (какю не помню) и то говорят, что там мол не все честно.
С т.з. прикладных программ абсолютно нет никакой разницы, какой процент нативного кода содержится в ядрах таких ОС. Что касается текущего положения вещей, то эти Ява-ОС ориентированы на всякие мелкие устройства, типа телефонов или карманных ПК, у которых откровенно слабые вычислительные возможности. Поэтому вопрос наличия приличной доли нативного кода в таких ОС — это вопрос вообще физической реализуемости данного подхода с приемлимыми потребительскими качествами.
Разумеется, разработчикам ПРОЩЕ было бы вообще все писать на Java, но речь не о разработчиках, а о потребителях. В противовес Java-OS, Сингулярити нацелилось на десктопный рынок, потому и может себе позволить гораздо большее, ввиду просто фантастических вычислительных мощностей современных десктопов.
VD>ОС может оказаться медленной относительно традиционных. Они слишком подчеркивают, что не производительность для них не главное.
Потенциально — не медленнее. Все же, работа в едином адресном пространстве, да еще без переключения режимов исполнения несет массу бенефитов именно в плане быстродействия. Просто, они наверняка не вылизывают алгоритмы, ибо действительно, сейчас это не главное. Я тоже самое тебе говорил в топике Муравья в "проектах".
VD>По крайней мере хочется в это верить, так как сегоднящние NT и Линкус — это дырявые колоши с доисторической архитекрутрой.
Проблема современных ОС в том, что к ним предъявляется жестокое требование универсальности. И этот опыт был накоплен только буквально в 90-х годах. ПО дожило до того, что вынужденно защищаться от другого ПО, и складвается впечатление, что на сегодняшний день нет более важной задачи. Похоже, мы дожили до кульминации — ПО будет полностью анализироваться перед исполнением. Занавес.
Code in Singularity is either verified or trusted. Verified code’s type and memory safety is
VD>checked by a compiler. Unverifiable code must be trusted by the system and is limited to the
VD>hardware abstraction layer (HAL), kernel, and parts of the run-time system. Most of the kernel is
VD>verifiably safe, but portions are written in assembler, C++, and unsafe C#.
VD>All other code is written in a safe language, translated to safe Microsoft Intermediate
VD>Language (MSIL)4, and then compiled to x86 by the Bartok compiler [20]. Currently, we trust
VD>that Bartok correctly verifies and generates safe code. This is obviously unsatisfactory in the long
VD>run and we plan to use typed assembly language to verify the output of the compiler and reduce
VD>this part of the trusted computing base to a small verifier [36]
Я тоже кое-что выделил во второй половине этого отрывка. Именно поэтому в той ветке Муравъя про разработку подобонй ОС настаиваю, что Bartok не является для нас обязательным. Это лишь некое текущее удобство для разработчиков Сингулярити.
VD>Кстати, при всем при том, что они говорят о защите на уровне безоспасного кода... все же они же говорят и о страничной подкачке. Это уже и в мою буйную на фантазию голову войти не может.
А в чем противоречие? У них x86 работает в защищенном режиме, имеет виртуальную память (или ты считал, что они ограничаться лишь объемом физической?). Просто вся эта бодяга работает в едином уровне исполнения и не переключает контексты (как при переключении процессов в других ОС). Все остальное остается в силе. Потому я и считаю, что подобную ОС можно разрабатывать и отлаживать прямо в виндах как обычный процесс, подсунув эмуляторную реализацию HAL.
V>>Я говорил имено про unmanaged код в том первом абзаце. В принципе, если ты напираешь на "дыру" в С++ в виде возможности произвольной реинтерпретации памяти в С++, то твой unsafe позволяет точно такое же.
VD>Такой же, да не такой же. В нем все опасные точки специфицируются и могут быть проконтролированны.
Я наверно чего-то упустил. Но так и не понял разницы. Вернее не представляю, как эти опасные куски кода могут быть проконтроллированы лучше, например, чем в С++? И если уж сравнивать инструменты, то для генерации небезопасного кода мне С++ представляется на голову выше по удобством. Я обкладываю программы на С++ жесткой статической типизацией, и при этом не трачу на это много усилий ввиду мощи шаблонов. А unsafe в C# по возможностям недалеко ушел от обычного С, т.е. каменный век. В общем откровенно неудобно и лишает меня чувства безопасности, которое присутствует при "правильной" разработке на С++.
Сдается мне, что советы писать unsafe-куски на C# — это из области религии. Особенно в свете вышедшего С++/CLI.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Kluev, Вы писали:
K>>Дотнетовский массив — это ссылочный тип который в GC-хипе аллоцируется. В NET нельзя сделать массив частью аггрегата, как в С++:
AVK>
AVK>struct CSharpTriangle
AVK>{
AVK> public fixed Node nodes[3];
AVK>}
AVK>
К превеликому сожалению данная конструкция является unsafe. А доступ к массиву возможен только внутри fixed-выражения.
Здравствуйте, vdimas, Вы писали:
V>Тебе описали реальную ситуацию, при которой виртуальные 2 гига набиты под завязку. Я охотно соглашусь лишь с тем, что у тебя лично ситуация обстоит по другому.
ЖЦ и виртуальная память плохо дружат. Дело в том, что сборка мусора поднимит все данные в память, и если физической памяти не хватает, то начнется кольцивой свопинг, так что для ОС основанной на ЖЦ вопрос с виртуальной памяти можно не рассматривать.
Когда же подобная ОС дойдет до промышленной эксплуатации, то говорить о чем-то отличном от 64-битных камней будет не серьезно. Ну, или на них можно смело бабить.
V>Вот не могу добиться уточнения твоей т.з. на этот момент. Еще раз. Unsafe код в Сингулярити допустим только внутри "пояса безопасности". В этот пояс безопасности входит только сама VM и микроядро. Драйвера НЕ МОГУТ содержать небезопасный код. И мне уже прямо сейчас нетерпиться узнать, пойдут они на компроммиссы или нет к моменту выпуска коммерчесского варианта. Невзирая на мощность техники к тому моменту. А тож блин опять введут нечто вроде: "подписанный unsafe-драйвер", и будет всем смешно.
Драйверы не могут содержать небезопасный код. Но это не значит, что процесс драйверов не может содержать доверительного небезопасного кода. В описании Синкулярити сказано, что в код драйверов подмешивается доверительный код (на базе CTR — рефлексии времени компиляции). Точно так же код прикладных процессов может содержать доверительный код генерируемый компилятором или рантайомом. Так что безопасность драйверов не означает невозможность использования трюков повышающих производительность.
Ну, а что до коммерческого релиза... Думаю до этого очень долеко и сама Сингулярити не будет коммерчесой ОС. Скорее она может стать прототипом для ОС нового поколения.
Меня вообще занимает не технический, а марально-экономический аспект. Ведь у МС есть 100 тысяч драйверов написаных на С/С++ которые для новой ОС прийдется переписать с нуля. Пусть даже на 2 трети они забьют, но ведь и без этого объем работы колосальный! А ведь еще прийдется переписать GUI, 3D, средства комуникции, серверы приложений... Один MS SQL — это уже огромнейшая работа.
Думаю это куда как посерьезнее каких-то технический проблем.
VD>>Вроде как ЖЦ использует ансэйф-код.
V>Разумеется. Он же памятью оперирует.
А что есть пмять? Набор байтов... Так что можно представить ее как массив байтов.
V>Я плохо представляю себе, как может быть безопасным unsafe-код.
В unsafe можно помечать ключевым словом unsafe только конкретные блоки кода. При этом даже внутри них все манипуляции с управляемыми типами будут безопасны. Так что общая надежность будет выше. unsafe же можно попытаться контролировать другими средствами. Например, допускать unsafe только если он генерируется по некоторым шаблонам (проверенным и безопасным).
V> Произвольная реинтерпретация памяти, она и в Африке грабля.
Дык сколько ее там надо?
V> И в чем отличие unsafe от unmanaged? Только лишь в отличие байт-кода от нативного? Это непринципиально при прямом доступе к памяти или другим частям железки.
Отличие в том, что при манипуляции с управляемымии данными ты защищен от ошиблок.
V>Разумеется, разработчикам ПРОЩЕ было бы вообще все писать на Java, но речь не о разработчиках, а о потребителях. В противовес Java-OS, Сингулярити нацелилось на десктопный рынок, потому и может себе позволить гораздо большее, ввиду просто фантастических вычислительных мощностей современных десктопов.
Думаю Сингулярити ни на что не рассчитана. Это исследование. И что оно покажет еще чер не знает. Вот они уже хвастаются очень малым расходом памяти на процессы.
V>Потенциально — не медленнее. Все же, работа в едином адресном пространстве, да еще без переключения режимов исполнения несет массу бенефитов именно в плане быстродействия. Просто, они наверняка не вылизывают алгоритмы, ибо действительно, сейчас это не главное. Я тоже самое тебе говорил в топике Муравья в "проектах".
Согласен. Но есть еще плата за софтовую безопасность. Хотя чем дальше в лес, тем меньше это убдет влиять на производительность, так как оптимизации все время становятся все мощьнее и мощьнее.
V>Проблема современных ОС в том, что к ним предъявляется жестокое требование универсальности. И этот опыт был накоплен только буквально в 90-х годах. ПО дожило до того, что вынужденно защищаться от другого ПО, и складвается впечатление, что на сегодняшний день нет более важной задачи. Похоже, мы дожили до кульминации — ПО будет полностью анализироваться перед исполнением. Занавес.
Давно пора.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > > V>Тебе описали реальную ситуацию, при которой виртуальные 2 гига набиты > под завязку. Я охотно соглашусь лишь с тем, что у тебя лично ситуация > обстоит по другому. > > ЖЦ и виртуальная память плохо дружат. Дело в том, что сборка мусора > поднимит все данные в память, и если физической памяти не хватает, то > начнется кольцивой свопинг, так что для ОС основанной на ЖЦ вопрос с > виртуальной памяти можно не рассматривать.
Ну, вообще-то, ничто не мешает держать управляющие структуры (для GC)
отдельно от блоков собственно памяти, доступных приложению. В таком
случае, GC вовсе не обязано вызывать интенсивный свопинг.
Здравствуйте, Pzz, Вы писали:
Pzz>Ну, вообще-то, ничто не мешает держать управляющие структуры (для GC) Pzz>отдельно от блоков собственно памяти, доступных приложению. В таком Pzz>случае, GC вовсе не обязано вызывать интенсивный свопинг.
"Управляющие структуры" хранятся внутри каждого объекта.
Дело в том, что даже банальный алогоритм определения достижимого графа объектов требует помечать найденные объекты. Да и сам перебор ведется непосредственно по самим объектам. Нельзя же хнанить отдельно поля объекта?
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > > Pzz>Ну, вообще-то, ничто не мешает держать управляющие структуры (для GC) > Pzz>отдельно от блоков собственно памяти, доступных приложению. В таком > Pzz>случае, GC вовсе не обязано вызывать интенсивный свопинг. > > "Управляющие структуры" хранятся внутри каждого объекта. > > Дело в том, что даже банальный алогоритм определения достижимого графа > объектов требует помечать найденные объекты. Да и сам перебор ведется > непосредственно по самим объектам. Нельзя же хнанить отдельно поля объекта?
Чтобы помечать объекты, нужен флаг. Что мешает хранить эти флаги в
отдельной кучке?
VladD2 wrote: > Pzz>Ну, вообще-то, ничто не мешает держать управляющие структуры (для GC) > Pzz>отдельно от блоков собственно памяти, доступных приложению. В таком > Pzz>случае, GC вовсе не обязано вызывать интенсивный свопинг. > "Управляющие структуры" хранятся внутри каждого объекта.
Pzz совершенно прав — нормальный GC не должен свопить во время малых
сборок, так как все нужные страницы и так уже есть в памяти. Вот во
время большой сборки — действительно нужно все загружать.
> Дело в том, что даже банальный алогоритм определения достижимого графа > объектов требует помечать найденные объекты. Да и сам перебор ведется > непосредственно по самим объектам. Нельзя же хнанить отдельно поля объекта?
Все просто — не надо обходить ВСЕ объекты, а только те, которые
изменились с предидущей сборки. Это достигается с помощью card marking'а
или трюков с защитой памяти.
).
) В сочетании с собственным представлением о HAL как об аттрибуттике именно микроядерной архитектуры сделал такой странный вывод, ИМХО.
