OSDev

для всех
Текущее время: 29 мар 2024, 15:29

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 61 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7  След.
Автор Сообщение
 Заголовок сообщения: Re: Химера ОС
СообщениеДобавлено: 22 ноя 2007, 20:08 

Зарегистрирован: 21 сен 2007, 17:24
Сообщения: 1088
Откуда: Балаково
Нестандартные устройства нет нужды эмулировать, их надо просто раздавать драйверам. Драйвер PCI должен скрывать только занятые устройства. Гостевая ОС после получения списка устройств, должна запрашивать у Гипервизора передачу выбранных устройств в своё пользование, чтобы драйвер PCI вёл список занятых устройств. Как в нано-ядре :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Химера ОС
СообщениеДобавлено: 23 ноя 2007, 02:39 

Зарегистрирован: 28 окт 2007, 18:33
Сообщения: 1418
Chizh

Так гостевая ОС не может запросить эту передачу, поскольку думает, что работает на реальной машине. Значит, надо полностью поддерживать конфигурационные возможности PCI, причём помнить, что разные гостевые ОС могут выделить своим виртуальным устройствам одинаковые адреса, из-за чего их нельзя физически сконфигурировать так, как гостевые ОС хотят, а значит, всё равно надо перехватывать обращения к этим устройствам. В общем, задача решаемая, но всё равно требующая определённых усилий. Это явно не элементарный гипервизор :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Химера ОС
СообщениеДобавлено: 25 ноя 2007, 16:11 

Зарегистрирован: 16 ноя 2007, 02:36
Сообщения: 27
Однако существующие ОС обращаются к аппаратуре напрямую и ни о каких "серверах", осуществляющих "трансляцию", не ведают. Таким образом, Вам необходимо перехватывать все обращения к аппаратуре и эмулировать эту самую аппаратуру. Перехват проблем не представляет...
В частности, эмулировать придётся все стандартны устройства ПК и стандартные технологии вроде PnP, ACPI и т.д. -- без такой поддержки обычные ОС под этим самым гипервизором просто не будут работать.

Проблема с PnP и ACPI высосана из пальца. Если даже BIOS окажется не способным сконфигурировать все устройства, Вы можете сконфигурировать их "вручную" (BIOS setup) или подготовить специальный "сервер", который это сделает это при запуске системы.
У W2K есть /PCILOCK в boot.ini, а XP и 2003 стараются не менять распределение сделанное BIOS:
http://download.microsoft.com/download/9/c...84a/PCI-rsc.doc
"All recent versions of Windows operating systems, including Windows XP, Windows Server 2003, and Windows Vista, respect and attempt to preserve the boot configuration of PCI devices. If it is impossible to do so, the operating system chooses an acceptable location for the device."
Linux также обычно не пытается делать реконфигурацию PnP.

Но, на самом деле, всё это - совершенно не важно, потому что "химера" строится в соотстветствии с простым принципом: "перехватывает Гипервизор, а эмулируют - Сервера". Таким образом, необходиость преодоления проблем связанных с управлением и распределеним оборудования (если таковые возникнут) не приведёт к усложнению Гипервизора.

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

