Kernel Architecture Перейти к странице -1-2 Следующая |
|
CodeWorld
|
Sunday 23.11.2003 10:42
|
|
|
Зарегистрирован Saturday 22.11.2003 22:58
Местоположение: Россия, Уфа
Сообщений - 38
|
такс, всё весело, хе хе, доков нет и т.д., давайте ентот топик штоль превратим в большую доку? я уверен со мной все согласны - все 32 юзакака , вместе со мной.
А вот и храткие вопросы:
Как вы юзаете GDT? вы их листаете - т.е. в линухе например 65 тысяч процессов, они прогаммно организует многозадачность, аппаратно же макс. число процессов - 8192, а у вас скоко?
А с LDT как? вообще привидите пример заполненых дескрипторных таблиц, и IDT тож...
Как с потоками? программно или отводите отдельный TSS?
и конешно интересно про менеджер памяти услышать што нить =) страницы по 4кб? как страницу для свопа ищете - LRU/FIFO? что из себя представляет пул - напишите структуру
а как с поддержкой интерфейсов? nt api/posix? и любопытно поддержка v86 будет?
Спасибо, что выделил 15 мин и ответили
|
Наверх
|
|
CodeWorld
|
Sunday 23.11.2003 15:10
|
|
|
Зарегистрирован: Saturday 22.11.2003 22:58
Местоположение: Россия, Уфа
Сообщений - 38
|
мдя
|
Наверх
|
|
CodeWorld
|
Sunday 23.11.2003 16:12
|
|
|
Зарегистрирован: Saturday 22.11.2003 22:58
Местоположение: Россия, Уфа
Сообщений - 38
|
ядерщики - девелоперы?
а меня не берут
а когда появяться? можь асю кого нить из них дашь?
|
Наверх
|
|
Freeman
|
Sunday 23.11.2003 16:27
|
|
|
Зарегистрирован: Sunday 16.11.2003 22:36
Местоположение: Зеленоград, Россия
Сообщений - 74
|
CodeWorld писал(а): ... а когда появяться? можь асю кого нить из них дашь?
Можешь себе представить, но ни у кого из наших ядерщиков постоянного доступа к Асе нет. Странное совпадние, честно говоря...
Пока ты об этом не спросил, не обращал внимания.
|
Наверх
|
|
CodeWorld
|
Monday 24.11.2003 17:58
|
|
|
Зарегистрирован: Saturday 22.11.2003 22:58
Местоположение: Россия, Уфа
Сообщений - 38
|
хе... быстрей бы новые доки
|
Наверх
|
|
Grinko
|
Wednesday 03.12.2003 00:32
|
|
|
Зарегистрирован: Sunday 30.11.2003 16:09
Местоположение: Екатеринбург
Сообщений - 13
|
Скажите, реализуема ли структура двойного ядра. Ядро реализовано по такому принципу. Есть два ядра, одно главное а второе резервное, причем во втором есть модуль который отвечает за введение резервного ядра в строй при ошибке главного. Модуль это монитор который загружает в определенные промежутки времени все содержимое главного ядра. Причем каждая новая запись стирает предыдущую. При ошибке главного ядра монитор отключает его и перебрасывает всю сохраненную информацию до возникновения ошибки в резервное при этоб сообщив об этом пользователю и перезагрузив главное ядро.
Возможно при такой архитектуре стабильность системы может резко возрасти.
|
Наверх
|
|
Roman I Khimov
|
Wednesday 03.12.2003 00:36
|
|
|
Местоположение: Россия, Санкт-Петербург
Сообщений - 178
|
Во-первых я не знаю куда такая стабильность - ядро не должно содержать ошибок, просто-напросто. На то оно и ядро.
Во-вторых на x86 по-моему это не реализуемо - ошибка в нулевом кольце, какое бы из двух ядер там ни работало - это финиш всей системы.
Греби и улыбайся!
|
Наверх
|
|
Grinko
|
Wednesday 03.12.2003 09:08
|
|
|
Зарегистрирован: Sunday 30.11.2003 16:09
Местоположение: Екатеринбург
Сообщений - 13
|
Да, плохо, что такое нельзя реализовать. Теперь я понял, что в продолжении развития двухядерной схемы не имеет смысла. Похоже что она с самого начала была нежизнеспособной, чтож, надо признавать свои ошибки и заблуждения
|
Наверх
|
|
AlexeyASugonyaev
|
Wednesday 03.12.2003 09:16
|
|
|
Зарегистрирован: Tuesday 18.11.2003 06:36
Местоположение: Челябинская обл., г.Карталы
Сообщений - 68
|
В принципе рестарт ядра возможен в случае краха #GP (или других исключений приводящих к невозможности продолжать работать в 0 кольце), но кто даст гарантию что это не сбой железа и поторный старт ядра приведет тут же к следующему исключению, и так до ... Практически нет возможности определить с вероятностью хотя бы 50% приведет ли в этом случае перезапуск ядра к дальнейшему его рестарту, т.е. пользователь должен осознать что произошло исключение не совместимое с "жизнью" ядра в данной ОС. Наша задача (3ОС) сделать систему устойчивой к "мягким" причинам (софта) приводящим к #GP с невозможностью дальнейшей работы, оставив такую возможность трапа ядра только в случае некорректной работы железа. Последнюю ситуацию так же можно разделить на группу сбойной работы железа поддающейся "купированию" и не поддающейся. Таким образом ядро должно "кувыркнуться" только в случае если без вмешательства пользователя осуществлять дальнейшую работу не имеет смысла (пациент скорее жив, чем мертв и реанимация трупа оживит пациента на доли секунды ж)). Вот такое ядро имеет 99.9% стабильности на заранее работоспособной платформе.
|
Наверх
|
|
Grinko
|
Wednesday 03.12.2003 09:57
|
|
|
Зарегистрирован: Sunday 30.11.2003 16:09
Местоположение: Екатеринбург
Сообщений - 13
|
Да похоже вы правы, и в двух ядерной системе нет смысла, она может обеспечить только то,если произойдет какая-то ошибка в одном из ядер, и все будет работать по моей идее. То произойдет такой большой цикл повторения одной и тойже ошибки, что можно сказать система зависнет и опять предется ее перезагружать холодным способом. Получилось что при такой конфигурации ядра эффективность не 100%, а приближается скорее к 0%.
Да, но идея выглядела красиво , но нежизнеспособно, да и зачем получется, если неисправно железо зря перезагружать систему, а стоит сообщить пользователю на эту неисправность, и пусть он сам решает, что дальше делать.
|
Наверх
|
|
Модераторы: Roman I Khimov. |
|
|