Аппаратные средства ядра специфичны?

Question

Аппаратные средства ядра специфичны?

435

Ki11akd0g 2016-06-28 в 21:38

Насколько я понимаю, ядро обеспечивает связь между программным и аппаратным обеспечением, и поэтому ядро должно направлять системные вызовы, выполняемые приложениями ОС, правильно? Значит, разные карты адресов ввода / вывода означают, что ядро должно программироваться по-разному? Читайте ниже, поскольку я не верю, что сформулировал этот вопрос очень точно.

Позвольте мне уточнить, и, пожалуйста, поправьте меня, если я ошибаюсь, потому что именно так я понял то, что написано в нескольких статьях. Я буду использовать семейство x86 в качестве основы для моих примеров. Процессоры x86 используют команду INT, а также индекс, называемый таблицей векторов прерываний, для сопоставления идентификатора INT с правильным расположением требуемой подпрограммы (подпрограмма и IVT, расположенные в BIOS, верно?). Сами подпрограммы написаны так, что они могут дать команду оборудованию, специфичному для компьютерной системы, выполнить задачу, основанную на протоколе используемого оборудования. Это позволяет ОС совершать системные вызовы и обмениваться данными с оборудованием, не имея никакого знания об оборудовании или отображении ввода / вывода, характерном для системы. Все, что необходимо для связи ОС с аппаратным обеспечением, - это идентификатор конкретного требуемого ISR. Поскольку ядро является связующим звеном между аппаратным и программным обеспечением, я предполагаю, что приложения, запускаемые ОС, не обязаны даже знать идентификатор ISR #, они просто сообщают ядру, что они хотят, например, записать данные X на жесткий диск, ядро передает данные X на правильный ISR, который затем записывает данные на жесткий диск. Таким образом, две системы, полностью идентичные за исключением того, что они используют разные идентификаторы ISR для разных задач, потребуют немного разных ядер?

И будет ли это также означать, что загрузочный сектор, который загружает ядро, также будет зависеть от сопоставления идентификатора ISR, поскольку для загрузки ядра потребуется выполнить системные вызовы для чтения с жесткого диска?

Я прошу прощения, если это не в том месте, но я прочитал, что это правильное место для вопросов, связанных с оборудованием. Спасибо!

1

Еще в 1990-х годах ядра Unix были настроены и связаны для каждой установки машины. Тенденция заключалась в том, чтобы использовать либо схемы «включай и работай» (самоидентифицирующееся оборудование в сочетании с самоконфигурирующимся программным обеспечением), либо управляемую данными конфигурацию (например, дерево устройств). Вы слишком сосредоточены на прерываниях. Прерывания являются лишь средством повышения производительности и не являются необходимыми для доступа к устройству. Чтобы получить доступ к устройству, вы должны знать, * как * получить к нему доступ (т. Е. Метод), и * где * это устройство (т. Е. Его адрес устройства, которое может быть портом ввода-вывода или адресом памяти). ). sawdust 7 лет назад 0

@sawdust Я просто не понимаю, как устройство может самоидентифицироваться без какого-либо аппаратного протокола взаимодействия. Если бы я должен был подключить SD-карту к Z80, и именно я подключил ее, я мог бы настроить ее так, чтобы выходной 06h на адрес io 0002h приводил к низкому контакту CS и инициировал передачу, или я мог настроить ее так что выход с 03h на io адрес 0002h инициирует передачу. Да, система может назначить SD-карте адрес 0002h, но как она могла бы знать, что OUT 06h или 03h приведет к низкому контакту выбора микросхемы и инициирует передачу? Ki11akd0g 7 лет назад 0

@sawdust Если только универсальные шины не используются для подключения всех устройств, а шины имеют одинаковую распиновку. Так, например, контакты 0-31 PCIe назначены контактам 0-31 каждой подключенной шины данных устройств, независимо от подключенного устройства. Если это действительно так, то это имеет смысл. Ki11akd0g 7 лет назад 0