Возможно я недостаточно ясно объяснил основную концепцию. Попробую иначе:
Обычные ВМ виртуализируют всю аппаратуру ПК. Это сильно снижает еффективность гостевой ОС.
Почему-бы не разрешить гостевой ОС напрямую работать с аппаратурой не используемой хост ОС ?
Тогда гостевая ОС будет работать как с виртуальной, так и с физической аппаратурой.
Таких гостевых ОС может быть несколько (каждой выделена своя часть аппаратуры).
На гостевой ОС может выполняться программа-емулятор, которая виртуализирует выделенную ей аппаратуру для других гостей.
Получается, что гостевые ОС могут снабжать друг друга виртуальными ресурсами.
Получается, что хост ОС вообще не нужна и гости перестают быть гостями.
С другой стороны, бывшие гости должны разделять память и процессор, а также иметь возможность общаться между собой.
Это может обеспечить небольшая резидентная программа - Гипервизор.
Нужно иметь "схему соединения" ВМ в общую систему и "план распределения аппаратуры".
Гипервизор должен обеспечивать каждую ВМ аппаратурой состоящей из виртуальных и физических устройств.Все обращения ВМ к аппаратуре перехватываются Гипервизором и либо передаются эмулятору на другой ВМ, либо пропускаются к аппаратуре.
Рассмотрим крайний случай с двумя ВМ. Вся аппаратура у одной ВМ (А), а у другой ВМ (Б) вся аппаратура виртуальная, обеспечиваемая эмуляторами, выполняющимися на ВМ-А. Схема, очевидно работоспособная.
Теперь заберём физический дисплей у ВМ-А и отдадим его ВМ-Б, добавив к её ОС программный эмулятор SVGA.
Такая систеа из двух ВМ тоже будет работоспособной.
Добавим третью ВМ (В), которой отдадим все диски и запустим на ней эмулятор, который будет снабжать первые две виртуальными дисками.
Заметим, что ВМ-А по-прежнему владеет физическим BIOSом, таким образом возможен конфликт между ВМ-В и ВМ-А.
Добавляем ВМ-Г, которой отдаём физический BIOS и запускаем на ней BIOS-эмулятор, который эмулирует дисковый сервис BIOSа через обращения к ВМ-В.
И т.д. и т.п.
Заметьте, что мы совершенно не обязаны (хотя и можем) добавлять ВМ по одной. Кроме того, разрешение конфликтов и расширение функциональности производится путём добавления новых "серверов" (т.е. ВМ), а не усложнения Гипервизора. В частности, при необходимости поддержки ACPI его эмулятор (а точнее "поставщик") может быть запущен на отдельной ВМ (возможно под DOSом).

Имеет смысл говорить что каждый "сервер" является как поставщиком, так и потребителем системных ресурсов (в частности виртуальной аппаратуры). Гипервизор только связывает поставщиков с потребителями и раздаёт потребителям физическую аппаратуру ПК.

Неужели и теперь не врубились?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Химера ОС
СообщениеДобавлено: 25 ноя 2007, 16:55 

Зарегистрирован: 21 сен 2007, 17:24
Сообщения: 1088
Откуда: Балаково
Цитата:
Обычные ВМ виртуализируют всю аппаратуру ПК.
К стати, только ту, которая указана в конфигурации ВМ. Остальные устройства ВМ не эмулирует. При использовании в качестве хоста Windows 98, получится прямое обращение к аппаратуре, т.к. Windows 98 не перехватывает обращения к свободным портам. А если порты заняты, то вызывается обработчик драйвера (считай гипервизор). Т.е. я на 90% уверен, что подобную систему можно реализовать даже на платформе какой-нибудь существующей ОС, добавив в неё драйвер-гипервизор.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Химера ОС
СообщениеДобавлено: 25 ноя 2007, 21:52 

Зарегистрирован: 28 окт 2007, 18:33
Сообщения: 1418
alexei
Цитата:
Проблема с PnP и ACPI высосана из пальца. Если даже BIOS окажется не способным сконфигурировать все устройства, Вы можете сконфигурировать их "вручную" (BIOS setup) или подготовить специальный "сервер", который это сделает это при запуске системы.
...
Linux также обычно не пытается делать реконфигурацию PnP


Любая ОС, поддерживающая PnP, имеет полное право переконфигурировать всю аппаратуру по своему усмотрению, и то, что конкретная ОС это не делает, ещё не значит, что это не делает никто. А значит, необходимо обеспечить всем гостевым системам возможность осуществить конфигурирование виртуальных' устройств, а для этого нужно их эмулировать правильным образом. Так что, извиняюсь, проблема не в начальном конфигурировании устройств (при загрузке системы, реально работающей с аппаратурой, т.е. гипервизора), а в том, что гостевые системы считают, что работают на реальном "железе" со всеми вытекающими.

