OSDev

Рассуждения в принципе правильные. Но во-первых обычно и при загрузке системы, и после ее загрузки работает один и тот же код (у меня, например, так), поэтому вариант с DMA опять предпочтительнее, чтобы не использовать дополнительный код. А во-вторых редко в какой системе обмен данными с дисками происходит вообще без буферизации. Даже если взять работу с дисками напрямую, минуя файловую систему, драйверы обычно работают с устройствами, используя свои внутренние буферы, а обмен данными между инициаторами запросов и драйверами выполняется уже отдельно. У меня, например, вся базовая память кроме первых 8 Кб отдана именно под использование в качестве аппаратных буферов. Драйверы просто отображают необходимый им участок в свое адресное пространство, используя специализированные системные функции. А потом идет обмен либо между буферами инициатора и драйвера, либо между буферами драйвера и устройством.

Позвольте не согласиться :)

Во-первых, инициализация ОС и её нормальная работа -- совсем разные вещи, и код для них вполне может быть различным (хотя частично может и совпадать). В частности, в процессе работы ОС должна сама управлять всеми поддерживаемыми устройствами, но в процессе инициализации и загрузки может пользоваться услугами BIOS, переключаясь постоянно из реального режима в защищённый и обратно (здесь можно вспомнить, например, установщик Windows: сначала он работает через BIOS, почему может обращаться к SCSI/SATA дискам, однако, если на этом этапе не установить с помощью дискеты специальный драйвер, система загрузиться и продолжить процесс установки уже не сможет, поскольку не будет иметь возможности обратиться к нужному устройству).

Во-вторых, в "нормальных" системах буферизация без нужды не используется (во всяком случае, допускается работа без буферизации). Например, в такой древней системе, как OS/360 (известной в нашей стране как ОС ЕС), прикладные программы имели два способа определения данных для операции ввода-вывода: режим пересылки и режим указания места. В первом случае ОС пересылала данные из указанной области в некий буфер, из которого уже осуществляла вывод на внешнее устройство (ну или читала в буфер, после чего пересылала в область памяти программы), во втором данные прямо читались или записывались в область памяти программы. Второй способ оказывался быстрее, причём значительно (скорость работы тогдашних процессоров наше воображение, естественно, не поразит), однако требовал определённых усилий со стороны программиста, связанных главным образом с синхронизацией выполнения ввода-вывода и работой программы.

Ну и позвольте небольшой камешек в Ваш огород. Если я правильно понял про "У меня, например, вся базовая память кроме первых 8 Кб отдана именно под использование в качестве аппаратных буферов", то у Вас область физической памяти от 800 до 9FFFF включительно отдана в распоряжение драйверов под буферы (а область от 0 до 800, возможно, используется под IDT -- для 256 записей как раз 8 Кб нужно). Если это так, то, весьма вероятно, Вы лишаетесь возможности когда-либо реализовать поддержку спящего режима и прочей ACPI'шной дребедени без переделок уже сделанного: чтобы эти функции работали, необходимо сохранять содержимое определённых областей памяти, список которых можно получить от BIOS. Ну а, ИМХО, любая ОС всё же должна поддерживать такие возможности хотя бы в теории. Впрочем, здесь всё зависит от постановки задачи; возможно, в Вашем проекте это действительно не требуется :)

Естественно, я имел в виду не первоначальные этапы загрузки, а загрузку конфигурационных файлов, драйверов и даже оболочку. Хотя некоторые умудряются все это сразу грузить в память посредством GRUB'а, где в основном используется BIOS, но мне такой вариант в принципе не подходит, потому что у меня загрузка выполняется вариативно в зависимости от содержимого конфигурационных файлов и может, также вариативно, частично повторяться без выполнения полной перезагрузки компьютера.

Моя ось поддерживает прямой ввод-вывод, но при работе с дисками он используется лишь дисковыми драйверами. У меня "без нужды не используется" прямой ввод-вывод :)

Вообще-то для IDT мне хватает 2 Кб, более того IDT большей своей частью находится совсем в другом месте (где именно, трудно сказать, т.к. я использую пэйджинг, но то что выше первого мега это точно). Далее в первой физической странице я сохраняю IVT и BDA (нетронутыми), парковочный код и только первые семь входов IDT (в конце страницы). Во второй физической странице находится специальная структура, отвечающая за распределение памяти. Кроме того я не затрагиваю EBDA, где могут храниться структуры, относящиеся к ACPI, а также все участки выше первого мега, которые не доступны для использования ОС (для детекта используется функция SMAP). Иными словами, изначально для распределения обычно доступен участок 0x2000..0x9EFFF(вверху 1-2 Кб обычно занимает EBDA, а ось выравнивает доступную память по границам страниц, поэтому свеху минус 4 Кб).

P.S. Не нужно переходить в оффтоп! При необходимости создай новую тему.

Моё мнение, что читать данные через DMA в буфер вместе с копированием будет быстрее, чем чтение через порты. Для этого достаточно посчитать количество тактов чтения из порта умноженное на количество байт. При количестве байт 1000h и среднем времени чтения из порта 4 такта, получится 4000h тактов. А копирование памяти по 4 байта займёт 100h тактов. Приблизительно так.

Chizh