Вы выбрали ужасный пример. SD-карта не является самоидентифицирующейся, а является скорее носителем, чем периферийным устройством. Устройство, с которым центральный процессор будет взаимодействовать, будет контроллером MMC, а не самой SD-картой. Успешными схемами plug-n-play являются те, которые используют периферийную шину, такую как PCI и USB. Метод идентификации периферийных устройств, подключенных к шине, является неотъемлемой частью протокола шины. Так что да, должен быть * "какой-то протокол аппаратного взаимодействия" *. sawdust 7 лет назад 0

Ваше внимание к аппаратным средствам ПК x86 искажает ваше понимание. С самого первого дня IBM PC стандартизировал свою конфигурацию, и клоны ПК последовали его примеру, чтобы установить стандарт компьютеров [Wintel] (https://en.wikipedia.org/wiki/Wintel). Процессоры ARM, которые встречаются в мобильных устройствах и SBC, не имеют какой-либо стандартизации конфигурации системы и страдают от одной сборки ядра для каждого варианта платы / машины. Только с принятием Device Trees для ARM Linux дистрибутивы Linux для плат ARM стали возможными. sawdust 7 лет назад 0

Давайте [продолжим это обсуждение в чате] (http://chat.stackexchange.com/rooms/41786/discussion-between-ki11akd0g-and-sawdust). Ki11akd0g 7 лет назад 0

1 ответ на вопрос

1

Accepted Answer · 2016-06-28 22:09:32

Что касается команд INTh, на которые вы ссылаетесь (см. « Прерывания BIOS» ), вы правы, что это использовалось для того, чтобы ОС получала доступ к низкоуровневому оборудованию. На современном компьютере эти вызовы (если они выполняются) часто оказываются в CSM (модуль поддержки совместимости, по крайней мере, на языке AMI), который может обрабатывать эти запросы. В случае, скажем, вызова видео BIOS, который будет выполнять код в видео BIOS, если он присутствует. Я работал с Intel IGP в качестве разработчика BIOS, и как часть окончательного образа у нас был инструмент от Intel, в котором мы выпекаем их видео BIOS в виде большого двоичного объекта.

Аналогично, BIOS может реализовывать «эмулированные» версии вызовов для чтения / установки RTC. Современная ОС просто не будет выполнять все эти устаревшие обработчики, поскольку ей не нужно полагаться на BIOS для такой поддержки - например, может существовать драйвер ядра, который знает, как напрямую общаться с вашим PCH, чтобы связываться с Настройки RTC.

Как вы можете себе представить, это очень, очень медленно и больше не используется современным программным обеспечением. Вместо этого ОС владеет оборудованием, необходимым для обеспечения уровня абстракции, который позволяет графическим приложениям использовать драйверы графического процессора для выполнения этих задач; это устройство, конечно, обычно PCIe от ПО POV и отображается в памяти.

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

Теперь, что касается разных карт адресов ввода-вывода и тому подобного, напомним, что x86 имеет как адресное пространство ввода-вывода, так и адресное пространство памяти. Если вы вспомните Plug-and-Play, при загрузке ваш BIOS будет проходить и перечислять дерево PCI-устройств, которое для современных систем в основном охватывает все ваши периферийные устройства, по крайней мере, из POV SW (т.е. контроллер DRAM находится на Шина PCIe 0, ваши USB-контроллеры являются устройствами PCI от SW POV и т. Д.). Используя BAR (регистры базовых адресов), BIOS знает, сколько памяти и какого типа требуется целевому устройству, и сделает все возможное, чтобы удовлетворить запрос.

Окончательное сопоставление передается операционной системе на хранение, и она может принять это во внимание или выполнить свою собственную фазу перечисления. Например, в Linux есть «причуды», которые вы можете применить к данным идентификаторам устройств PCI до загрузки ОС, и вы можете вспомнить параметры загрузки ядра, которые могут влиять на то, сколько памяти они выделяют, какие IRQ они заканчивают и т. Д. ,

Аппаратные средства ядра специфичны?

1 ответ на вопрос

Похожие вопросы