Цитата:
Но, на самом деле, всё это - совершенно не важно, потому что "химера" строится в соотстветствии с простым принципом: "перехватывает Гипервизор, а эмулируют - Сервера". Таким образом, необходиость преодоления проблем связанных с управлением и распределеним оборудования (если таковые возникнут) не приведёт к усложнению Гипервизора


Похоже, Вы абсолютно не представляете себе, что такое виртуализация и как работает аппаратура. Как ваши любимые сервера будут что-то эмулировать, если эти сервера, как Вы утверждали несколькими постами раньше, могут быть обычными операционками типа Винды или Линуха? Эти системы понятия не имеют о том, что они кого-то должны эмулировать -- они уверены, что работают на реальной аппаратуре, а поэтому будут обращаться к ней, не задумываясь о наличии какого-то там гипервизора. В частности, в процессе загрузки все эти системы будут требовать наличия правильно построенных информационных блоков ACPI, из которых определят конфигурацию оборудования на материнской плате, затем будут настраивать APIC, возможно, перенастроят устройства PnP, подключённые к PCI и другим шинам... Причём каждая ОС-"сервер" будет уверена, что она выполняется на "голом" железе и машина находится в её полном распоряжении, а соответственно, и настройку будет производить под себя. Как Вы эту проблему собираетесь решать, не обеспечив эмуляции всех без исключения устройств, используемых каждой из систем?

Цитата:
С другой стороны, я совсем не уверен, что Как раз управление памятью и разделение процессора не представляют никаких сложностей и реализуются очень просто. Дело в том, что если "обычная" ОС может зафиксировать в физической памяти страницы, которые ей необходимы для обработки системных событий в реальном времени, то все страницы "сервера" могут оказаться выгружены из физической памяти на диск (если не принять специальных мер)


Увы, не сомневаюсь, что для Вас это кажется проблематичным: своё слабое знакомство с "железными реалиями", непонимание многих важных принципов работы аппаратуры Вы уже неоднократно демонстрировали, поэтому я просто вынужден предположить, что и с функционированием виртуальной памяти Вы не слишком хорошо знакомы (если ошибаюсь -- прошу прощения). Не буду тут расписывать, как же осуществляется управление памятью и процессором в таких случаях, лишь повторю, что это по сравнению с управлением устройствами -- сущие пустяки. Правда, эффективность может прилично упасть, ведь обычные ОС, использующие виртуальную память, уверены, что вся память ПК принадлежит им, а поэтому создаваемые ими таблицы страниц гипервизор будет вынужден корректировать под реальное распределение памяти, причём так корректировать, чтобы гостевые системы этого не замечали, а это -- приличные накладные расходы. Как их уменьшить и всё такое прочее, можно обсуждать в отдельной теме, причём скорей в разделе "теоретические вопросы". Кроме того, прежде чем обсуждать подобные вещи, надо сначала понять, что Ваша идея в том виде, в каком она есть, абсолютно нежизнеспособна -- как раз из-за аппаратуры, которую нельзя просто так взять и разделить между различными осями-"серверами".

Цитата:
Кроме того, "сервер" может закрыть прерывания только на своей ВМ, а не на физическом ПК


Вообще-то прерывания запрещают, а не закрывают, но это так -- лингвистические придирки. Однако проблема существует, причём проблема не только с запретом прерываний вообще (установкой или сбросом соответствующего флага), но и запретом конкретных прерываний путём манипуляций с APIC. Ну и как, скажите, Вы будете решать эту проблему без полной эмуляции APIC? Оси-сервера -- они понятия не имеют, что работают под Вашим гипервизором, они уверены, что работают на самом настоящем ПК, с которым могут творить всё, что захотят.

Цитата:
Обычные ВМ виртуализируют всю аппаратуру ПК. Это сильно снижает еффективность гостевой ОС


Сильно -- не сильно, а снижает, тут не поспоришь.

Цитата:
Почему-бы не разрешить гостевой ОС напрямую работать с аппаратурой не используемой хост ОС ?


