Любопытство вне абстракций: как байт-код выполняется? как драйверы устройств работают?
Все, что я видел на *, отклоняет, был ряд абстракций от аппаратных средств, но мне любопытно относительно того, как аппаратные средства работают.
Я запрограммировал в блоке, но это - все еще только ряд абстракций.
Как процессор понимает коды операций блока (как байт-код)?
Как драйверы устройств работают (с объяснением на более низком уровне (абстракции))?
4 ответа
Wow.... огромный вопрос! На самом корневом уровне процессор может общаться с аппаратным обеспечением через специальные инструкции, например, 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, по крайней мере, та, с которой я знаком (вероятно, устаревшая), имеет тенденцию предлагать библиотеки вызовов функций для конкретных устройств.