>>>>> DRVTiny <<<<<
Пока я тут, понимаешь в разных форумах , да ещё в институте время убиваю , совсем мало остаётся на "общее интеллектуальное развитие" Вообще, если честно, я как-то всё больше по части реализации различных интерфейсных стандартов взаимодействия с аппаратурой специалист. Системное программирование меня интересует только с этой точки зрения. Поэтому моя ОСь- не более, чем эксперимент, целью которого является - изучение возможностей ProtectedMode и встроенной поддержки многозадачности современных микропроцессоров Intel . У меня, кстати, как раз с аппаратной поддержкой TaskSwitch'ей какие-то непреодолимые трудности возникли. Я сварганил простенький монитор процессов специально для переключения через IRQ0, а он упорно не желает работать через дескриптор шлюза задачи в IDT - CPU в прединфарктное состояние RESET'а вводит. При чём, что интересно, на ту же задачу можно без проблем переключаться при запрещённых прерываниях прямым Call на её TSS.
еще раз... а про калл на тсс непонил? ты тсс в IDT затолкал штоль? тобишь шедулер как отдельная задача у тя?
еще раз... а про калл на тсс непонил? ты тсс в IDT затолкал штоль? тобишь шедулер как отдельная задача у тя?
Извиняюсь за вынужденное долговременное отсутствие.
Sheduller у меня и впрямь - автономное образование со своим сегментом состояния, в котором ещё и проинициализирован регистр LDT впридачу. Вообще перебирайтесь все на ветку "Нуль-Ядерная ОС ROSA YOUR Solutions"
Извиняюсь за вынужденное долговременное отсутствие.
Sheduller у меня и впрямь - автономное образование со своим сегментом состояния, в котором ещё и проинициализирован регистр LDT впридачу. Вообще перебирайтесь все на ветку "Нуль-Ядерная ОС ROSA YOUR Solutions"
а теперь я скажу почему так делать нестоит! ты понимаешь что на каждое переключение задач одна из задач являеется шедулер... тобишь 50% потери...
а теперь я скажу почему так делать нестоит! ты понимаешь что на каждое переключение задач одна из задач являеется шедулер... тобишь 50% потери...
При переключении задач - да, но сами задачи в активной фазе своего выполнения наверное тоже чего-то полезное делают. И уж квант времени, выделяемый каждой задаче sheduller'ом несоизмерим с накладными расходами switch'ей между задачами. А что ты предлагаешь - изобрертать велосипед типа монитора процессов в Linux? Так там дело не в скорости переключения (выигрыша в этом плане за счёт использования чисто программного механизма не достигается никакого. Убытки никто не считал), а в обеспечении надёжности системы, устойчивости её к фатальным аппаратным сбоям, могущим возникнуть при переключении на некорректный контекст TSS. Может когда-нибудь и придётся отказаться от аппратной поддержки MT
Intell'овскими процессорами - не знаю. Сейчас заморачиваться с этим нет ни малейшего желания - для меня существенно более принципиальна логика работы системы, а не конкретные асспекты её технической реализации (хотя и с этим бывают проблемы, разумеется).
я неотрицаю..
> с накладными расходами switch'ей между задачами.
зря ты так... ИМЕННО TSSишный свитч достаточно тактов жрёт.. но я как понял ты пишешь ось в целях понятия самой организации взаимодествия интерфейсов ос, так что.. да тут для тебя не очень важный момент..
>А что ты предлагаешь
про линух ни че не знать.. просто можно в первой области памяти сделать глобальный кусок для всех карт памяти и оставить адрес на него по случаю прерывания от таймера, а в ентом куске как раз и будет шедулер, и лишних TSSишных свитчей не будет...
>её к фатальным аппаратным сбоям, могущим возникнуть при переключении на некорректный контекст TSS.
непонял.. а как ты избежишь некоректного TSS?
>Может когда-нибудь и придётся отказаться от аппратной поддержки
ты мне не поверишь.. я всегда кричал - аппаратная перекючение самоё надежное! стабильное! легкое по организации! но вот как кстати, вчера подсчитал скоко мне прдется памяти под систему отвести... TSS полноценый 64k при 512 процессах тебе понадобится 32 метра (!!!) - и это без потоков!, ты канешно скажешь что все енто стоит динамически делать - но так как я пишу RTOS то придётся отказаться от вещей которые тормозят проц... да я согласился - я потрачу 32 метра, а потоки органищую как таблицу из 8 байтовых полей со смещением на тек. поток - как вишь я уже сам делаю гибрпид програмнной многозадачности... такая структура при 1024 потоках на каждый процесс займёт 4 метра.. и всего моей оси тока для запуска потреб 50 метров!
>но сами задачи в активной фазе своего выполнения наверное тоже чего-то полезное делают.
я неотрицаю..
> с накладными расходами switch'ей между задачами.
зря ты так... ИМЕННО TSSишный свитч достаточно тактов жрёт.. но я как понял ты пишешь ось в целях понятия самой организации взаимодествия интерфейсов ос, так что.. да тут для тебя не очень важный момент..
>А что ты предлагаешь
про линух ни че не знать.. просто можно в первой области памяти сделать глобальный кусок для всех карт памяти и оставить адрес на него по случаю прерывания от таймера, а в ентом куске как раз и будет шедулер, и лишних TSSишных свитчей не будет...
>её к фатальным аппаратным сбоям, могущим возникнуть при переключении на некорректный контекст TSS.
непонял.. а как ты избежишь некоректного TSS?
>Может когда-нибудь и придётся отказаться от аппратной поддержки
ты мне не поверишь.. я всегда кричал - аппаратная перекючение самоё надежное! стабильное! легкое по организации! но вот как кстати, вчера подсчитал скоко мне прдется памяти под систему отвести... TSS полноценый 64k при 512 процессах тебе понадобится 32 метра (!!!) - и это без потоков!, ты канешно скажешь что все енто стоит динамически делать - но так как я пишу RTOS то придётся отказаться от вещей которые тормозят проц... да я согласился - я потрачу 32 метра, а потоки органищую как таблицу из 8 байтовых полей со смещением на тек. поток - как вишь я уже сам делаю гибрпид програмнной многозадачности... такая структура при 1024 потоках на каждый процесс займёт 4 метра.. и всего моей оси тока для запуска потреб 50 метров!
Не понял, а зачем каждому TSS нужны таблицы доступных портов вводы-вывода, да ещё и карта прерываний. У тебя что каждая задача - эмулятор DOS, работающий в V86?
у мя микроядро... и некотрым задчам понадобится обращение к портам с 3 кольца...
> да ещё и карта прерываний...
есть прерывания гле висят дрова хара и эмуляция запроса харда посредством int крайне не желательна
>Не понял, а зачем каждому TSS нужны таблицы доступных портов вводы-вывода
у мя микроядро... и некотрым задчам понадобится обращение к портам с 3 кольца...
> да ещё и карта прерываний...
есть прерывания гле висят дрова хара и эмуляция запроса харда посредством int крайне не желательна
Последнее я вообще не просёк.
По определению даже в ОС РВ все задачи, общающиеся на прямую с обрудованием, обязаны находиться в 0-ом кольце. Иначе весь смысл разделения на кольца пропадает и система оказывается подвержена аппаратным сбоям, которые пострашнее программных (вызывающих исключения процессора) будут. К тому же обработчики прерываний у тебя тоже задачи 3 кольца могут устанавливать? Так то, извините меня, странность какая-то...
да.. но по определению микроядро все сказанному протеворесит
>Иначе весь смысл разделения на кольца пропадает и система оказывается подвержена аппаратным сбоям, которые пострашнее программных (вызывающих исключения процессора) будут. К тому же обработчики прерываний у тебя тоже задачи 3 кольца могут устанавливать? Так то, извините меня, странность какая-то...
все ок.. если ненравиться то побрбней
>По определению даже в ОС РВ все задачи, общающиеся на прямую с обрудованием, обязаны находиться в 0-ом кольце.
да.. но по определению микроядро все сказанному протеворесит
>Иначе весь смысл разделения на кольца пропадает и система оказывается подвержена аппаратным сбоям, которые пострашнее программных (вызывающих исключения процессора) будут. К тому же обработчики прерываний у тебя тоже задачи 3 кольца могут устанавливать? Так то, извините меня, странность какая-то...
все ок.. если ненравиться то побрбней
Тааак! Разберёмся с терминологией. Микроядро-это всего лишь ядро, использующее только АСИНХРОННЫЕ вызовы (в том числе и для "внтуриядерных" процессов) - и этим отличается от всех остальных ядер, которые как минимум для потоков ядра предоставляют синхронную модель обмена. А ты, по видимому, что-то другое имеешь в виду. Так вот, то чего ты имеешь, не соответствует смыслу конкретного термина "микроядро".
о боже какой ужас.. тыж где таких определний набрался? )) микроядро - это один из спобов представления ядер, котрое представялет собой минимальный код выполняющийся в 0 кольце во избежание ошибок, управляющие компоненты в 3 кольце.. http://board.sysbin.com/viewtopic.php?t=71
И любая мало-мальски хитрая прикладная программа разносит твоё ядро к ЧМ. А вообще-то данное тобой определение - (с каким-то извращённым смыслом, правда) для ядер (любых), реализующих межзадачное вз.-действие по принципу ВЗАИМНО НЕДОВЕРЯЮЩИХ ПОДСИСТЕМ.
И любая мало-мальски хитрая прикладная программа разносит твоё ядро к ЧМ. А вообще-то данное тобой определение - (с каким-то извращённым смыслом, правда) для ядер (любых), реализующих межзадачное вз.-действие по принципу ВЗАИМНО НЕДОВЕРЯЮЩИХ ПОДСИСТЕМ.
Смотрел я твою ссылку. Бред полный (см. Дмитрий Иртегов "Введение в Операционные системы" или ЧТО УГОДНО ещё). Скажу только, что ВСЕ ОС РВ построены на основе микроядер именно потому, что там латентность ответа на запросы и реакции на внешние события минимальна (что свойственно асинхронной модели межпоточного взаимодействия).
И любая мало-мальски хитрая прикладная программа разносит твоё ядро к ЧМ. А вообще-то данное тобой определение - (с каким-то извращённым смыслом, правда) для ядер (любых), реализующих межзадачное вз.-действие по принципу ВЗАИМНО НЕДОВЕРЯЮЩИХ ПОДСИСТЕМ.
да.. так и есть.. но все надежно, и гиюк.. прога не разнесет ядро если этого не одоюрит пользователь..