По одной простой причине: вся' аппаратура ПК взаимосвязана, и "выдрать" какое-то устройство и передать контроль над ним одной системе, а остальные оставить другой, нельзя. Первая из причин: конфликт в настройке адресов ресурсов, потому что ОС не обязаны' довольствоваться той настройкой, что выполнила BIOS, и могут перенастраивать устройства на свой лад, а это чревато возникновением конфликтов. Вторая причина: есть устройства, которые невозможно разделить. К ним гарантированно относятся APIC, системные таймеры, по крайней мере часть мостов между шинами, контроллеры жёстких дисков (все оси используют жёсткие диски, причём не с помощью каких-то там "серверов", а напрямую обращаясь к аппаратуре); вероятно, сюда же пойдут и хост-контроллеры USB. Ну а поскольку разделить эти устройства нельзя, а они нужны всем осям, то придётся их эмулировать программными средствами (в простейшем случае -- отображать запросы гостевых систем к виртуальным ресурсам на соответствующие физические).

Цитата:
Тогда гостевая ОС будет работать как с виртуальной, так и с физической аппаратурой


Не получится, как уже сказал. С физической можно только в том случае, если эта аппаратура: а) абсолютно никому больше не нужна; б) настраивается всегда стандартным образом. А пункт "б" соблюдается разве что для COM- и LPT-портов, клавиатуры и мыши PS/2 да контроллера гибких дисков.

Цитата:
Таких гостевых ОС может быть несколько (каждой выделена своя часть аппаратуры).
На гостевой ОС может выполняться программа-емулятор, которая виртуализирует выделенную ей аппаратуру для других гостей.
Получается, что гостевые ОС могут снабжать друг друга виртуальными ресурсами


Только вот гостевые оси понятия не имеют, что кто-то их снабжает "виртуальными ресурсами" -- им подавай реальные шины и контроллеры (ну или их точную программную эмуляцию). Так что никак Вы не сможете "виртуализировать" аппаратуру для "других гостей" -- эти "другие гости" сначала должны уметь пользоваться виртуализированной аппаратурой.

Цитата:
Нужно иметь "схему соединения" ВМ в общую систему и "план распределения аппаратуры"


Угу, только Вы забываете про один малюсенький нюанс: ни одна из обычных осей не знает ни о каких "схемах соединения" и "планах распределения аппаратуры". А значит, Ваша идея будет работать только в том случае, если "серверами" будут специально' написанные под Ваш гипервизор системы. Что фактически превращается в разработку традиционной ОС с микроядерной архитектурой.

Цитата:
Рассмотрим крайний случай с двумя ВМ. Вся аппаратура у одной ВМ (А), а у другой ВМ (Б) вся аппаратура виртуальная, обеспечиваемая эмуляторами, выполняющимися на ВМ-А. Схема, очевидно работоспособная.
Теперь заберём физический дисплей у ВМ-А и отдадим его ВМ-Б, добавив к её ОС программный эмулятор SVGA


Похоже, Вы не заметили противоречия у самого себя. Схема, когда всё реальное "железо" у одного, а другой (или другие) пользуются только виртуальным -- действительно работоспособна. Только эти виртуальные "железяки" придётся эмулировать, что Вы, собственно, и сами говорите, например: "добавив к её ОС программный эмулятор SVGA". Вот и получается, что "добавив" всюду программные эмуляторы всех железяк, мы получим работающую систему виртуальных машин. Только здесь одно "но": либо вся эмуляция сосредоточена в гипервизоре, либо сервисы, осуществляющие эмуляцию, являются специально написанными, а отнюдь не стандартными осями, к чему Вы призывали в самом начале. В любом случае всё сводится к разработке полной операционной системы.

Цитата:
Неужели и теперь не врубились?


С полным основанием переадресую этот вопрос Вам :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Химера ОС
СообщениеДобавлено: 27 ноя 2007, 12:31 

