@nekun@qoto.org @ru@lor.sh @rf@mastodon.ml Это имеет смысл в двух случаях:
1. время доступа к устройству меньше, чем программная подгрузка;
2. доступ нужен до (или без) загрузки драйвера.
Если время доступа больше чем нужно драйверу и переключению контекста, то железка просто будет останавливать процессор, вместо того, чтобы он переключился на другую задачу, пока текущая ждёт ввода-вывода. Это было бы просто потерей производительности.
А если накопитель ещё и внешний, и его отсоединили, то комп или зависнет намертво, или работавшая с ним задача грохнется с аппаратным исключением (если это реализовано).
Так то флэш часто отображается в память, например, на ARM-ах.
Я ещё добавил бы такие доводы:
1. Уменьшение кодовой базы операционных систем, а следовательно и человеческих затрат, и багов.
2. Унификация wear-leveling слоя в стандартном контроллере чипсета.
Кстати, кажется, из этих соображений от программно-управляемых NAND пришли к eMMC и UFS.
> Если время доступа больше чем нужно драйверу и переключению контекста, то железка просто будет останавливать процессор, вместо того, чтобы он переключился на другую задачу, пока текущая ждёт ввода-вывода.
Ну, он ещё по таймеру может переключиться на шедулер, впрочем я не имею понятия, ждут ли прерывания завершения инструкции (возможно, заимплементить специальный класс адресов в MTRR?)
Причём, такие задержки также можно минимизировать WB-кэшем контроллера.
> А если накопитель ещё и внешний, и его отсоединили, то комп или зависнет намертво, или работавшая с ним задача грохнется с аппаратным исключением (если это реализовано).
Контроллер прерывание пошлёт и драйвер обработает: а собственно что ещё делать задаче, пытающейся достать мапнутый недоступный физически файл, кроме как сегфолтиться? ну а через fd и ОС ошибку дать может, всё штатненько
@nekun@qoto.org @rf@mastodon.ml @ru@lor.sh Помимо обычных прерываний в процессорах обычно есть другие аппаратные исключения (Hardware exception), в том числе отвечают за всякие ужасы на шине, segfault один из них, который вырабатывается MMU. Ещё бывает bus fault, который вырабатывается если обращение не может быть обработано внешним устройством.
Прерывание от таймера это как правило обычное прерывание, а прерывания обычно обрабатываются по завершению инструкции. То есть обычный таймер не поможет: процессору сначала придётся дождаться конца цикла шины, а потом только заняться таймером.
Для целей отмены таких долгих обращений нужно использовать исключение шины (bus fault или что-то подобное): если цикл обращения затянулся слишком долго — обрывать его и делать повтор позже.
1. Уменьшение кодовой базы ОС настолько же, насколько увеличение сложности железа. Усложнять железо дороже. Но да, если такое возможно малой кровью — делают, например, в случае с флэшем.
2. Унификация обычно делается на уровне интерфейса (SATA, USB вот это всё). Если контроллер интерфейса будет уметь отображать носитель в память — такое будет работать.
Но это не универсальное решение — в отображении есть смысл, если адресное пространство носителя (носителей) меньше, чем у процессора. Но оно может быстро исчерпаться.
Насчёт переключения по таймеру.
Тут всё будет зависеть от того, как реализована работа с памятью в процессоре и на шине. Для того, чтобы прерваться, нужно, чтобы
— процессов поддерживал отмену цикла шины с будущим повтором (abort&retry);
— системный контроллер поддерживал abort шины по таймауту;
— контроллер носителя также поддерживал такой режим;
— ОС умела отличать остановку по неготовности устройства от какой-нибудь ошибки (обращение к несуществующему устройству например);
Из-за того, что в аппаратной реализации такого куча нюансов, обычно стараются сложную логику вынести в софт.