Board.KolibriOS.org

Serge
Хороший malloc выделяет и освобождает память довольно часто (чтобы приложение не занимало память, которая ему не нужна). Поэтому односвязных список может начать тормозить. В windows для этого используется (не много сбалансированное) дерево.

Тоесть при инициализации выделяется блок памяти фиксированного размера,а потом от этого блока по необходимости malloc отсчипывает память ?

Хороший malloc выделяет и освобождает память довольно часто (чтобы приложение не занимало память, которая ему не нужна). Поэтому односвязных список может начать тормозить. В windows для этого используется (не много сбалансированное) дерево.

Тоесть при инициализации выделяется блок памяти фиксированного размера,а потом от этого блока по необходимости malloc отсчипывает память ?

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

P.S.

Вопрос был задан Serge-у.

Опередили

Пока ООП языков нет,но появяться(если в Колибри будет портирован компилятор C,то потом и C++ появиться).

VaStaNi

Я не пойму что то "великий смысл" работы с файлом(и) сразу из бут сектора??? В чем кроется столь высокая стратегия и приоритетность этого? Почему ЭТО нельзя отложить "на потом", скажем на этап полноценного ДРАЙВЕРНОГО взаимодействия системы ну типа расклада как в СТУПЕНИ 3!?

Объясняю, почему я это предлагаю. Принципиальное соображение: если бутсектор загрузил ядро/ini-файл, то он знает, где именно на диске это располагается, так ведь? А если знает, то наверное, ему не сложно это запомнить и записывать потом сразу туда, не производя заново разбор структуры каталога, верно? А если реализовывать сохранение на ступени 3, драйверу таки придётся снова считывать с диска некоторые данные. Конечно, диски сейчас быстрые, но решать проблемы повышениями требований к аппаратуре - это путь Microsoft, которым (я надеюсь) здесь никто следовать не хочет. Непринципиальное соображение: в текущей ситуации вынос сохранения параметров на protected-mode код зарубит на корню сохранение параметров в NTFS.

Ведь надо делать(мое убеждение), как проще и оптимальнее рашается задача проектирования и работы(функционирование) самого детища, а НЕ так, как хочется проектанту, оператору, юзеру, приложению, потому, что с каждой колокольни найдутся свои доводы и аргументы, что проще, да приятнее, да удобнее... Плюс нужно не забывать про глобальное видение перспектив выбранной стратегии вцелом, гибкость и пр.

Что важнее: идеологически прекрасно выдержанный, но тормозящий (если вообще работающий) код или идеологически ужасный, но при этом прекрасно работающий код?

важнее идеологически прекрасно выдержанный, но при этом прекрасно работающий код

Какие драйверы требуют много памяти ?
Воот к примеру под звуковой буфер нужно не более 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, а когда ты выложишь для тестов то, что получилось? Ты вроде писал, что большая часть работы уже сделана

Надеюсь выложить к концу июня, когда будет готов аудио драйвер. Футбол мешает