Зарегистрирован: 16 ноя 2007, 02:36
Сообщения: 27
Цитата:
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><td id='QUOTE'><!--QuoteEBegin-->Проблема с PnP и ACPI высосана из пальца. Если даже BIOS окажется не способным сконфигурировать все устройства, Вы можете сконфигурировать их "вручную" (BIOS setup) или подготовить специальный "сервер", который это сделает это при запуске системы.
...
Linux также обычно не пытается делать реконфигурацию PnP

Любая ОС, поддерживающая PnP, имеет полное право переконфигурировать всю аппаратуру по своему усмотрению, и то, что конкретная ОС это не делает, ещё не значит, что это не делает никто. А значит, необходимо обеспечить всем гостевым системам возможность осуществить конфигурирование виртуальных' устройств, а для этого нужно их эмулировать правильным образом. Так что, извиняюсь, проблема не в начальном конфигурировании устройств (при загрузке системы, реально работающей с аппаратурой, т.е. гипервизора), а в том, что гостевые системы считают, что работают на реальном "железе" со всеми вытекающими.<!--QuoteEnd-->QUOTE<div class='postcolor'><!--QuoteEEnd-->
Вспоминая старый анекдот про слона в зоопарке, "Съесть то он съест, да кто-ж ему даст?"
Гостевые системы могут захотеть переконфигурировать виртуальную аппаратуру, но в нашей власти им этого не позволить.
Хотя ещё важнее то, что мы сами выбираем какие ОС запускать и как их настраивать. Вы, должно быть, читали об ОС с ограниченной функциональностью построенных как на базе Windows, так и Linux. Они-то как раз и явлются лучшими кандидатами для создания "серверов". Напоминаю, что я предложил использовать уже иеющиеся ОС по двум причинам: 1.работа с неописанным железом 2.быстрое получение работающей системы. Обеспечеие запуска под "Химерой" любой ОС в любыми настройками, да ещё в качестве "сервера аппаратуры" (т.е. имещей непосредственный доступ к аппаратуре) никогда не предлагалось.

Цитата:
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><td id='QUOTE'><!--QuoteEBegin-->Почему-бы не разрешить гостевой ОС напрямую работать с аппаратурой не используемой хост ОС ?

По одной простой причине: вся'аппаратура ПК взаимосвязана, и "выдрать" какое-то устройство и передать контроль над ним одной системе, а остальные оставить другой, нельзя. Первая из причин: конфликт в настройке адресов ресурсов, потому что ОС 'не обязаны'довольствоваться той настройкой, что выполнила BIOS, и могут перенастраивать устройства на свой лад, а это чревато возникновением конфликтов. Вторая причина: есть устройства, которые невозможно разделить. К ним гарантированно относятся APIC, системные таймеры, по крайней мере часть мостов между шинами, контроллеры жёстких дисков (все оси используют жёсткие диски, причём не с помощью каких-то там "серверов", а напрямую обращаясь к аппаратуре); вероятно, сюда же пойдут и хост-контроллеры USB. Ну а поскольку разделить эти устройства нельзя, а они нужны всем осям, то придётся их эмулировать программными средствами (в простейшем случае -- отображать запросы гостевых систем к виртуальным ресурсам на соответствующие физические).<!--QuoteEnd-->QUOTE<div class='postcolor'><!--QuoteEEnd--> Вобщем-то, всё это правильно, хоть Вы и несколько преувеличиваете возникающие трудности. Существо нашего спора в том, что из необходимости эмуляции устройств Вы делаете вывод о том, что эмуляторы должны быть частью Гипервизора, тогда как я каждй раз подчёркиваю, что эмуляторы выполняются на "серверах", а Гипервизор всего лишь перехватывает запросы ОС к аппаратуре и либо пропускает их к железу, либо направляет их на тот "сервер", который предоставляет соответствующее виртуальное устройство. Возможно, я забыл подчеркнуть, что "сервер" - это "гостевая ОС " на которой ваполняется программа-эмулятор аппаратуры (или абстрактного виртуального ресурса) ".
Написание эмуляторов "с нуля", конечно, было бы трудной задачей, но их вокруг как собак нерезанных и с исходняками (см. QEMU, XEN и т.д.)
Ожидаю вопрос "на засыпку" - Это через сколько-же "серверов" любому обращению к железу придётся прохренячить пока оно дойдёт до реальной железки? Отвечаю: возможно, через много :)
И сколько же системных ресурсов на это пойдёт?
Не исключено, что меньше, чем кажется с первого взгляда. Опять-же, смотря как всё написать :)




Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Химера ОС
СообщениеДобавлено: 27 ноя 2007, 13:22 

