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

Kernel architecture questions
  • Тоесть при инициализации выделяется блок памяти фиксированного размера,а потом от этого блока по необходимости malloc отсчипывает память ?
  • Хороший malloc выделяет и освобождает память довольно часто (чтобы приложение не занимало память, которая ему не нужна). Поэтому односвязных список может начать тормозить. В windows для этого используется (не много сбалансированное) дерево.
    Тоесть при инициализации выделяется блок памяти фиксированного размера,а потом от этого блока по необходимости malloc отсчипывает память ?
    Примерно так. malloc запрашивает у системы блок памяти и потом сама им управляет. В "продвинутом" варианте маленькие блоки памяти ( 1-63 параграфов ) хранятся в массиве списков и отсортированиы по размеру. Блоки длиной более 63 параграфов ханятся в упорядоченном дереве. При необходимости malloc будет запрашивать у системы дополнительные блоки памяти а освободившиеся возвращать (256 Кб при выделении нового блока и 1024 Кб при освобождении). Насколько часто часто это будет происходить пока не ясно. Активней всего выделение памяти используют программы на ООП-языках, а их пока нет.
  • P.S.

    Вопрос был задан Serge-у.
  • Опередили :)

    Пока ООП языков нет,но появяться(если в Колибри будет портирован компилятор C,то потом и C++ появиться).
  • VaStaNi
    Я не пойму что то "великий смысл" работы с файлом(и) сразу из бут сектора??? В чем кроется столь высокая стратегия и приоритетность этого? Почему ЭТО нельзя отложить "на потом", скажем на этап полноценного ДРАЙВЕРНОГО взаимодействия системы ну типа расклада как в СТУПЕНИ 3!?
    Объясняю, почему я это предлагаю. Принципиальное соображение: если бутсектор загрузил ядро/ini-файл, то он знает, где именно на диске это располагается, так ведь? А если знает, то наверное, ему не сложно это запомнить и записывать потом сразу туда, не производя заново разбор структуры каталога, верно? А если реализовывать сохранение на ступени 3, драйверу таки придётся снова считывать с диска некоторые данные. Конечно, диски сейчас быстрые, но решать проблемы повышениями требований к аппаратуре - это путь Microsoft, которым (я надеюсь) здесь никто следовать не хочет. Непринципиальное соображение: в текущей ситуации вынос сохранения параметров на protected-mode код зарубит на корню сохранение параметров в NTFS.
    Ведь надо делать(мое убеждение), как проще и оптимальнее рашается задача проектирования и работы(функционирование) самого детища, а НЕ так, как хочется проектанту, оператору, юзеру, приложению, потому, что с каждой колокольни найдутся свои доводы и аргументы, что проще, да приятнее, да удобнее... Плюс нужно не забывать про глобальное видение перспектив выбранной стратегии вцелом, гибкость и пр.
    Что важнее: идеологически прекрасно выдержанный, но тормозящий (если вообще работающий) код или идеологически ужасный, но при этом прекрасно работающий код?
    Ушёл к умным, знающим и культурным людям.
  • важнее идеологически прекрасно выдержанный, но при этом прекрасно работающий код
  • 8) :P 8)
  • Какие драйверы требуют много памяти ?
    Воот к примеру под звуковой буфер нужно не более 128 килобайт.
    Драйвер файловой системы резервирует большой кэш ?
    Думаю,что драйверы клавиатуры и мыши расходуют очень мало.
    Под видео буфер необходимо (1280*1024*4)=5.12 мегабайт.

    Почему запись в порты напрямую идет через большие буферы ?
  • блин, Андрей :) посмотри лучше сюда http://www.mosswinn.com/english/index.html
    времени нет!
  • Вот и яо том-же.
    Работа-то идет,но требует постоянного сидения за компьютером.
    С 7 утра за компьютером до 12 ночи.Даже на элементарные дела времени не хватает.
  • diamond wrote: Объясняю, почему я это предлагаю. Принципиальное соображение: если бутсектор загрузил ядро/ini-файл, то он знает, где именно на диске это располагается, так ведь? А если знает, то наверное, ему не сложно это запомнить и записывать потом сразу туда, не производя заново разбор структуры каталога, верно?
    Знает - да! Запомнить - нет! Не запомнить, а ПЕРЕДАТЬ "свои ЗНАНИЯ"
    далее НАВЕРХ надо! ;) Пусть "верх" цивилизованно и грамотно делает все необходимые дисковые и файловые операции, вот ОПТИМАЛЬНОСТЬ смысла. А передать можно минуя стек и память, через регистры. Таким образом загрузчик (любой FS) унифицированно предоставляет "интеллекту наверх", все что нужно, например:
    EAX - абс. номер сектора начала оглавления каталога оси;
    EBX - ...... FAT1;
    ECX - ....... загруженного файла;
    EDX - номер привода +порт IDE(SATA) + master/slave реальной "физики привода" с которым работал он при загрузке...
    diamond wrote: А если реализовывать сохранение на ступени 3, драйверу таки придётся снова считывать с диска некоторые данные. Конечно, диски сейчас быстрые, но решать проблемы повышениями требований к аппаратуре - это путь Microsoft, которым (я надеюсь) здесь никто следовать не хочет. Непринципиальное соображение: в текущей ситуации вынос сохранения параметров на protected-mode код зарубит на корню сохранение параметров в NTFS.
    а это отпадёт само собой, т.к. не будет иметь места, смысла.
  • VaStaNi
    Оглавление каталога оси? А то, что структура каталога чрезвычайно сильно отличается в разных файловых системах (FAT/NTFS/ext2fs), не в счёт? Разбирать каталог нужно именно в загрузчике, поскольку он ориентирован на конкретную файловую систему и умеет с ней работать. (По крайней мере, корневой каталог он уж точно разбирает). То же самое замечание по поводу получения следующего сектора в заданном файле.
    а это отпадёт само собой, т.к. не будет иметь места, смысла
    Не понял, что именно не будет иметь смысла. Сохранение параметров?
    Ушёл к умным, знающим и культурным людям.
  • Serge, а когда ты выложишь для тестов то, что получилось? Ты вроде писал, что большая часть работы уже сделана
  • Надеюсь выложить к концу июня, когда будет готов аудио драйвер. Футбол мешает :)
  • Who is online

    Users browsing this forum: No registered users and 5 guests