Все, что я видел в *nix, было набором абстракций от аппаратного обеспечения, но мне любопытно, как работает аппаратное обеспечение.
Я программировал на ассемблере, но это всего лишь набор абстракций.
Как процессор понимает коды операций сборки (как байт-код)?
Как работают драйверы устройств (с объяснением на более низком уровне (абстракции))?
Вау.... огромный вопрос! На самом корневом уровне процессор может взаимодействовать с оборудованием с помощью специальных инструкций, например. IN и OUT для портов ввода-вывода на оборудовании x86 и/или какой-либо области ввода-вывода с отображением памяти.
Различное оборудование имеет очень разные протоколы / правила относительно того, как общаться по этим каналам, и в целом, вероятно, произойдет ужасный сбой, если эти правила не будут соблюдаться. Примером может служить устройство вывода, которое может обрабатывать только ограниченное количество передач в секунду, поэтому драйвер должен проверить, готово ли оборудование отправить больше данных, прежде чем пытаться что-либо передать. Вам также обычно необходимо убедиться, что нет одновременных попыток доступа к одному и тому же устройству, что является одной из многих веских причин, по которым операционные системы не позволяют программам пользовательского режима напрямую обращаться к оборудованию, когда им этого хочется.
Почему бы не взглянуть на исходный код Linux, чтобы удовлетворить свое любопытство?
Обратите внимание, что большая часть этого написана на C, а не на ассемблере. Нет строгого требования использовать язык ассемблера для написания драйверов устройств, если у вас есть инструкции для связи с оборудованием (что верно для C, но может быть неверно для некоторых языков более высокого уровня).
Драйверы устройств образуют интерфейс между API-интерфейсом устройства ОС и реальными аппаратными регистрами.
Модель API устройства Linux является продолжением более широкой концепции Linux, согласно которой все является файлом, и что приложение может выполнить все, что ему нужно, с помощью функций open(), read(), write(), ioctl() и close( ) интерфейс. Под капотом есть процедура install(), но ОС решает, когда ее вызывать.
Другая сторона медали — аппаратное обеспечение. ЦП обращается к регистрам устройства либо с помощью специальных инструкций ввода-вывода, либо с помощью обычного доступа к памяти в специальных ячейках памяти, подключенных к оборудованию. Хотя аппаратные регистры могут действовать как память, они могут делать то, чего память не может. Довольно часто запись в один из регистров устройства может изменить значения некоторых других его регистров, и, в частности, может измениться или быть изменена электрической активностью в подключенном оборудовании.
Драйверы устройств восполняют этот пробел. Поскольку возможности для типов устройств практически безграничны, трудно сделать обобщение о том, как функции отображаются, кроме нескольких моментов. Процедура install() вызывается во время запуска системы, настраивает регистры для правильной работы, обычно это включает в себя настройку службы прерывания и обработку; подпрограмма open() предоставляет приложению логическое соединение с устройством; обычно предпринимаются попытки заставить read() и write() перемещать данные каким-то разумным образом, хотя иногда вы видите, что они реализованы как no-ops; а оперативные настройки устройства выполняются через ioctl(). И, конечно же, основная задача close() состоит в том, чтобы отменить работу open(), уделяя особое внимание высвобождению любых системных ресурсов, захваченных open().
Ну, в любом случае, это ориентированный на Linux подход. Модель Windows, по крайней мере, та, с которой я знаком (вероятно, устаревшая), имеет тенденцию предлагать библиотеки вызовов функций для конкретных устройств.
У устройств есть «прерывание» — так они сигнализируют о том, что им нужно внимание процессора.
Драйверы устройств имеют «процедуру обслуживания прерывания» — код, который запускается, когда на этом устройстве происходит прерывание.
Драйверы устройств затем читают или записывают данные в низкоуровневой форме, которая сопоставляется с устройством — обычно либо символы, либо блоки данных. Верхние уровни драйвера устройства управляют упаковкой, распаковкой, буферизацией и преобразованием данных более низкого уровня в данные более высокого уровня, например строки текстовых символов.
Довольно просто в своих основах, но это очень быстро усложняется, когда вы добавляете несколько устройств, нескольких пользователей, отслеживая состояние для обоих, и множество других абстракций, таких как файловая система, поверх базового блочно-ориентированного ввода-вывода устройства.
«Искусство ассемблера» — хорошая, но немного устаревшая книга с пояснениями почти ко всему аппаратному и низкоуровневому. Вы должны дать ему прочитать.
Он доступен легально в Интернете и в печатной форме.
РЕДАКТИРОВАТЬ: Комментатор Самоз упоминает новое издание, так что теперь оно, вероятно, актуально!
