Есть еще маленький недостаток дело в том, что виртуальная файловая система посути отсутствует и передает код напрямую файловой системе того устройства к которому идет обращение. А та в свою очередь использует прямое чтение с диска используя свои функции. Так что NFTS не знает ничего о DMA с его кэшами. Тоже самое и для сд-дисков там ISO.
Так что пост выше относиться по большей части к FAT 32 и жестким дискам.
Полное отсутствие структуры.
Это не препядствие для введение SATA, но прежде всего необхадимость ввести структуру и начать все переписывать. Так как в противном случии SATA будет рабоать местами.
PS. Возможно мои данные устарели.
ВАЖНО!!! Ядро - концепция работы
Насчёт того, что вышеприведённое относится только к жёстким дискам, а код поддержки iso на CD/DVD напрямую обращается к физическому чтению с CD/DVD (аналогичная ситуация с FAT12 на дискетах) и совершенно никак не связан с жёсткими дисками, согласен. А вот то, что код поддержки NTFS ничего не знает о DMA, неверно и никогда (если брать временные рамки существования и того, и другого) не было верно - всё-таки для жёстких дисков некоторая абстракция есть и все вызовы от кода поддержки файловых систем NTFS и FAT32 проходят через две конкретные процедуры (hd_read/hd_write), уже внутри которых осуществляется перенаправление на нужные физические процедуры (PIO/DMA/V86).
Ну а вещи насчёт SATA и vfs обсуждаются здесь: viewtopic.php?f=1&t=1101
Ну а вещи насчёт SATA и vfs обсуждаются здесь: viewtopic.php?f=1&t=1101
А как маппится самая верхняя зона физической памяти, куда BIOS обычно конфигурирует адреса MMIO-блоков PCI-устройств (видеопамяти, аудио- и сетевых буферов, SATA, USB и т.п.)?diamond wrote:...начальный кусок системных адресов [OS_BASE, OS_BASE + a), где OS_BASE = 0x80000000 (const.inc), маппится на начало физической памяти [0,a) "почти тривиально" - вычитанием OS_BASE; в этот кусок входит само ядро и все системные таблицы ...
В init.inc этого нет. Возникают 2 наивных предположения:
1) используется еще более тривиальный маппинг (phys = virt) для всего пространства выше [0,a)
или
2) ядро вообще не производит инициализации страниц для MMIO, оставляя это хлопотное дело драйверу
?
Евангелие от Иоанна: стих 1[/size]
Code: Select all
; В начале было Слово:
B32: mov ax, os_stack ; Selector for os
art_zh
Второе. Для этих целей ядро экспортирует функцию MapIoMem (это имя для драйверов, реализация в map_io_mem из core/memory.inc), которая выделяет память ядра и маппит туда указанный диапазон физической памяти с указанными флагами. Как вариант, то же самое можно сделать через AllocKernelSpace и MapPage.
Второе. Для этих целей ядро экспортирует функцию MapIoMem (это имя для драйверов, реализация в map_io_mem из core/memory.inc), которая выделяет память ядра и маппит туда указанный диапазон физической памяти с указанными флагами. Как вариант, то же самое можно сделать через AllocKernelSpace и MapPage.
Надо бы эту информацию на WIKI перенести, а то каждый раз чертыхаясь ищу эту тему, когда вновь приходящие люди начинают фундаментальные вопросы задавать. Может кто перенесет?
Замечательно. Просто иногда начинаешь рефлексивно вспоминать что и где (не так уж часто новички задают фундаментальные вопросы) и никак не можешь вспомнить. Вроде еще не старый (в ноябре 32 года будет), но забываешь напрочь - хорошо хоть что-то в виде зацепки в голове остается.
Это, кстати, проблема связности вики. По-идее не должно быть страниц без ссылок на них, и даже больше чем одна, ну и все в таком роде. Я уже часто сталкивался с подобной проблемой.
Кто-то может написать статью про механизм распределения ОЗУ между приложениями в Колибри ОС?
Монтировка решит всё
Who is online
Users browsing this forum: No registered users and 1 guest