Сравнение ядер операционок

← →
iZEN © (2006-11-26 18:32) [0]

Здесь:
http://widefox.pbwiki.com/Kernel%20Comparison%20Linux%20vs%20Windows
и здесь:
http://en.wikipedia.org/wiki/Comparison_of_kernels

Однако...

← →
DrPass © (2006-11-26 20:44) [1]

По первому же вопросу - с каких это пор у Windows оказалось монолитное ядро?

← →
Anatoly Podgoretsky © (2006-11-26 20:51) [2]

> DrPass (26.11.2006 20:44:01) [1]

Авторам простительно, наверно у них другие цели.

← →
iZEN © (2006-11-26 21:18) [3]

> DrPass © (26.11.06 20:44) [1]
>
> По первому же вопросу - с каких это пор у Windows оказалось
> монолитное ядро?

У Виндоуз ядро гибридное. Это с тех самых пор, когда MS начала допускать работу на уровне ядра видео- и принтерные драйверы.

http://en.wikipedia.org/wiki/Hybrid_kernel
Proponents Microsoft normally uses the term "microkernel" and sometimes "modified microkernel", "modified microkernel or macrokernel"[1] when describing the kernel part of the architecture of the Windows NT operating system line. The whole architecture is said to be composed of a "modified microkernel", drivers, Executive, and HAL, and GDI/GDI+ all in kernel space. There are user space APIs supporting different OS environments. Hybrid kernel example - NT kernel Description The best known example of a hybrid kernel is the NT kernel inside Windows NT, Windows 2000, Windows XP, Windows 2003, and Windows Vista. All Windows NT kernel services run in kernel space. The HAL, Executive, and drivers are all also in kernel space. Since NT 4.0, the graphical/printing subsystem (GDI, later GDI+) was also brought into kernel space to improve performance (see diagram). http://upload.wikimedia.org/wikipedia/en/thumb/5/5d/Windows_2000_architecture.svg/275px-Windows_2000_architecture.svg.png The lower levels of the architecture are in kernel mode. They consist of the lowest level - the HAL. Then the kernel and drivers which sit between the HAL and the NT executive. The Executive provides the equivalent of microkernel servers but, unlike microkernels, faster interfacing can be used in order to optimize performance. The higher levels of the architecture are in fact in user mode, firstly the Native API which calls routines in the Executive. Above the Native API are system call interfaces providing APIs for different operating systems - Win32 (Win32 API), OS/2 (OS/2 API), POSIX (POSIX API). It is also worth noting that the OS/2 and POSIX APIs are built upon the Win32 API, and not the Native API. Classification Microsoft uses various terms including macrokernel[1]. The NT kernel is predominantly monolithic (that is kernel mode), structured internally in a similar way to a microkernel, but it is only slightly microkernel due to user mode OS APIs. That has always been the case - even before NT 3.51. Ironically, monolithic kernels normally have graphics/printing in user mode, NT 4.0 and newer contain the GDI (or later GDI+) in kernel mode.

Ещё странно другое. В книге с описанием архитектуры и реализации FreeBSD Маршалл МакКузик говорит о микроядерной архитектуре этой самой FreeBSD, что не является полной правдой. Хотя с другой стороны, большинство демонов *BSD представляют собой процессы пользовательского уровня.

← →
iZEN © (2006-11-26 21:26) [4]

> Anatoly Podgoretsky © (26.11.06 20:51) [2]
>
> Авторам простительно, наверно у них другие цели.

Какие же?

← →
Anatoly Podgoretsky © (2006-11-26 22:13) [5]

> iZEN (26.11.2006 21:26:04) [4]

Ну не знаю, но какие то цели авторы преследуют?

← →
cyborg © (2006-11-27 09:38) [6]

>[5] Anatoly Podgoretsky © (26.11.06 22:13)

Конечно. Всячески пытаясь не дать русским нормально почитать сравнение путём написания своих текстов нерусскими буквами и словами.

