Tanenbaum-Torvalds Debate: Part II
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.05.06 07:34
Оценка: 72 (9)
Tanenbaum-Torvalds Debate: Part II

Небольшая статья Эндрю Таненбаума по поводу возобновления его споров с Линусом Торвальдсом о микроядерных ОС.
Ссылка была найдена на linux.org.ru

What Am I Trying to Prove?

Actually, MINIX 3 and my research generally is **NOT** about microkernels. It is about building highly reliable, self-healing, operating systems. I will consider the job finished when no manufacturer anywhere makes a PC with a reset button. TVs don't have reset buttons. Stereos don't have reset buttons. Cars don't have reset buttons. They are full of software but don't need them. Computers need reset buttons because their software crashes a lot. I know that computer software is different from car software, but users just want them both to work and don't want lectures why they should expect cars to work and computers not to work. I want to build an operating system whose mean time to failure is much longer than the lifetime of the computer so the average user never experiences a crash...

So what do microkernels have to do with this goal? They make it possible to build self-healing systems. That is what I care about and my research is about...
...In our design, when most drivers fail, the reincarnation server can restart a fresh copy, and optionally save the core image of the dead driver for debugging, log the event, send email to an administrator or developer, etc. The system continues to run, and at the very least can be shut down gracefully without loss of work or data. Some components, such as the reincarnation server itself, the file server, and the process server are critical, and losing them crashes the system, but there is absolutely no reason to allow a faulty audio, printer, or scanner driver to wipe out the system. They should just be restarted and work should continue. This is our goal: systems that can detect and repair their own faults. You can do this easily in a microkernel system...


Специально для местных любителей .NET и Singularity Она там так же упоминается:

Microsoft also has interest in microkernels. It understands the maintenance headache of monolithic kernels like no one else. Windows NT 3.1 was a half-hearted attempt at a microkernel system, but it wasn't done right and the performance wasn't good enough on the hardware of the early 1990s, so it gave up on the idea for a while. But recently, it tried again on modern hardware, resulting in Singularity. Now I know that a lot of people assume that if Microsoft did it, it must be stupid, but the people who drove the Singularity project, Galen Hunt and Jim Larus, are very smart cookies, and they well understand that Windows is a mess and a new approach is needed.



SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re: Tanenbaum-Torvalds Debate: Part II
От: iZEN СССР  
Дата: 16.05.06 08:02
Оценка:
Здравствуйте, eao197, Вы писали:

E>Tanenbaum-Torvalds Debate: Part II


E>Небольшая статья Эндрю Таненбаума по поводу возобновления его споров с Линусом Торвальдсом о микроядерных ОС.

E>Ссылка была найдена на linux.org.ru

Основным аргументом Линуса против Таненбаума, как известно, было высказвание об усложнении связей между микроядром и подсистемами/драйверами, из-за чего страдала производительность. Так что на тот момент (1991-92гг.) было лучше делать системы моноядерными в пользу практичности, простоты и быстродействия. Ведь в те времена преобладали в основном машины с процессорами i386 и i486 и объёмом памяти не больше 4МБ.
Re[2]: Tanenbaum-Torvalds Debate: Part II
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.05.06 15:26
Оценка: +1
Здравствуйте, iZEN, Вы писали:

ZEN>Основным аргументом Линуса против Таненбаума, как известно, было высказвание об усложнении связей между микроядром и подсистемами/драйверами, из-за чего страдала производительность. Так что на тот момент (1991-92гг.) было лучше делать системы моноядерными в пользу практичности, простоты и быстродействия. Ведь в те времена преобладали в основном машины с процессорами i386 и i486 и объёмом памяти не больше 4МБ.


Имхо, по поводу практичности и быстродействия довольно спорное утверждение, т.к. в тогда уже существовала микро-ядерная ОС QNX. И производительность у нее была вполне достаточной, тем более, что это Real-Time OS.

Насколько я помню, как раз в Real-Time OS микроядро и старались применять, т.к. только этот подход давал возможности для обеспечения надежности и предсказуемости. В частности, вынесение драйверов из ядра позволяло прерывать работу драйвера при более приоритетным прерывания, которое адресовалось real-time процессу. Еще одним фактором в пользу микроядерности в Real-Time OS было то, что OS сама по себе состояла только из минимального набора модулей (главным из которых был диспетчер). А остальные части (такие как GUI, shell-ы, файловая система) были опциональными и могли приобретаться только в случае их необходимости (для многих встраиваемых приложений они были вообще не нужны).

Так что уже в то время были реальные доказательства возможности построения работоспособных систем на базе микроядра. Другое дело, что подобное занятие было более трудоемким. Будучи прагматиком Линус выбрал более простой путь.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[3]: Tanenbaum-Torvalds Debate: Part II
От: Quintanar Россия  
Дата: 17.05.06 18:04
Оценка: 4 (2) +3
Здравствуйте, eao197, Вы писали:

E>Имхо, по поводу практичности и быстродействия довольно спорное утверждение, т.к. в тогда уже существовала микро-ядерная ОС QNX. И производительность у нее была вполне достаточной, тем более, что это Real-Time OS.


Real time не значит быстрая. Рискну даже предположить, что это значит довольно медленная.

E>Насколько я помню, как раз в Real-Time OS микроядро и старались применять, т.к. только этот подход давал возможности для обеспечения надежности и предсказуемости. В частности, вынесение драйверов из ядра позволяло прерывать работу драйвера при более приоритетным прерывания, которое адресовалось real-time процессу. Еще одним фактором в пользу микроядерности в Real-Time OS было то, что OS сама по себе состояла только из минимального набора модулей (главным из которых был диспетчер). А остальные части (такие как GUI, shell-ы, файловая система) были опциональными и могли приобретаться только в случае их необходимости (для многих встраиваемых приложений они были вообще не нужны).


Так и в Линукс также. Само ядро состоит только из менеджера памяти, переключателя задач и т.п. по мелочи, все остальное опционально. Конечно не так как в системе с микроядром, но все таки. Достигнут баланс.
Re[4]: Tanenbaum-Torvalds Debate: Part II
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 18.05.06 04:30
Оценка:
Здравствуйте, Quintanar, Вы писали:

Q>Real time не значит быстрая. Рискну даже предположить, что это значит довольно медленная.


Не значит. Но некоторые операции должны быть гарантированно быстрыми. Например, переключение контекстов и реакция на возникновение высокоприоритетного исключения/сообщения/события.

Q>Так и в Линукс также. Само ядро состоит только из менеджера памяти, переключателя задач и т.п. по мелочи, все остальное опционально. Конечно не так как в системе с микроядром, но все таки. Достигнут баланс.


Но ведь драйвера работают совместно с ядром, как я понимаю? Имхо, именно это Таненбауму и не нравится.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.