OSDev

Мда, нехорошо получилось, не стоило мне в таком сонном состоянии читать и уж тем более поспешно отвечать.
При том что сам я флопом пользовался буквально вчера, всё равно мозг даже и не подумал что кто-то под него будет программировать, так что прочёл "PIO" и проигнорировал русское сокращение, соотв. по-умолчанию подставив HDD.

Ок, правильная ссылка: http://wiki.osdev.org/Floppy_Disk_Controller
Правда, там ессно практически всё про DMA режим, разве что в части http://wiki.osdev.org/Floppy_Disk_Contr ... _Transfers сказано "poll the RQM bit in the Main Status Register to determine when the controller wants to have data moved in/out of the FIFO buffer" + "When the transfer is complete, read the "result" bytes to see if there were any errors." + MSR.CB "Command Busy: set when command byte received, cleared at end of Result phase", т.е. если стадия получения результата "result phase" закончилась раньше, чем были считаны все ожидаемые данные, то понятно что искать байты статуса надо среди последних считанных. Хотя я бы в таком случае всё же поставил эксперимент (на реальном железе, конечно, ибо эмули, точнее, их разработчики, по очевидным причинам PIO режим флопа не любят).

> У меня уже есть тестовый системник, только разъемы IDE, а у меня все диски sata.
Ну уж IDE хард-то нынче найти для тестов весьма просто.

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

> К тому же загрузчики обычно используют сервис BIOS, т.е. напрямую не работают с прерываниями.
Люто плюсую, тем более что этот слой эмуляции нередко позволяет нахаляву грузиться (а иногда и даже потихоньку с ними работать дальше) с самых разных устройств, включая el-torito, флешки, intel fake raid, scsi диски и т.д.

В принципе можно использовать прерывания BIOS и для служебных целей,переключаясь в реальный режим, но опять же на мой взгляд могут возникнуть проблемы в smp системе, так как BIOS использует устаревший контроллер PIC, а в SMP системе на сколько я понял используется IO APIC, причем использовать стандартные ISA IRQ в APIC нельзя, только PCI-шные вроде бы. Если бы было можно использовать PIC(для стандартных прерываний) и APIC(как дополнительные), то тогда бы это прокатило.Может я в чем то ошибаюсь...

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

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

Click me

IDE диск можно и на эмуляторе и здесь все гораздо проще, но для начала мне бы хотелось с флоппиком доработать. Можно и рамдиск, но мне памяти жалко... Мегабайта 2 у системы захавает... рамдиск я буду для другого использовать.

Обработчик прерывания будет реализован в hal, как и сигналы с потоками, и оповещаться драйверы будут при помощи сигналов.
Боюсь что в SMP системе данный способ не проканает(МОЖЕТ Я И ОШИБАЮСЬ), если конечно не появилось расширенного сервиса int 0x13 для защищенного режима(как сервис PCI).

Во всем.

Здесь ты прав. Переключаться в RM из "раскрученной" системы - неблагодарное дело. Было время, когда я переключался в RM, чтобы выключить/перезагрузить комп. Даже несмотря на то, что это последнее переключение в RM перед выключением компа/переинициализацией BIOS, я постоянно боялся, что случится какой-нибудь глюк. Единственный нормальный вариант переключения PM-RM (в том числе и многократного) - делать это на начальном этапе, как это реализовано в нек. вторичных загрузчиках. У меня в ядре сейчас тоже есть код возврата в RM, но он работает именно на начальном этапе и предназначен для того, чтобы после загрузки Multiboot-совместимым загрузчиком вернуться к нормальным условиям начальной загрузки (штатно система запускается в реальном режиме).

В таком случае остается только один выход - создать рамдиск и загружать в него драйверы устройств хранения и шинных интерфейсов.