Новая модель ядра

Kernel architecture questions
  • При этом никто не мешает другим осестроителям ещё и использовать наши бутсекторы для разных ФС (и mtldr с acroboot)...
  • При этом никто не мешает другим осестроителям ещё и использовать наши бутсекторы для разных ФС (и mtldr с acroboot)...
    Вот и я о том же. Пусть код будет максимально гибким и полезным не только для нас.
  • Serge wrote:А удастся запихнуть write_file в бутсектор? Конечно так можно сделать, но такое компромисное решение только маскирует проблему. И как быть если хочется держать систему не на С:\ а где нибудь на E:\OS\KOLIBLI\MAIN\053 ?
    Я не пойму что то "великий смысл" работы с файлом(и) сразу из бут сектора??? В чем кроется столь высокая стратегия и приоритетность этого? Почему ЭТО нельзя отложить "на потом", скажем на этап полноценного ДРАЙВЕРНОГО взаимодействия системы ну типа расклада как в СТУПЕНИ 3!? Ведь надо делать(мое убеждение), как проще и оптимальнее рашается задача проектирования и работы(функционирование) самого детища, а НЕ так, как хочется проектанту, оператору, юзеру, приложению:), потому, что с каждой колокольни найдутся свои доводы и аргументы, что проще, да приятнее, да удобнее... Плюс нужно не забывать про глобальное видение перспектив выбранной стратегии вцелом, гибкость и пр.
    Если хочется E:\OS\KOLIBLI\MAIN\053 то это решаемо именно в бутсекторе. Этому аргумент один, аналогия, как в математике - приведение к ОБЩЕМУ ЗНАМЕНАТЕЛЮ принципов загрузки с различных носителей, FS. Тем самым спрямляется все в одну линию т.к. бутсектор, каков бы он ни был по конструкции, алгоритму, типу FS, ВСЕГДА в конечном итоге загружает один и тот же файл, одно и то же имя файла! Никакой записи! Только ЗАГРУЗКА, точная и прицельная, из каталога ли или нет с одним вложением папок или более, но КОНЕЦ этого этапа= НАЧАЛУ т.к. файл ДОЛЖЕН БЫТЬ найден и успешно загружен в нужную, ФИКСИРОВАННУЮ точку в памяти первых 640кБ! А вот что будет дальше - это следующий шаг, ЭТАП(тут надо не забывать про передачу параметров от бутсектора, хотя бы в регистрах, коих масса и они НАПРАСТНО НИЧЕГО НЕ НЕСУТ ИНФОРМАЦИОННО в этот следующий этап.). Практически и алгоритмически опробовал тучу вариантов подобных решений и путей загрузки, скажу, что путь для ОС более чем x:\xxxxx\<имя файла> - неоправдан ввиду массы причин, поверьте на слово. Посему я "играюсь" с унифицированнным целевым именем ОСи=каталога, а версия, релиз, редакция, модификация предполагает изменение ЕГО расширения (сугубо 8+3) т.е. например:
    С:\ATOMOS.000, С:\ATOMOS.001,С:\ATOMOS.023..... Алгоритм решения задачи (код бутсектора) максимально прост и лаконичен, а вот эффект максимален + наглядность(при сортировках) и простота выбора в корне диска, навигация. Это также хорошо и просто даже для правки РУЧКАМИ кода бута в HIEW, например! Это еще один "убитый заяц одним выстрелом". Поправить в HEX-редакторе последние символы - вот тебе новая загрузка, навый путь, навая отладочная редакция! Клонирование таких загрузок -пара пустяков в пределах одного диска даже ДЛЯ МУЛЬТИЗАГРУЗЧИКОВ ОСей, т.к. в их SAVEфайлах все аналогично! И в случае краха или непредвиденных обстоятельств, такой метод успешно работает и позволяет восстановить, вернуться, изменить... На мой комплексный взгляд - одни зайцы! ;D т.е. достоинства.
    Если я изъяснился мутно и непонятно где то - не молчите. Всегда готов разжевать и донести суть. Хотелось бы понять и Ваши АРГУМЕНТЫ в этом деле.
  • Если хочется E:\OS\KOLIBLI\MAIN\053 то это решаемо именно в бутсекторе. Этому аргумент один,
    Будет сложно грузить E:\OS\KOLIBLI\MAIN\053\kernel.mnt именно бусектором. Бутсектор не знает заранее путь. Значит этот путь должен быть или жестко зашит в код бутсектора или записан в ini файле в корневом каталоге загрузочного диска и бутсектор должен сначала считать этот ini файл. Сомневаюсь, влезет ли весь необходимый для этого код вместе с разбором пути и чтением папок в маленький бутсектор.
    Потому и предлагаю свалить всю эту работу на загрузчик.

    Всем
    Нужно ли ограничивать размер кучи ядра? Например если в системе 64Мб то после загрузки ядра свободно будет 52Мб. Можно делить эту память между ядром и программами как 2/5 (близко к золотому сечению) то есть максимальный размер кучи ядра будет 20 Мб. Для 256 Мб соответственно 96 Мб. Это значение можно переопределять в ini файле например KERNEL HEAP 48 если нужно изменить соотношение.
  • Думаю куча ядра и приложений должна быть общая. Разве что для ядра нужно оставлять 2-3% свободной памяти в качестве резерва.
  • Резерв оставлять нужно, но речь идет о куче в адресном пространстве ядра, то есть общей памяти. Сюда будут загружаться драйверы ядра, отображаться ввод/вывод и т.д. В общем это память которая будет использоваться только ядром. Это не рельная физическая память, а только диапазон адресов. А у каждой программы будет своя куча в адресном пр-ве приложения.
  • ВсемНужно ли вводить приоритеты для процессов. Если да, то сколько уровней делать и какой алгоритм планирования использовать?
  • Приоритеты полюбому нужны
    Я тут думал о возможности создания многопотоного сервера и пришёл к такому выводу

    Надо как минимум 3(idle-time,real-time,normal)
    Для долгих но не критичных можно по времени задач можно добавить belowe normal
    Ну и можно above normal (для симметрии :) )
    Куда ещё прикручивать не знаю

    В алгоритмах планирования я не силён :)
  • По загрузке: возлагать на бутсектор функции загрузки файлов - это ещё нормально, но вот чтобы писать в произвольные файлы... А что, если загрузка идёт с CD, к примеру?

    Получается такая схема загрузки:
    1. Бутсектор грузит
    а) драйвер ФС реального режима (если он не влезает в бутсектор)
    б) начальный загрузчик ядра и передаёт ему управление
    2. В реальном режиме определяется оборудование, загружаются драйверы дисков и ФС защищенного режима. Загружается ядро, система переводится в защищенный режим и управление переходит на следующую ступень.
    3. Загрузчик защищенного режима переходит к страничной адресации, инициализирует драйверы дисков и ФС, после этого загружает остальные драйверы и вперёд в многозадачность! :-)
    Загрузчики могут находится как в одном файле с ядром, так и в отдельных.

    По поводу кучи ядра: я не понимаю, в чём проблема. Предлагается делить физическую память или виртуальную???
    Смысла в первом я не вижу. Во втором тоже :) - память уже разделена. 2 Гб процессу и 2 Гб ядру (или как-нибудь по-другому - не важно).

    Я уже создавал тему про Scheduler, но конкретных предложений по алгоритму высказано не было. Реализовать очереди с приоритетами легко, а вот как эти приоритеты назначать... Сам я в этом так и не разобрался.

    Да, кстати, лучше не сваливать всё в одну тему, а то бардак получается!
  • По поводу кучи ядра: я не понимаю, в чём проблема. Предлагается делить физическую память или виртуальную???
    Смысла в первом я не вижу. Во втором тоже Smile - память уже разделена. 2 Гб процессу и 2 Гб ядру (или как-нибудь по-другому - не важно).
    Память ядра общая для всех процессов. Проще создать таблицы страниц для этой памяти сразу, тогда при выделении памяти в ядре нет необходимости проходить по каталогам таблиц всех процессов и модифицировать их. Если в компьютере установлено 64Мб памяти то максимум требуется 16 таблиц страниц (одна таблица на 4Мб ОЗУ). Реально ядро никогда не сможет использовать все 64Мб (часть памяти займут приложения) значит одна или несколько таблиц страниц ядра не будут использоваться. Установив размер кучи ядра можно уменьшить количество таблиц страниц, создаваемых при инициализации системы и сэкономить физическую память.
  • Таблицы страниц составляют лишь 0.1%-1% памяти, никто их не заметит.
  • Serge,если под ядро отводить (2/5) от общей памяти,то при большом объёме оперативки(512 например) ядру отводиться >200
    .А зачем ядру так много? Мы же динамические библиотеки будем грузить в адресное пространство приложений,а не ядра(ато повесим систему к чёрту).Да и драйверы будут не в ядре,а ввиде динамических библиотек.
    Это при малом объёме памяти(<256) такой подход правилен.Я думаю,что,если оперативки >256,то нужно под ядро отводить 1/5 часть от общей памяти.
  • erge,если под ядро отводить (2/5) от общей памяти,то при большом объёме оперативки(512 например) ядру отводиться >200
    .А зачем ядру так много?
    Пока незачем, но если там размещать звуковые буферы, кэш файловой системы, те буферы которые пока размещаются статически то может понадобиться несколько десятков мегабайт. Я сделал в ini параметр Kernel heap. Им можно жёстко задавать размер кучи, а 2/5 или 1/5 использовать только по умолчанию. В любом случае какое-то регулирование размера кучи необходимо.
  • Есть два варианта выделения памяти для программ. Первый использует простой односвязный список и хранит все данные в таблицах страниц. Второй сложнее но ему нужна дополнительная память для хранения информации о выделенных блоках памяти. Надо ли использовать более сложный вариант я не знаю. Скорее всего память будет выделятся только один раз при инициализации malloc и дальше все динамическое выделение памяти будет идти через malloc.
  • Who is online

    Users browsing this forum: No registered users and 5 guests