Re: Колибри для встроенных систем?
Posted: Sat Apr 11, 2009 7:20 pm
Ну вот, снова захотелось жить
Спасибо
Спасибо
Official KolibriOS board
http://board.kolibrios.org/
Тестовый пример простой:Galkov wrote:А тестовый пример для проверки правильности показаний show_error_parameters при debug_exception и отсутствии самого отладчика - как-то сразу в голову и не приходит...
Code: Select all
pushf
or byte[esp+1],1 ; set TF
popf
nop ; после выполнения этой команды возникнет #DB
diamond wrote:Исправления в коде ещё не смотрел
DOSBox - это полностью программная реализация эмулятора, без поддержки со стороны системы. В линейке WinNT (до Vista и если не учитывать x86-64), кстати, есть эмуляция dos-программ через v86-режим и работает она так криво, что лучше DOSBox Как-никак программы для DOS писались из расчёта на однозадачную среду и захватывают все ресурсы, что неприемлемо для многозадачной системы.Galkov wrote:И еще, я пока вообще плохо себе представляю как работет dosbox (речь о нем ???), средства v86 вроде никуда и не экспортируется....
Сдуреть можноdiamond wrote:DOSBox - это полностью программная реализация эмулятора, без поддержки со стороны системы
Про 13-е, это я уже догадался.diamond wrote:V86 в данный момент используется только для вызова функций BIOS через int 13h (дисковая подсистема). В принципе можно ещё добавить переключение банков в VESA 1.2 через int 10h, но поскольку тестить не на чем
В принципе, мне уже понятно, как решать этот вопрос. В смысле - убрать "потенциально сколь угодно долгий срок".diamond wrote:А это уже никакие не "2.56 секунд", а потенциально сколь угодно долгий срок. Особенно если учесть, что ждать придётся вовсе не до выхода из функции, а именно пока работающая с диском прога не перестанет выдавать запросы к 70-й (58-й) функции (потому что вероятность того, что прерывание таймера, обработчик которого и занимается переключением процессов, придёт ровно в момент между вызовами функций, довольно мала. А на то, чтобы в момент освобождения мьютекса и выхода из функции вызвать планировщик немедленно, интеллектуальности у Колибри сейчас не хватает. А переделать это не так уж и тривиально).
Колибри не имеет плана развития как такового, так что можно делать всё в разумных пределах (переписывание на "что-нибудь посложнее, чем сегодняшний wait_mutex" в эти пределы входит, а переписывание ядра на Си таки нет).Galkov wrote:Если коллеги посчитают таковое движение правильным, я могу предварительно описать "схему мероприятий", и, по согласии с этой "схемой" - сделать кодинг.
а) Согласенdiamond wrote:Дисклеймер: .......
Угу, разные факторы и проявляются на разных этапах разработки. Я про то, что нет документации и потенциальный ядерщик забивает на систему, вообще не доходя до размышлений "как бы это поменять и что по этому поводу думают остальные".Galkov wrote:Но все-таки, отсутствие четкого плана, и то, чего я могу сегодня охарактеризовать как "молчаливую анархию" - это разные вещи.
Мне даже кажется, что очень разные. Возможно настолько, что серьезно влияет на "баланс притока разработчиков"
Универсальный ответ: перекладывай. Коллеги наверняка тоже думают, что оно лежит криво, но сами не исправляют по ряду возможных причин. Собственно, сейчас ситуация такая, что можно перекладывать, если для этого есть разумные обоснования и даже если коллеги против.Galkov wrote:Ну хорошо, вот вижу я лежащее бревно, и подумалось мне, что оно лежит криво..
Мысли разные бывают. Общих мыслей на форуме очень много, например, хорошо бы добавить поддержку многопроцессорности и сделать списки потоков и процессов динамическими. Но они напрямую непригодны для кодинга. А чертежи для кодинга нужно долго и упорно чертить, продумывая, какие поля должны быть в структуре потока, какие в структуре процесса, где должны быть блокировки, какие должны быть блокировки на многопроцессорных системах, как организовать файловую систему и т.д., и т.п. И всё это нетривиально. Главное в программировании - именно мысли, а не кодинг.Galkov wrote:Говорю же, например: поделитесь мыслями, а кодинг за мной.
Обычными, если не станет ждать советов по тому, что надо закодить, а будет сам думать.Galkov wrote:Ну хорошо, какими нервами должен обладать некий "новичок", чтобы выдержать аналогичную "систему советования" ???
Не страшно, что перекладывания перетряхнут систему. Проблема, что они могут не помочь.Galkov wrote:Мне совершенно понятно, что некоторые "перекладывания бревен" так встряхнут систему, что с полгода только глюки ловить будем, вспоминая автора тряски незлым тихим словом.
Пожалуйста.Galkov wrote:Ну например, можно помечтать об объединении всех данных потока в единую структуру данных (а не в три), а массив этих структур сделать динамическим.
А имена-то чем не устраивают? Вполне информативные.Galkov wrote:А то ведь достала уже эта славная троица - CURRENT_TASK, TASK_BASE, current_slot (в глаза бы посмотреть еще тому, кто такие имена-то придумал)
Потому что общую мысль высказал, а детализации, пригодной для кодинга, у меня просто нет.Galkov wrote:Вы же -- ну ничего не пояснили Ну и пытался "просчитать" чужой ход мыслей.
Тогда действуй.Galkov wrote:Пока мне кажется, что цель достойна затрат.
Не стукнет. Если укрепление подпорки не залито на svn, то можно считать, что его не существует, а если оно и существует на отдельно взятом компе, то "укрепляющий" коллега сам разберётся.Galkov wrote:Вот и вопрос: как мне узнать, что это "новое бревно" не стукнет по голове коллегу, который укрепляет другую подпорку гвоздями.
Лично для меня это не имеет особого значения (документация на все сисфункции в некоторый момент тоже была "очень большой работой", что не помешало мне ей заняться), а вот необходимость фраз "это реализовано в корне неправильно, но мы всё равно об этом расскажем" (хотя бы между строк) убивает желание на корню.Galkov wrote:Про справку: это очень большая работа...