Board.KolibriOS.org
http://board.kolibrios.org/

Новая модель ядра
http://board.kolibrios.org/viewtopic.php?f=35&t=509
Page 5 of 31

Author:  halyavin [ Wed May 24, 2006 12:26 pm ]
Post subject: 

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

Author:  andrew_programmer [ Wed May 24, 2006 12:26 pm ]
Post subject: 

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

Author:  Serge [ Wed May 24, 2006 1:03 pm ]
Post subject: 

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

Author:  andrew_programmer [ Wed May 24, 2006 1:04 pm ]
Post subject: 

P.S.

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

Author:  andrew_programmer [ Wed May 24, 2006 1:08 pm ]
Post subject: 

Опередили :)

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

Author:  diamond [ Wed May 24, 2006 4:13 pm ]
Post subject: 

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

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

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

Author:  camper [ Wed May 24, 2006 7:55 pm ]
Post subject: 

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

Author:  diamond [ Thu May 25, 2006 10:58 am ]
Post subject: 

8) :P 8)

Author:  andrew_programmer [ Sat May 27, 2006 8:24 am ]
Post subject: 

Какие драйверы требуют много памяти ?
Воот к примеру под звуковой буфер нужно не более 128 килобайт.
Драйвер файловой системы резервирует большой кэш ?
Думаю,что драйверы клавиатуры и мыши расходуют очень мало.
Под видео буфер необходимо (1280*1024*4)=5.12 мегабайт.

Почему запись в порты напрямую идет через большие буферы ?

Author:  camper [ Sat May 27, 2006 10:12 am ]
Post subject: 

блин, Андрей :) посмотри лучше сюда http://www.mosswinn.com/english/index.html
времени нет!

Author:  andrew_programmer [ Sat May 27, 2006 10:32 am ]
Post subject: 

Вот и яо том-же.
Работа-то идет,но требует постоянного сидения за компьютером.
С 7 утра за компьютером до 12 ночи.Даже на элементарные дела времени не хватает.

Author:  VaStaNi [ Thu Jun 01, 2006 1:48 pm ]
Post subject: 

diamond wrote:
Объясняю, почему я это предлагаю. Принципиальное соображение: если бутсектор загрузил ядро/ini-файл, то он знает, где именно на диске это располагается, так ведь? А если знает, то наверное, ему не сложно это запомнить и записывать потом сразу туда, не производя заново разбор структуры каталога, верно?

Знает - да! Запомнить - нет! Не запомнить, а ПЕРЕДАТЬ "свои ЗНАНИЯ"
далее НАВЕРХ надо! ;) Пусть "верх" цивилизованно и грамотно делает все необходимые дисковые и файловые операции, вот ОПТИМАЛЬНОСТЬ смысла. А передать можно минуя стек и память, через регистры. Таким образом загрузчик (любой FS) унифицированно предоставляет "интеллекту наверх", все что нужно, например:
EAX - абс. номер сектора начала оглавления каталога оси;
EBX - ...... FAT1;
ECX - ....... загруженного файла;
EDX - номер привода +порт IDE(SATA) + master/slave реальной "физики привода" с которым работал он при загрузке...
diamond wrote:
А если реализовывать сохранение на ступени 3, драйверу таки придётся снова считывать с диска некоторые данные. Конечно, диски сейчас быстрые, но решать проблемы повышениями требований к аппаратуре - это путь Microsoft, которым (я надеюсь) здесь никто следовать не хочет. Непринципиальное соображение: в текущей ситуации вынос сохранения параметров на protected-mode код зарубит на корню сохранение параметров в NTFS.

а это отпадёт само собой, т.к. не будет иметь места, смысла.

Author:  diamond [ Fri Jun 02, 2006 5:17 pm ]
Post subject: 

VaStaNi
Оглавление каталога оси? А то, что структура каталога чрезвычайно сильно отличается в разных файловых системах (FAT/NTFS/ext2fs), не в счёт? Разбирать каталог нужно именно в загрузчике, поскольку он ориентирован на конкретную файловую систему и умеет с ней работать. (По крайней мере, корневой каталог он уж точно разбирает). То же самое замечание по поводу получения следующего сектора в заданном файле.
Quote:
а это отпадёт само собой, т.к. не будет иметь места, смысла

Не понял, что именно не будет иметь смысла. Сохранение параметров?

Author:  Heavyiron [ Sat Jun 17, 2006 1:12 pm ]
Post subject: 

Serge, а когда ты выложишь для тестов то, что получилось? Ты вроде писал, что большая часть работы уже сделана

Author:  Serge [ Sun Jun 18, 2006 10:33 am ]
Post subject: 

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

Page 5 of 31 All times are UTC+03:00
Powered by phpBB® Forum Software © phpBB Limited
https://www.phpbb.com/