Зарегистрирован: 28 окт 2007, 18:33
Сообщения: 1418
alexei

Цитата:
Гостевые системы могут захотеть переконфигурировать виртуальную аппаратуру, но в нашей власти им этого не позволить


В связи с этим заявлением вспоминается один старый фильм про Ивана Васильевича и князя Милославского, но цитировать не буду: ещё сочтут оскорблением личности...

Ну а говоря проще, если Windows хочет настроить некое устройство, она просто-напросто рухнет, если означенное устройство не будет настроено так, как ей нужно. Это же самое оносится и к любой другой ОС. Аппаратура не может не позволить оси выполнять настройку.

Цитата:
Напоминаю, что я предложил использовать уже иеющиеся ОС по двум причинам: 1.работа с неописанным железом 2.быстрое получение работающей системы. Обеспечеие запуска под "Химерой" любой ОС в любыми настройками, да ещё в качестве "сервера аппаратуры" (т.е. имещей непосредственный доступ к аппаратуре) никогда не предлагалось


А с чего Вы взяли, что "кастрированные" ОС не захотят настраивать аппаратуру, да ещё "неописанную"?

Цитата:
Существо нашего спора в том, что из необходимости эмуляции устройств Вы делаете вывод о том, что эмуляторы должны быть частью Гипервизора, тогда как я каждй раз подчёркиваю, что эмуляторы выполняются на "серверах", а Гипервизор всего лишь перехватывает запросы ОС к аппаратуре и либо пропускает их к железу, либо направляет их на тот "сервер", который предоставляет соответствующее виртуальное устройство


Да пишите эмулятор устройства где угодно -- хоть в гипервизоре, хоть в гостевой ОС. Проблема всего одна: эмулятор 'придётся' писать. А посему все Ваши заявления о возможности быстрого создания работоспособной системы, мягко говоря, не имеют под собой оснований.

Цитата:
Написание эмуляторов "с нуля", конечно, было бы трудной задачей, но их вокруг как собак нерезанных и с исходняками


А сколько из них реально работоспособных, т.е. на которых нормально работают стандартные оси, используя при этом любые имеющиеся физические ресурсы компьютера (например, звуковые платы, видеоускорители и т.п.), а не "джентльменский набор" типа "клава-мыша-SVGA-HDD-CD"?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Химера ОС
СообщениеДобавлено: 28 ноя 2007, 04:45 

Зарегистрирован: 16 ноя 2007, 02:36
Сообщения: 27
Цитата:
Ну а говоря проще, если Windows хочет настроить некое устройство, она просто-напросто рухнет, если означенное устройство не будет настроено так, как ей нужно. Это же самое оносится и к любой другой ОС. Аппаратура не может не позволить оси выполнять настройку.

Из того, что я читал по этому вопросу, у меня создалось впечатление, что конкретное устройство настраивает его драйвер с учётом того, что это устройство про себя сообщает. Поскольку взаимодействие драйвера и устройства находится под нашим контролем, мы можем при необходимости "надурить" их как нам потребуется (в виндах это делается добавлением filter driver).
Необходимость/трудоёмкость такой работы зависит от устройства. Например, на запрос про ACPI можем ответить "отсутствует", а обращения к конкркетному дисковому накопителю пропускать без изменений (примеры только чтобы пояснить, возможно неудачные).