← →
Игорь Шевченко © (2006-11-27 10:20) [7]

Уже давно известно, что микроядро - вещь тормозная.

← →
iZEN © (2006-11-27 13:11) [8]

> Игорь Шевченко © (27.11.06 10:20) [7]
>
> Уже давно известно, что микроядро - вещь тормозная.

Бред.

Микроядерные операционки давно используется в критических (по надёжности) системах и в системах реального времени. Всё дело в том, какое количество сервисов пользовательского уровня юудет работать с API микроядра.

Монолитное ядро можно сравнить с объектом (в квази-ООП-программе), у которого все поля и методы public, и ими пользуются любые системные приложения, пройдя через несложный контроль доступа.

Микроядерную архитектуру можно сравнить с ООП-парадигмой, в которой досконально соблюдается один основополагающий принцип инкапсуляции данных, а всё взаимодействие производится через защищённый интерфейс.

iZEN © (27.11.06 13:11) [8]

> Бред.

Обоснуй.

> Монолитное ядро можно сравнить с объектом (в квази-ООП-программе),
> у которого все поля и методы public, и ими пользуются любые
> системные приложения, пройдя через несложный контроль доступа.
>
>
> Микроядерную архитектуру можно сравнить с ООП-парадигмой,
> в которой досконально соблюдается один основополагающий
> принцип инкапсуляции данных, а всё взаимодействие производится
> через защищённый интерфейс.

Какое отношение твои фразы имеют к быстродействию ?

> Игорь Шевченко © (27.11.06 13:26) [9]
> iZEN © (27.11.06 13:11) [8]
> > Бред.
> Обоснуй.

"Чую, а обосновать не могу!" :)))
Микроядерная архитектура строится по принципу коммутатора процессов уровня пользователя. В микроядре выполняется минимум продолжительных процессов. В монолитном ядре для того, чтобы не преобразовывать и не передавать через сложный механизм межуровневой защиты контекст испонения одного системного процесса другому системному процессу, исполняемые программные модули компонуются вместе с ядром и их код исполняется, соответственно, на уровне ядра.

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

> Игорь Шевченко © (27.11.06 13:26) [9]
> > Монолитное ядро можно сравнить с объектом (в квази-ООП-
> программе),
> > у которого все поля и методы public, и ими пользуются
> любые
> > системные приложения, пройдя через несложный контроль
> доступа.
> >
> >
> > Микроядерную архитектуру можно сравнить с ООП-парадигмой,
>
> > в которой досконально соблюдается один основополагающий
> > принцип инкапсуляции данных, а всё взаимодействие производится
> > через защищённый интерфейс.
>
> Какое отношение твои фразы имеют к быстродействию ?

Прямое. Быстрее работать записью (record), чем с объектом через его методы доступа к полям.

Но вот по эффективности/функциональности структура данных остаётся структурой, в неё могут лазать по-разному разные процедуры. А вот объект самодостаточен и, как правило, внутренне непротиворечив из-за чёткого внешнего интерфейса и ПРОТОКОЛА доступа, определённым интерфейсом из методов.

iZEN © (27.11.06 14:05) [10]

> Прямое. Быстрее работать записью (record), чем с объектом
> через его методы доступа к полям.

Ну вот сам говоришь, что тормознее, а мне - бред. Нехорошо.

> Когда таких вызовов становится очень много, только тогда
> микроядерная архитектура сливает монолитному ядру.

Ну посчитай сам. Если процессы управления памятью, вводом-выводом, подкачкой вынесены из ядра, то, сам понимаешь, для того, чтобы им координироваться, потребуются вызовы того самого микроядра. В отличие от монолитного/гибридного ядра, где подобные вызовы сводятся к обычной инструкции call.

> А вот объект самодостаточен и, как правило, внутренне непротиворечив
> из-за чёткого внешнего интерфейса и ПРОТОКОЛА доступа, определённым
> интерфейсом из методов.

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

Сравнение ядер операционок Найти похожие ветки