Здравствуйте, vdimas, Вы писали:
V>Твое мнение насчет "научность vs инженерность" разработки понятна. Если они предоставят какие-то новые парадигмы и подходы мировому сообществу, то может быть ты прав. А если эта разработка будет закрытым образом использована MS, т.е. использована напрямую в практических целях, то согласно твоему же определению, это будет просто макетирование очередной инженерной разработки.
Ну, и почему ты считашь, что имешь право определять степень научности чужих работ "по запаху"? Люди называют свою работу научным исследованием. И до тех пор пока нет не будет точно доказано, что они занимаются профанацией не стоит ставить под сомнение их честность и компетентность.
V>И насчет инноваций — неплохо тебе ознакомится с JavaMe, и конкретно с устройствами, типа @Blackberry. Тогда мы сможем поговорить о степени инноваций.
А зачем ты пыташся перевести разговор в плоскость сталкивания лбами разных разрботок. Чем бы не являлась JavaMe — это не сколько не мешает производить аналогичные или другие исследования другим людям.
Я не собираюсь сравнивать степень новаций. Я просто вижу, что люди затеяли интересное исследование которое может дать много нового.
V>Я вот только одного не понимаю, почему когда я пытаюсь развить тему привязки HAL к железу и уровне его абстракции, ты отсылаешь меня к микроядерной архитектуре???
Потому что ты паташся доказать что люди что-там врут, и при этом сам делаешь довольно спорные утверждения.
V> Еще при этом пытаешься выставить за ламера.
Нет, уж. Не надо переваливать с больной головы на здоровую. Выставлять тебя за кого-то никто не собирается. Это ты всячески пыташся обвинить во лжи и профанации создателей этой ОС. Причем довольно неуклюже.
V> Я реально имел дело с совершенно различными по уровню HAL, и знаю о чем говорю. Понятие HAL никак не пересекается с архитектурой ОС.
В общем-то после этоих слов уже дальше говорить не о чем. Наличие HAL-а как раз и говорит о ориентации ОС на минкроядерную архитектуру. Собственно зачем монолитной ОС HAL если любой драйвер может залезть в любой аспект железки? Единственное с чем можно согласиться, в последнее время в погоне за производительностью многие ОС инзначально ориентировавшиеся на микроядерную архитектуру начали постепенно нарушать принцыпы которые декларировались ими в начале. NT4 хороший тому пример. Ради быстрой 3D-графики по сути драва видеокарт были всунуты в ядро и стали лезть к железу напрямую. И это при том, что во многих случаях эта самая 3D-графика вообще не нужна.
V>Более того, если ты уж так подробно интересовался микроядерной архитектурой, то ты должен прекрасно понимать, что для микроядерной архитектуры требуется самый что ни на есть высокий уровень абстракции от железки.
С чего бы это? Наоборот требуется минимальное ядро абстрагирующее от самых тонких вещей. Далее дрова работая через это микроядро абстрагируют ОС от остальных деталей реализации железа.
V> Ибо в микроядерной архитектуре общение с драйверами происходит наиболее затратно,
Во как? Кто тебе это сказал? Ты приписываешь микроядерной архитектуре проблемы современнх ОС и современных процессоров. В них процессы защищаются друг от друга аппоратно и имеются большие накладные расходы на комуникацию между процессами. Между тем в безопасной ОС без проблем можно сделать легкие процессы взаимодействующие в рамках одного адресного пространтсва. При этом снимаются ограничения скорости и идеи микрояденой архитектуры становятся очень даже приемлемыми.
V> т.е. наличие лишнего драйвера дорогого стоит.
Еще раз. Последий. Если я правильно понял суть исследования, то ребята делают максимально надежную ОС. В ней принципиально предпочитаются более надежные решения более быстрым. О скорости они конечно тоже думают, но уже во вторую очередь. Все драйверы в этой ос являются отдельными процессами. Никакой экономии драйверов не делается. Все процессы общаются между собой исключительно по средствам типизированных сообщений. Ну, а приемлемая скорость достигается тем, что процессы живут в одном адресном пространстве, а их память защищается применением типобезопасного языка и верификации кода.
V>Именно поэтому я и считаю, что для каждой новой железки для этой Сингулярити придется приличную часть НЕПЕРЕНОСИМОГО кода по-любому писать в unmanaged.
Я рад за то что ты обладашь такой самоуверенностью, что умудряшся утверждать что почти все что говорят разработчики Сингулярити невозможно, тем самым обвиняя их во лжи. Однако ты иж извини, но мне кажется ты просто слишком самоуверен.
V>Тут я кое-что ответил Синклеру, не хочу повторяться http://www.rsdn.ru/Forum/Message.aspx?mid=1494189&only=1
Там ровным счетом ни одного аргумента. Одни домыслы.
V>---------- V>И по поводу моего незнания C#. А-я-яй опять дергать из контекста. Я говорил про прямой доступ не только к памяти, но и к портам и прерывания. Работа с прерываниями — это задание своих точек входа на обработчики. Я спрашивал — возможно ВСЕ это? НЕТ. На C# вряд ли можно написать корректную точку входа для обработки прерывания для конкретного проца. Т.е. в ф-ии HAL помимо всего того, что прочтешь по ссылке выше, надо будет добавлять нечто вроде SetStaticMethodAsIRQEntry, это тянет за собой еще одну проблему — надо обеспечить, чтобы указанный метод был явно загружен джитом, ибо обработка прерываний по сути должна иметь быструю реакцию, а не ждать, пока джит что-то там разджитит,
Если бы ты вместо того чтобы упорно отстаивать свою совершенно не обоснованную позицию внимательно почитал бы то что пишут авторы ОС, то заметил бы, что ядро ОС работает на прекомпилированном машинном коде созданном компилятором Барток. Соотвественно никаких проблем джитом там нет и быть не может по определению.
V>т.е. в API надо добавлять еще методы по явному управлению VM (пусть даже во внутренние API OС).
Одной из задач исследования является разработка рантайма реального времени. Думаю, что это куда более серьезная задача нежели решение каких-то там мелких проблем с обрабокой прерываний.
V>В общем, когда они дойдут до более-меннее реальной системы и откроют всю информацию по ней, тогда можно будет судить, что именно и где managed, а где нет.
Правильно. А до тех пор все свои домыслы лучше держать при себе и просто верить тому, что говорят разработчики.
V>Простое заявление "у нас драйвера на C#" говорит слишком мало.
Но куда больше чем все твои рассуждения вместе взятые.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, rombeck, Вы писали:
R>Ну если существуют ОС, полностью написанные на Java (JavaOS) и на Обероне, почему бы и не существовать ОС, полностью написанной на C#?
ОС полностью написанной на Яве не существует. На Обероне существует. Однако даже если бы всего этого небыло лично я не вижу препятсвий к созданию такой ОС.
R>А вот будет ли эта ОС развиваться и практически применяться — вопрос другой...
Эта? Нет конечно. Это всего лишь прототип. Просто возможно лет через 5-10 на базе полученной в этом ислледовании информации будет создана ОС нового поколения.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > > В общем-то после этоих слов уже дальше говорить не о чем. Наличие HAL-а > как раз и говорит о ориентации ОС на минкроядерную архитектуру. > Собственно зачем монолитной ОС HAL если любой драйвер может залезть в > любой аспект железки? Единственное с чем можно согласиться, в последнее > время в погоне за производительностью многие ОС инзначально > ориентировавшиеся на микроядерную архитектуру начали постепенно нарушать > принцыпы которые декларировались ими в начале. NT4 хороший тому пример. > Ради быстрой 3D-графики по сути драва видеокарт были всунуты в ядро и > стали лезть к железу напрямую. И это при том, что во многих случаях эта > самая 3D-графика вообще не нужна.
NT никогда не была микроядерной ОС. Ядро НТ монолитно, работает в едином
адресном пространстве. Наличие динамической загрузки драйверов никак не
отменяет этого факта (иначе придется признать, что любой современный
UNIX тоже имеет микроядерную архитектуру, что неправда).
HAL в NT нужен, чтобы можно было использовать одни и теже драйвера без
перекомпиляции на разных вариантах одного и того же железа, или с
перекомпиляцией на разных платформах. Короче, чтобы абстрагироваться от
таких аспектов железа, до которых большей части системы нет никакого
дела, как особенности конфигурации шин, контроллера прерываний,
таймеров, DMA и т.п.
> V> Ибо в микроядерной архитектуре общение с драйверами происходит > наиболее затратно, > > Во как? Кто тебе это сказал? Ты приписываешь микроядерной архитектуре > проблемы современнх ОС и современных процессоров. В них процессы > защищаются друг от друга аппоратно и имеются большие накладные расходы > на комуникацию между процессами. Между тем в безопасной ОС без проблем > можно сделать легкие процессы взаимодействующие в рамках одного > адресного пространтсва. При этом снимаются ограничения скорости и идеи > микрояденой архитектуры становятся очень даже приемлемыми.
Кеши у процессоров работают не слишком эффективно при постоянном
переключении адресного пространства. Причем если на x86 это не очень
заметно (там кеш работает с физическими адресами), то на многих RISC'ах
переключение контекстов стоит очень дорого именно из-за необходимости
проинвалидировать весь кеш (да еще и слить его в память, если кеш с
отложенной записью).
> V> т.е. наличие лишнего драйвера дорогого стоит. > > Еще раз. Последий. Если я правильно понял суть исследования, то ребята > делают максимально надежную ОС. В ней принципиально предпочитаются более > надежные решения более быстрым. О скорости они конечно тоже думают, но > уже во вторую очередь. Все драйверы в этой ос являются отдельными > процессами. Никакой экономии драйверов не делается. Все процессы > общаются между собой исключительно по средствам типизированных > сообщений. Ну, а приемлемая скорость достигается тем, что процессы живут > в одном адресном пространстве, а их память защищается применением > типобезопасного языка и верификации кода.
Ух, я этого не знал. Т.е., MS-DOS (Windows 3.1), но с защитой при
компиляции. Прекрасная ОС, ничего не скажешь...
Здравствуйте, VladD2, Вы писали:
Pzz>>Ух, я этого не знал. Т.е., MS-DOS (Windows 3.1), но с защитой при Pzz>>компиляции. Прекрасная ОС, ничего не скажешь...
VD>В MS-DOS небыло ни процессов ни, ни сообщений, ни потоков. Короче нихрена в ней небыло. VD>Сингулярити это скорее нечто на тему Оберон-ОС.
Offtopic: Над Виртом часто подшучивают и не принимают всерьез, а ведь он довел до промышленного состояния то, над чем сейчас экспериментируют в Microsoft -- Оберон-ОС.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
eao197 wrote: > > Offtopic: Над Виртом часто подшучивают и не принимают всерьез, а ведь он > довел до промышленного состояния то, над чем сейчас экспериментируют в > Microsoft -- Оберон-ОС.
В Мелкософте над чем только не экспериментируют. Не надо принимать их
эксперименты слишком уж близко к сердцу. Цель этого эксперимента —
доказать, это C#, .Net и managed code 1) интересны для исследователей 2)
годятся для системного программирования.
Если посмотреть на их другие исследовательские проекты, то они все такие
— или про .Net, или про WiFi.
Ничего она не повторяет. Там сказано то что было на самом деле. ОС проектировалась как микроядерная, но в ходе разработки в ядро засовавались все большие и большие куски тем самым уводя ОС в сторону монолитных. На сегодня это гибрид.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > > Pzz>Википедия повторяет распостраненное заблуждение. > > Ничего она не повторяет. Там сказано то что было на самом деле. ОС > проектировалась как микроядерная, но в ходе разработки в ядро > засовавались все большие и большие куски тем самым уводя ОС в сторону > монолитных. На сегодня это гибрид.
Здравствуйте, VladD2, Вы писали:
V>> Я реально имел дело с совершенно различными по уровню HAL, и знаю о чем говорю. Понятие HAL никак не пересекается с архитектурой ОС.
VD>В общем-то после этоих слов уже дальше говорить не о чем. Наличие HAL-а как раз и говорит о ориентации ОС на минкроядерную архитектуру.
Бред полный. Наличие HAL-а говорит лишь об обстрагировании от железа. С чего ты делаешь подобные выводы? Ознакомился бы с вопросом наличия HAL в современных ОС, в том числе и встраиваемых, которые никогда не будут микроядерными. HAL есть практически везде. Так что, странное заявление.
VD>Собственно зачем монолитной ОС HAL если любой драйвер может залезть в любой аспект железки?
Не только драйвер, но и ОС, правда?
HAL — это абстракция, иногда довольно-таки высокоуровневая. Ее цель — действительно развязаться от железа, и от процессора в т.ч. Смешной вопрос, право. Для того, чтобы ответить на него, надо элементарно составить список ф-ий, которые содержат HAL различных ОС. Оставляю как домашнее задание (для WinXX, Linux, и кучи встраиваемых, в ответе Синклеру указал, где копать)
V>>Более того, если ты уж так подробно интересовался микроядерной архитектурой, то ты должен прекрасно понимать, что для микроядерной архитектуры требуется самый что ни на есть высокий уровень абстракции от железки.
VD>С чего бы это? Наоборот требуется минимальное ядро абстрагирующее от самых тонких вещей. Далее дрова работая через это микроядро абстрагируют ОС от остальных деталей реализации железа.
Блин, туго. Возьми для примера таймер. Сколько нужно приседаний, чтобы создать этот объект ядра? Причем эти приседания зависят от количества, способа обращения и интерпретации результатов работы внешних таймеров, а некоторые реализации вообще обходятся БЕЗ внешних аппаратных таймеров (в WinXX, в которых внешние таймеры задействованы для других нужд). Применительно к таймерам HAL позволяет сделать ОДИН системный вызов для создания оного, а не 5-10, если бы мы работали через inp()/outp() и сами бы подписывались на прерывания. В микроядерной архитектуре общение с драйверами происходит весьма затратно из-за того, что сами драйвера — это отдельные процессы. Поэтому, повторю, в такой архитектуре HAL делают именно "высокоабстрактным".
V>> Ибо в микроядерной архитектуре общение с драйверами происходит наиболее затратно,
VD>Во как? Кто тебе это сказал? Ты приписываешь микроядерной архитектуре проблемы современнх ОС и современных процессоров. В них процессы защищаются друг от друга аппоратно и имеются большие накладные расходы на комуникацию между процессами. Между тем в безопасной ОС без проблем можно сделать легкие процессы взаимодействующие в рамках одного адресного пространтсва. При этом снимаются ограничения скорости и идеи микрояденой архитектуры становятся очень даже приемлемыми.
Это ты про Сингулярити? Я где-то в других ветках уже задавался вопросом — а сколько приложений смогут работать в этой Сингулярити одновременно на 32-х битиной архитектуре? Аппаратная защита памяти реализует так же виртуальный механизм памяти. Весьма болезненно будет от него отказаться.
Опять же, unmanaged код при таком раскладе должен быть ЗАПРЕЩЕН как для драйверов, так и для пользовательских приложений. Поэтому в других ветках можешь начинать отвыкать повторять, что в C# есть unmanaged код "в случае чего".
V>> т.е. наличие лишнего драйвера дорогого стоит.
VD>Еще раз. Последий. Если я правильно понял суть исследования, то ребята делают максимально надежную ОС. В ней принципиально предпочитаются более надежные решения более быстрым. О скорости они конечно тоже думают, но уже во вторую очередь. Все драйверы в этой ос являются отдельными процессами. Никакой экономии драйверов не делается. Все процессы общаются между собой исключительно по средствам типизированных сообщений. Ну, а приемлемая скорость достигается тем, что процессы живут в одном адресном пространстве, а их память защищается применением типобезопасного языка и верификации кода.
Вопрос о "вместимости" единого адресного пространства по-прежнему актуален.
V>>Именно поэтому я и считаю, что для каждой новой железки для этой Сингулярити придется приличную часть НЕПЕРЕНОСИМОГО кода по-любому писать в unmanaged.
VD>Там ровным счетом ни одного аргумента. Одни домыслы.
Там указания на конкретные DLL Win2000 и выше, которая юзает HAL. Так же просьба просмотреть наличие драйверов на основные системные устройства — их нет!!! (Или ты не удосужился проверить сам?) Домыслов нет, ты играешь "на публику" ИМХО.
V>>---------- V>>И по поводу моего незнания C#. А-я-яй опять дергать из контекста. Я говорил про прямой доступ не только к памяти, но и к портам и прерывания. Работа с прерываниями — это задание своих точек входа на обработчики. Я спрашивал — возможно ВСЕ это? НЕТ. На C# вряд ли можно написать корректную точку входа для обработки прерывания для конкретного проца. Т.е. в ф-ии HAL помимо всего того, что прочтешь по ссылке выше, надо будет добавлять нечто вроде SetStaticMethodAsIRQEntry, это тянет за собой еще одну проблему — надо обеспечить, чтобы указанный метод был явно загружен джитом, ибо обработка прерываний по сути должна иметь быструю реакцию, а не ждать, пока джит что-то там разджитит,
VD>Если бы ты вместо того чтобы упорно отстаивать свою совершенно не обоснованную позицию внимательно почитал бы то что пишут авторы ОС, то заметил бы, что ядро ОС работает на прекомпилированном машинном коде созданном компилятором Барток. Соотвественно никаких проблем джитом там нет и быть не может по определению.
Блин, ну при чем тут ядро, если речь о драйверах?
Да читали мы то что они пишут, не переживай. Насколько я понял, драйвера — это должны быть внешние сборки, которые можно будет динамически загружать/выгружать.
V>>т.е. в API надо добавлять еще методы по явному управлению VM (пусть даже во внутренние API OС).
VD>Одной из задач исследования является разработка рантайма реального времени. Думаю, что это куда более серьезная задача нежели решение каких-то там мелких проблем с обрабокой прерываний.
По-твоему, мы не можем обсуждать отдельные моменты? Мне интересны именно технические детали. До твоего рантайма еще доберемся, никуда он не денется. Когда сами разработчики будут готовы.
V>>В общем, когда они дойдут до более-меннее реальной системы и откроют всю информацию по ней, тогда можно будет судить, что именно и где managed, а где нет.
VD>Правильно. А до тех пор все свои домыслы лучше держать при себе и просто верить тому, что говорят разработчики.
Фигушки. Не вчера родились и знаем, как легко жонглировать понятиями. Вон они даже понятие "процесс" переиначили. Без дополнительного разъяснения, что именно кроется за их "процессами" непонятна суть происходящего. Так что, извини, но оставляю за собой право критического взгляда на вещи и обмен мнениями на форумах.
Microsoft hired a group of developers from Digital Equipment Corporation led by Dave Cutler to build Windows NT, and many elements reflect earlier DEC experience with VMS and RSX-11. The OS is designed to run on multiple instruction set architectures, with the kernel separated from the hardware by a hardware abstraction layer. APIs are implemented as subsystems atop the publicly undocumented Native API; it was this that allowed the late adoption of the Windows API. Originally a microkernel design, subsequent releases have integrated more functions into the kernel for better performance. Windows NT was the first operating system to use Unicode internally.
Неужели ты не знал, что в виндах можно писать kernel-mode дрова? Полностью микроядерной NT никогда не была. И как раз там же в википедии ответ на твой вопрос — "нафига HAL монолитным ОС". Как видишь, HAL и микроядро по-прежднему никак не связаны.
Здравствуйте, VladD2, Вы писали:
V>>Ориентируясь же на произвольную архитектуру необходимо операционке предоставить унифицированный доступ к этим фичам. Разумеется, не через inp() и outp(), а именно через более высокий абстрактный уровень.
VD>Да какая разница где и как будет реализовано абстрагирование от тонкостей аппаратуры? ... Синклер тебе верно заметил, что то что действительно не возможно вылевается в 2-3 функции работы с портами.
VD>А все остальное пишется с их использованием. Функции эти в общем-то примитивный и могут быть просто написаны в машинных кодах.
Это понятно и первокурснику. А вот тебе до сих пор непонятно, почему именно так не делают. Тебя наталкивают на размышления в правильном направлении, просто пройдись по этой всей информации.
VD>Ты же ведь другое изначально утверждал. Ты утверждал, что невозможно на C# писать ОС так как он что-то там не может.
Да где? Опять за старое? Я утвержал, что если HAL будет высокоуровневый (и я сильно подозреваю, что именно так, а не как ты там говоришь про 3 машинные инструкции), то много кода надо писать как unmanaged. Если хочешь с чем-то спорить, то спорь именно с этим. Пока я ни одного нормального аргумента не увидел, кроме "надо верить на слово". Я и не спорю с ними, я дополняю их отчет размышлениями о доли "unmanaged" кода в их ОС. (Мое демократическое право )
vdimas wrote: > > Pzz>>NT никогда не была микроядерной ОС. Ядро НТ монолитно, > > VD>Windows NT microkernel > <http://www.google.ru/search?hl=ru&q=Windows+NT+microkernel&lr=> > VD>http://en.wikipedia.org/wiki/Windows_NT > > А ты сам по найденым ссылкам ходил? > > Microsoft hired a group of developers from Digital Equipment Corporation > led by Dave Cutler to build Windows NT, and many elements reflect > earlier DEC experience with VMS and RSX-11. The OS is designed to run on > multiple instruction set architectures, with the kernel separated from > the hardware by a hardware abstraction layer. APIs are implemented as > subsystems atop the publicly undocumented Native API; it was this that > allowed the late adoption of the Windows API. *Originally a microkernel > design, subsequent releases have integrated more functions into the > kernel for better performance.* Windows NT was the first operating > system to use Unicode internally.
Я читал этот текст.
> Неужели ты не знал, что в виндах можно писать kernel-mode дрова? > Полностью микроядерной NT никогда не была. И как раз там же в википедии > ответ на твой вопрос — "нафига HAL монолитным ОС". Как видишь, HAL и > микроядро по-прежднему никак не связаны.
Здравствуйте, vdimas, Вы писали:
V>Неужели ты не знал, что в виндах можно писать kernel-mode дрова? Полностью микроядерной NT никогда не была. И как раз там же в википедии ответ на твой вопрос — "нафига HAL монолитным ОС". Как видишь, HAL и микроядро по-прежднему никак не связаны.
Я и не утвреждал, что NT имеет чистую микроядерную архитектуру. Я утверждал что она основана на идеях микроядерной архитектуры и постепенно сползала в монолитную сторону интегрируя в ядро все больше и больше кода. NT 3.x практически не имела такого кода. А в 4.0 его было уже выше крыши. Собственно это и сказано в приведенных ссылках.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
VD>>С чего бы это? Наоборот требуется минимальное ядро абстрагирующее от самых тонких вещей. Далее дрова работая через это микроядро абстрагируют ОС от остальных деталей реализации железа.
V>Блин, туго. Возьми для примера таймер. Сколько нужно приседаний, чтобы создать этот объект ядра? Причем эти приседания зависят от количества, способа обращения и интерпретации результатов работы внешних таймеров, а некоторые реализации вообще обходятся БЕЗ внешних аппаратных таймеров (в WinXX, в которых внешние таймеры задействованы для других нужд). Применительно к таймерам HAL позволяет сделать ОДИН системный вызов для создания оного, а не 5-10, если бы мы работали через inp()/outp() и сами бы подписывались на прерывания. В микроядерной архитектуре общение с драйверами происходит весьма затратно из-за того, что сами драйвера — это отдельные процессы. Поэтому, повторю, в такой архитектуре HAL делают именно "высокоабстрактным".
Да это уже не туго. Это уже тугоухо.
Читай по губам. Повторяю последний раз. В безопасной среде исполнения HAL может работать в том же кольце защиты, что и прикладные процессы. Защита памяти ведь не требуется, так как ни один процесс не может повредить чужие данные. При этом стоимость вызовов HAL-а фактически становится такой же как стоимость вызовов внутрепроцессных методов (а то и быстрее если учесть что и на этом уровне можно заниматься инлайнингом и оптимизациями).
По этому в такой архитектуре можно делать очень тонкий HAL, а все проблемы с таймерами и т.п. переносить в драйверы устройств работающий в отдельных процессах.
V>Это ты про Сингулярити?
А о чем по-твоему мы тут говорили? Ты же ее все время обсуждашь доказывая что все слова ее авторов невозможны.
V> Я где-то в других ветках уже задавался вопросом — а сколько приложений смогут работать в этой Сингулярити одновременно на 32-х битиной архитектуре? Аппаратная защита памяти реализует так же виртуальный механизм памяти. Весьма болезненно будет от него отказаться.
Ага колосальная проблема. Ведь на сегодны все серверы забиты 5 и более гигами памяти, а 64-битных процессоров не видно даже в подзорную трубу. Согласен. Надо будет ее обсудеть... в "Колегах".
V>Опять же, unmanaged код при таком раскладе должен быть ЗАПРЕЩЕН как для драйверов, так и для пользовательских приложений. Поэтому в других ветках можешь начинать отвыкать повторять, что в C# есть unmanaged код "в случае чего".
Насколько я понял прикладные процессы в Сингулярити приципиально обязаны быть безопасными. Ну, а небезопасные возможности C# можно использовать внутри ОС для повышения быстродействия и замены С/С++.
Ну, а анменеджед-код на C# вообще создать невозможно, если конечно не брать в рассчет возможность сформировать машинный код побайтно. Ты очередной раз путашь термины "анменеджед" и "ансэйф".
VD>>Если бы ты вместо того чтобы упорно отстаивать свою совершенно не обоснованную позицию внимательно почитал бы то что пишут авторы ОС, то заметил бы, что ядро ОС работает на прекомпилированном машинном коде созданном компилятором Барток. Соотвественно никаких проблем джитом там нет и быть не может по определению.
V>Блин, ну при чем тут ядро, если речь о драйверах?
А что мешает драйвер прекомпилировать перед запуском? Если уж есть просто отдельный компилятор...
V>Да читали мы то что они пишут, не переживай. Насколько я понял, драйвера — это должны быть внешние сборки, которые можно будет динамически загружать/выгружать.
Это без разницы. Внешние сборки тоже в лучшем виде прекомпилируются. Это можно делать даже на первой версии дотнета.
V>По-твоему, мы не можем обсуждать отдельные моменты? Мне интересны именно технические детали. До твоего рантайма еще доберемся, никуда он не денется. Когда сами разработчики будут готовы.
Можем, но пока не разобрались наверно лучше грязь не лить. Думаю разработчикам тоже позориться не охота, так что пока к разговору не подключились орлы из PR-отдела им все же следует верить.
V>Фигушки. Не вчера родились и знаем, как легко жонглировать понятиями. Вон они даже понятие "процесс" переиначили.
Это чем же это? Я бы еще понял если бы ты подискутировал с функциональциками которые рассказывают о процессах в Эрленг. Но тут... ?
V> Без дополнительного разъяснения, что именно кроется за их "процессами" непонятна суть происходящего. Так что, извини, но оставляю за собой право критического взгляда на вещи и обмен мнениями на форумах.
Оставляй конечно. Но тогда хоть аргументируй. А то я вижу одни догмы. Вроде как обсуждаешь управляемую ОС, а все скатывашся на обсуждение проблем ОС где защита делается на базе аппаратной защиты памяти и т.п.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Да где? Опять за старое?
За что за старое? Это ты за старое. Уже отказывашся от своих же слов. Не ты ли тут твердил, что нужно много писать на С/С++? Нахрена, объясни мне, нужны вообще С/++? Что нельзя сделать в небезопасном режиме Шарпа?
V> Я утвержал, что если HAL будет высокоуровневый (и я сильно подозреваю, что именно так, а не как ты там говоришь про 3 машинные инструкции), то много кода надо писать как unmanaged.
Ты уже задолбал. На Ченел9 раз двадцать было сказано, что почти все написано на C#, что С++ и т.п. использован в очень редких случаях типа стартап-кода который работает в реальном режиме процессора, что основная масса кода ОС — это безопасный код, что на ансэйфе в основном встречается в реализации ЖЦ.
Вот это и есть утверждение о том, чо они врут. Но ты уж извини, но аргументов у тебя ниже плинтуса. А в их разработке я ничего сверхестественного не вижу.
V> Если хочешь с чем-то спорить, то спорь именно с этим.
Это ты с чем-то хочешь спорить. Мне лично все ясно. Ситуация проще паренной репы. Ты просто не можешь свыкнуться с мыслью, что то что ты считал только что невозможным, более чем возможно.
V> Пока я ни одного нормального аргумента не увидел, кроме "надо верить на слово". Я и не спорю с ними, я дополняю их отчет размышлениями о доли "unmanaged" кода в их ОС. (Мое демократическое право )
А не надо дополнять чужие утверждения своими домыслами.
Ты можешь продемонстрировать, что приведет к появлению массы анменеджед-кода? И чем тебя не удовлетваряет нарисованная мной картина?
ЗЫ
Ну, и хорошо бы чтобы ты перестал путать термины ансэйф и анменеджед. C# принципиально не может породить анменеджед-код. Он может работать с анменеджед-дканными в ансэйф-режиме.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > > V>Неужели ты не знал, что в виндах можно писать kernel-mode дрова? > Полностью микроядерной NT никогда не была. И как раз там же в википедии > ответ на твой вопрос — "нафига HAL монолитным ОС". Как видишь, HAL и > микроядро по-прежднему никак не связаны. > > Я и не утвреждал, что NT имеет чистую микроядерную архитектуру. Я > утверждал что она основана на идеях микроядерной архитектуры и > постепенно сползала в монолитную сторону интегрируя в ядро все больше и > больше кода. NT 3.x практически не имела такого кода. А в 4.0 его было > уже выше крыши. Собственно это и сказано в приведенных ссылках.
Прошу прощения за занудливость, но все же, на каких именно идеях
микроядерной архитектуры идеях была основана NT?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, vdimas, Вы писали:
VD>За что за старое? Это ты за старое. Уже отказывашся от своих же слов. Не ты ли тут твердил, что нужно много писать на С/С++? Нахрена, объясни мне, нужны вообще С/++? Что нельзя сделать в небезопасном режиме Шарпа?
Я поднялся высоко по ветке и вот тот мой кусок, с которорым ты не согласился:
Может программа на C# непосредственно обращаться к портам ввода/вывода? или по фиксированным адресам памяти? Или настраивать внутренние регистры процессора на новые карты отображения виртуальных устройств ввода/вывода? НЕТ. И никогда не сможет by design. Очевидно, надо на ASM/C/C++ написать требуемый функционал, и приподнести его "на блюдечке" управляемой среде в виде простых интерфейсов. Реально это? Вполне.
Мне пофиг какой там язык будет (ASM/C/C++) или твой Барток (или как его там). Я говорил о невозможности сделать часть задач на C#, пользуясь своими знаниями об этом языке.
А вот твое выше (ты отвечал mrozov):
Кстати, ты все же ошибашся. Есть таки очень разумные и весьма дальновидные люди которые пишут драйверы на C#.
Ты про драйверы, я же сделал замечание про ядро. Если тебе не понравились мои примеры (ASM/C/C++), то уж извини — я не зря не уточнил, т.к. не могу знать подробности. Мне вообще-то все-равно, на чем это будет написано, но это должен быть язык, который позволяет ЭТО написать, и который уж никак не может быть использован для пользовательских приложений этой же ОС.
V>> Я утвержал, что если HAL будет высокоуровневый (и я сильно подозреваю, что именно так, а не как ты там говоришь про 3 машинные инструкции), то много кода надо писать как unmanaged.
VD>На Ченел9 раз двадцать было сказано, что почти все написано на C#, что С++ и т.п. использован в очень редких случаях типа стартап-кода который работает в реальном режиме процессора, что основная масса кода ОС — это безопасный код, что на ансэйфе в основном встречается в реализации ЖЦ.
VD>Это ты с чем-то хочешь спорить. Мне лично все ясно. Ситуация проще паренной репы. Ты просто не можешь свыкнуться с мыслью, что то что ты считал только что невозможным, более чем возможно.
Я тебе привел свою цитату из начала обсуждения. Не помню, чтобы я чего-то там не считал невозможным. Я обсуждаю долю unmanaged кода. Заодно unsafe (спасибо за поправки).
Вроде мы пришли уже к тому, что в их драйверах никакого unsafe и близко быть не может из-за плоской модели памяти самой ОС. (Кстати, в "плоском" режиме даже ввод/вывод происходит гораздо эффективней, так что, кое-какие бенефиты от плоской модели разумеется есть.)
VD>Ну, и хорошо бы чтобы ты перестал путать термины ансэйф и анменеджед. C# принципиально не может породить анменеджед-код. Он может работать с анменеджед-дканными в ансэйф-режиме.
Я говорил имено про unmanaged код в том первом абзаце. В принципе, если ты напираешь на "дыру" в С++ в виде возможности произвольной реинтерпретации памяти в С++, то твой unsafe позволяет точно такое же.
--------
Кстати, насчет моих "или по фиксированным адресам памяти?". Ты там позже прошелся по этой фразе, что я недостаточно знаю C# раз такое написал. Прочитай в той же фразе чуть дальше. Имелась ввиду фиксированная "плоская" память и реализация механизма виртуального режима (суть его одинакова как для портов так и для памяти). Насчет работы Сингулярити в едином адресном пространстве я прочел уже позже.
Здравствуйте, VladD2, Вы писали:
VD>Читай по губам. Повторяю последний раз. В безопасной среде исполнения HAL может работать в том же кольце защиты, что и прикладные процессы. Защита памяти ведь не требуется, так как ни один процесс не может повредить чужие данные. При этом стоимость вызовов HAL-а фактически становится такой же как стоимость вызовов внутрепроцессных методов (а то и быстрее если учесть что и на этом уровне можно заниматься инлайнингом и оптимизациями).
VD>По этому в такой архитектуре можно делать очень тонкий HAL, а все проблемы с таймерами и т.п. переносить в драйверы устройств работающий в отдельных процессах.
Браво, начал с того, что стал доказывать, что HAL присущь только микроядерной архитектуре, закончил своими предположениями по поводу того, как это работает в Сингулярити. Браво. Но сначала согласись, что не понимал роль HAL в произвольных архитектурах.
Конкретно по твоему вопросу. Ставлю 5 баксов, что таймер они все-таки включат в HAL а не в драйвер, невзирая на легкость вызова в среде единого адресного пространства
Есть такая фигня как целессобразность, я почему-то уверен, что разработчики обсуждаемого сабжа этим понятием пренебрегать не станут.
V>> Я где-то в других ветках уже задавался вопросом — а сколько приложений смогут работать в этой Сингулярити одновременно на 32-х битиной архитектуре? Аппаратная защита памяти реализует так же виртуальный механизм памяти. Весьма болезненно будет от него отказаться.
VD>Ага колосальная проблема. Ведь на сегодны все серверы забиты 5 и более гигами памяти, а 64-битных процессоров не видно даже в подзорную трубу. Согласен. Надо будет ее обсудеть... в "Колегах".
Обсуди. У меня в студии плагины типа Решарпера + Rational XDE + весьма большие проекты. В общем, 2-3 студии с разными солюшинами открыл и 2 гига памяти под завязку. А когда отлаживаешь работу дизайнеров в этих же проектах (т.е. запускаешь саму студию как процесс для отладки), и используешь отладку unmanaged+managed — то вообще труба.
VD>Насколько я понял прикладные процессы в Сингулярити приципиально обязаны быть безопасными.
Т.е. и драйверы тоже, правда же?
VD>Ну, а небезопасные возможности C# можно использовать внутри ОС для повышения быстродействия и замены С/С++.
V>>Да читали мы то что они пишут, не переживай. Насколько я понял, драйвера — это должны быть внешние сборки, которые можно будет динамически загружать/выгружать.
VD>Это без разницы. Внешние сборки тоже в лучшем виде прекомпилируются. Это можно делать даже на первой версии дотнета.
OK, здесь действительно возможны решения (насчет pre-JIT).
VD>Оставляй конечно. Но тогда хоть аргументируй. А то я вижу одни догмы. Вроде как обсуждаешь управляемую ОС, а все скатывашся на обсуждение проблем ОС где защита делается на базе аппаратной защиты памяти и т.п.
Вообще-то мы "зацепились" после моего предположения, что с их концепцией им потребуется довольно высокая абстракция от железки, т.е. некий приличный базис "unsafe" должен будет существовать для конкретной железки.
Почему я делаю такое предположение? Глядя на происходящее в мире Java-встраиваемых устройств. Речь идет о переносимости, причем переносимости не только пользовательстких приложений, но и кода самой ОС (который немаленький).
Стараться сделать ВСЕСЬ КОД ЯДРА управляемым элементарно НЕЦЕЛЕСООБРАЗНО (т.е. опуститься до уровня inp()/outp() и не выше). Опускание на такой уровень абсолютно ничего не дает управляемой ОС, чей фокус заострен все-таки на немного других моментах. После прочтения последних их отчетов (до этого последний раз читал более полугода назад), мне кажется, что я скорее прав, чем нет.