Цитата:
Да пишите эмулятор устройства где угодно -- хоть в гипервизоре, хоть в гостевой ОС. Проблема всего одна: эмулятор придётся' писать. А посему все Ваши заявления о возможности быстрого создания работоспособной системы, мягко говоря, не имеют под собой оснований.
Самое важное исходное положение было то, что Гипервизор может быть сделан относительно простым, а вся эмуляция/трансляция вынесена на "серверы".

Когда я говорю о "создании работоспособной системы" я имею в виду получение системы с некой минимальной функциональностью, которая позволит продолжить разработку в относительно комфортабельных условиях.

Цитата:
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><td id='QUOTE'><!--QuoteEBegin-->Написание эмуляторов "с нуля", конечно, было бы трудной задачей, но их вокруг как собак нерезанных и с исходняками
А сколько из них реально работоспособных, т.е. на которых нормально работают стандартные оси, используя при этом любые имеющиеся физические ресурсы компьютера (например, звуковые платы, видеоускорители и т.п.), а не "джентльменский набор" типа "клава-мыша-SVGA-HDD-CD"?<!--QuoteEnd-->QUOTE'<div class='postcolor'><!--QuoteEEnd--> Ну во-первых ОС-самоделки даже до "джентльменского набора" не всегда доползают. Во-вторых использование таких ресурсов, как "видеоускоритель" едва-ли необходимо кому-либо кроме "сервера" видео карты (хотя я и не отрицаю потенциальной "динамической реконфигурации", чтобы, например, временно отдать видео карту конкретной ВМ и играть на ней в видео игры).



Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Химера ОС
СообщениеДобавлено: 28 ноя 2007, 07:52 

Зарегистрирован: 28 окт 2007, 18:33
Сообщения: 1418
alexei
Цитата:
Из того, что я читал по этому вопросу, у меня создалось впечатление, что конкретное устройство настраивает его драйвер с учётом того, что это устройство про себя сообщает


Ну, во-первых, настраивает отнюдь не драйвер в гордом одиночестве. А во-вторых, устройство лишь сообщает, какие виды ресурсов и в каком количестве ему потребны (например, нужен диапазон из 16 байт в адресном пространстве ввода-вывода и из 4 килобайт в адресном пространстве памяти). Где конкретно будут выделены такие диапазоны, является делом ОС в целом, а не одного конкретного драйвера, ведь нужно обеспечивать, чтобы один и тот же ресурс не выделялся сразу нескольким устройствам. Потому и невозможно обойтись без эмуляции, если на одной ЭВМ выполняется сразу несколько осей: каждая ось настраивает устройства по своему разумению, не согласуя это с другими осями, поскольку даже не подозревает об их существовании. И если одна ось выделяет диапазон, предположим 1000-1010 контроллеру USB, а другая ось выделяет тот же самый диапазон контроллеру FireWire, отказать нельзя ни одной, но и удовлетворить такие требования тоже нельзя: в первом случае оси не будут работать (поскольку они твёрдо уверены, что аппаратура выполнит их команды по настройке конкретных контроллеров), а во втором -- получится конфликт ресурсов, что тоже приведёт к неработоспособности системы в целом.

Цитата:
Самое важное исходное положение было то, что Гипервизор может быть сделан относительно простым, а вся эмуляция/трансляция вынесена на "серверы"


Между прочим, микроядро тоже можно сделать не просто "относительно простым", а очень простым -- буквально несколько килобайт, а всё осталное возложить на "серверы". Только сложность ОС в целом от этого не уменьшится.

Цитата:
Когда я говорю о "создании работоспособной системы" я имею в виду получение системы с некой минимальной функциональностью, которая позволит продолжить разработку в относительно комфортабельных условиях


Ну так что мешает продемонстрировать это на практике? ;)

Цитата:
Ну во-первых ОС-самоделки даже до "джентльменского набора" не всегда доползают