Думаю, Вы правы по существу, хотя недооценили тормознутость программного ввода-вывода: ведь для чтения или записи каждого байта придётся заниматься обработкой отдельного прерывания, а это уже десятки тактов на каждый байт.

Ну а поскольку одновременно несколько секторов читать с гибкого диска невозможно, достаточно предусмотреть на один физический привод два буфера: с одним из них идёт текущая операция ввода-вывода по DMA, а другой в этот момент переписывается в область памяти программы или, наоборот, заполняется из неё. Если иметь только один буфер, нельзя будет параллельно читать/писать дискету и пересылать буфер.

Я просто не в курсе того, на каждый байт ли происходит прерывание или всё-таки на целый сектор (надо по спецификации уточнить). Прерывание на каждый байт мне кажется слишком нелогичным.

Думаю, что копирование буфера по сравнению со скоростью чтения диска будет мгновенным. Диск крутится слишком медленно, параллельность будет аморфной.

Гость, во-первых с флоппика в пределах одной дорожки можно читать несколько секторов. Далее вы описываете метод работы с DMA, который обычно используется при вводе-выводе звуковой информации. В многозадачной оси нет необходимости таким образом экономить время, т.к. пока выполняется операция чтения/записи через DMA, может работать совершенно посторонний код, хотя описанный подход конечно может ускорить обмен данными с дисковым драйвером, но его значительно сложнее реализовать с точки зрения синхронизации, т.к. к примеру при чтении придется синхронизировать не только заполнение полубуфера данными с диска, но еще и его освобождение для возможности повторного использования.

Chizh, при использовании PIO и прерываний прерывание будет генерироваться для каждого байта. Другое дело, что можно вообще не использовать прерывания, а опрашивать контроллер самостоятельно.

Chizh

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

Phantom-84

Думаю, Вы не совсем правильно поняли написанное Гостем. В некий момент времени читается только один сектор -- параллельное чтение нескольких секторов невозможно. Да, можно дать команду чтения целой дорожки, но само чтение будет всё равно последовательным.

При минимальном раскладе поэтому гарантированно хватает двух буферов, каждый из которых имеет размер сектора (т.е. 512 байт, хотя теоретически он может быть и другим). С одним из буферов идёт обмен данными по DMA, а другой в этот момент либо опорожняется после уже завершившейся операции чтения сектора, либо заполняется информацией для следующей операции записи -- поскольку процессор работает намного быстрее, он в сколько-нибудь грамотно построенной системе будет это успевать сделать раньше, чем закончится начатая раньше операция ввода-вывода.

Со сложностью синхронизации не согласен -- в такой схеме она элементарна. Хотя кому-то более простым может показаться выделение каждый раз (или постоянное резервирование) в нижней памяти буфера необходимого размера -- вплоть до длины дорожки.

SII, я все прекрасно понял (полубуфером я назвал один из двух буферов). Просто в случае звуковой информации такая схема частично поддеживается на аппаратном уровне. А здесь нужно все делать самому. Синхронизация элементарна (она изначально понятна), но вот с реализацией могут возникнуть трудности. Попробуй написать алгоритм и мы все вместе оценим, насколько он будет элементарен.

Phantom-84

Тогда прошу прощения, что я не понял, что Вы всё поняли :)

Насчёт алгоритма. Писать его на каком-то реальном языке, в т.ч. асме, смысла нет, поскольку он "завязан" на кучу дополнительных функций. Поэтому просто опишу его словами.

1. Начальное состояние -- оба буфера свободны, никакая операция ввода-вывода не выполняется.

2. Через ОС поступает запрос на чтение одного или нескольких секторов диска (заданы CHS, с которого начинается чтение, количество секторов и начальный адрес области памяти программы, куда должны быть помещены считанные данные).

3. Драйвер инициирует чтение одного сектора с диска, указывая в качестве приёмника по DMA любой свободный буфер.

4. Драйвер проверяет, не требуется ли выполнить копирование информации из другого буфера в область памяти программы. Если оказывается, что второй буфер заполнен информацией, выполняется её пересылка, по окончании которой буфер помечается как свободный, а управление возвращается ОС, чтобы та заняла процессор какой-нибудь полезной работой. Если второй буфер пуст, управление сразу возвращается ОС.

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

6. Операция чтения завершилась успешно. Буфер помечается как занятый информацией, счётчик секторов уменьшается на единицу, CHS увеличивается на единицу.

7. Если число секторов для чтения не равно нулю -- идём на п. 3 (чтение следующего сектора с параллельной пересылкой уже считанного в область программы).

8. Если число секторов уже равно нулю, пересылаем последний считанный сектор в область памяти программы, помечаем буфер как свободный и возвращаем через ОС код успешного завершения. Можно приступать к следующей операции.

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

При необходимости алгоритм можно усовершенствовать, чтобы он оставался работоспособным при заполненности обоих буферов сразу, т.е. не зависел от "лишних" прерываний -- тогда драйвер сможет нормально функционировать при разрешённых прерываниях (для "канцелярской" ОС вроде Винды или Линуха это непринципиально, поскольку время нахождения процессора в состоянии запрещения прерываний невелико, но для ОС жёсткого реального времени следует минимизировать время запрета прерываний). Такой драйвер фактически может работать параллельно самому себе (обрабатывать прерывание в связи с завершением операции чтения раньше, чем закончить пересылку ранее считанных данных в область памяти программы).