Совершенно согласен, но дело здесь далеко не только в сложности создания ОС с нуля. ИМХО, куда большее значение имеет непонимание большинством осеписателей того, что они вообще должны делать, чтобы решить ту или иную задачу. Поэтому-то многие загибаются сразу после написания вполне работоспособного начального загрузчика: его сделали, а что делать дальше -- непонятно. Ну или кидаются в реализацию GUI, не реализовав куда более необходимые системые сервисы (управление процессами, потоками, памятью, вводом-выводом, синхронизацией и межпроцессным взаимодействием).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Химера ОС
СообщениеДобавлено: 29 ноя 2007, 16:16 

Зарегистрирован: 16 ноя 2007, 02:36
Сообщения: 27
Цитата:
alexei
Цитата:
Из того, что я читал по этому вопросу, у меня создалось впечатление, что конкретное устройство настраивает его драйвер с учётом того, что это устройство про себя сообщает


Ну, во-первых, настраивает отнюдь не драйвер в гордом одиночестве. А во-вторых, устройство лишь сообщает, какие виды ресурсов и в каком количестве ему потребны (например, нужен диапазон из 16 байт в адресном пространстве ввода-вывода и из 4 килобайт в адресном пространстве памяти). Где конкретно будут выделены такие диапазоны, является делом ОС в целом, а не одного конкретного драйвера, ведь нужно обеспечивать, чтобы один и тот же ресурс не выделялся сразу нескольким устройствам. Потому и невозможно обойтись без эмуляции, если на одной ЭВМ выполняется сразу несколько осей: каждая ось настраивает устройства по своему разумению, не согласуя это с другими осями, поскольку даже не подозревает об их существовании. И если одна ось выделяет диапазон, предположим 1000-1010 контроллеру USB, а другая ось выделяет тот же самый диапазон контроллеру FireWire, отказать нельзя ни одной, но и удовлетворить такие требования тоже нельзя: в первом случае оси не будут работать (поскольку они твёрдо уверены, что аппаратура выполнит их команды по настройке конкретных контроллеров), а во втором -- получится конфликт ресурсов, что тоже приведёт к неработоспособности системы в целом.

Цитата:
Самое важное исходное положение было то, что Гипервизор может быть сделан относительно простым, а вся эмуляция/трансляция вынесена на "серверы"


Между прочим, микроядро тоже можно сделать не просто "относительно простым", а очень простым -- буквально несколько килобайт, а всё осталное возложить на "серверы". Только сложность ОС в целом от этого не уменьшится.

Цитата:
Когда я говорю о "создании работоспособной системы" я имею в виду получение системы с некой минимальной функциональностью, которая позволит продолжить разработку в относительно комфортабельных условиях


Ну так что мешает продемонстрировать это на практике? ;)

Цитата:
Ну во-первых ОС-самоделки даже до "джентльменского набора" не всегда доползают


Совершенно согласен, но дело здесь далеко не только в сложности создания ОС с нуля. ИМХО, куда большее значение имеет непонимание большинством осеписателей того, что они вообще должны делать, чтобы решить ту или иную задачу. Поэтому-то многие загибаются сразу после написания вполне работоспособного начального загрузчика: его сделали, а что делать дальше -- непонятно. Ну или кидаются в реализацию GUI, не реализовав куда более необходимые системые сервисы (управление процессами, потоками, памятью, вводом-выводом, синхронизацией и межпроцессным взаимодействием).
//SII 28.11.2007, 07:52

Что-то мне настройка устройств не кажется уж такой непобедимой :)
На вскидку:
- Разным осям можно подбросить разные описания имеющейся памяти.
- Отображение обащений ОС к памяти под нашим контролем (вроде-бы AMD-V позволяет просто задать mapping).
И вообще, XEN, например запускает винду без ACPI, и ничего, всё работает.

Другое дело, что почитал я AMDшные доки и погрустнел :( Столько всего наворотили, да ещё нужно учитывать их "errata" :( Похоже, что ко всей икебане придётся добавить "сервер процессора", который будет его правильно настраивать, а для "гостей" эмулировать что-нибудь по-проще.

На самом деле, самое сложное, это запуск ("разворачивание") химеры и её серверов. Намётки есть, но будут пересмотрены и детализированы, а там, может, и гипервизор "задышит".

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 61 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 3


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB