В обход планирования ввода-вывода и буферизации страниц ядра Linux

Question

Чего я хочу добиться:

Developing an linux application in C language, that "exclusively" accesses a

Жесткий диск PATA/SATA (HDD) для отправки команд ATA (фактически только те команды ATA, которые не изменяют ни один байт на жестком диске, к которому осуществляется доступ - например, READ_SECTOR, IDENTIFY_DEVICE, SET_FEATURES и т. Д.).

Под "эксклюзивом" я подразумеваю, что как только HDD включается (специальное аппаратное обеспечение, которое представляет собой простой выключатель питания, гарантирует, что HDD не включается до тех пор, пока приложение не загружено и не желает это делать), первое и только доступ к этому HDD только для моего приложения. IOW, кроме моего приложения, даже ядро ​​Linux (включая подсистему SCSI), а также любое другое приложение, процесс или пользовательский пользователь никогда не смогут получить доступ к этому жесткому диску, если только мое приложение не дает им указаний / разрешений.

К моему приложению предъявляется еще одно требование: поскольку доступ к жесткому диску в нашем приложении весьма критичен (с точки зрения управления, а не с точки зрения производительности), поэтому нежелательно, чтобы какой-либо график ввода-вывода участвовал в выполненных транзакциях. приложением (производительность на этом жестком диске не является ограничением). Также не желательно, чтобы данные, считываемые с жесткого диска, буферизировались буфером ядра или буфером страницы. Приложение будет читать с размером блока 512 байт или только кратным ему.

Теперь проблема, с которой я сталкиваюсь:

Подсистема SCSI находится ниже (и написана для работы) с планировщиком ввода-вывода и буфером ядра или буфером страниц.

Хотя подсистема SCSI предоставляет 'sg-драйвер' для прямой отправки команд (- команды подсистемы Linux SCSI, а не команды ATA или SCSI напрямую - которые затем преобразуются посредством libata в реальные команды ATA. Я прямо здесь?) Для жесткий диск, но это подход ввода / вывода - вы даете i/p и получаете o/p, т.е. у вас нет контроля над процессом протокола передачи данных (например, состояния PIO, DMA и ATA и регистры ошибок и т. д.) и конфигурация устройства (с помощью команды Set Features ATA.).

Также механизм сообщения об ошибках должен быть надежным и специфичным для протокола ATA, а не просто кодов ошибок подсистемы Linux SCSI. IOWs мое приложение должно иметь доступ к регистру ошибок ATA и регистру состояния ATA на жестких дисках PATA/SATA.

То, что требует мое приложение - это эксклюзивный контроль над жестким диском, например. Выполнение команды READ_SECTOR ATA и последующее извлечение самих данных с жесткого диска напрямую через чтение портов ввода-вывода или через "libata" с вышеуказанными требованиями должно быть выполнено.

Что я не могу сделать?

Я не собираюсь писать драйвер устройства PATA/SATA HBA или каждый HBA, доступный на рынке, поскольку они уже включены в ядро ​​для libata.

Что я узнал до сих пор?

Чтобы выполнить желаемую задачу, мне может (или нет?) Написать драйвер блочного устройства, который напрямую взаимодействует со слоем VFS(или есть ли способ обойти VFS даже, чтобы мое приложение могло напрямую связываться с этим драйвером блока)) без использования буфера ядра или буфера страниц и планировщика ввода-вывода. Этот блочный драйвер будет напрямую связываться с libata(минуя верхний уровень подсистемы SCSI), который затем связывается с драйвером PATA/SATA HBA.

Можно ли написать такой драйвер независимо от архитектуры процессора?

Это осуществимый подход? Если да, то это повлияет на производительность ввода-вывода других подключенных жестких дисков, к которым мое приложение не обращается. в этом случае. Нужно ли в этом случае записывать системный вызов через VFS(или, если возможно, в обход), чтобы мое приложение связывалось с моим блочным драйвером? Пожалуйста, просветите меня относительно этого подхода.

или возможно, чтобы мой драйвер блочного устройства напрямую связывался с драйвером PATA/SATA HBA, написанным для libata, но, опять же, этот подход повлияет на производительность ввода-вывода других подключенных жестких дисков, к которым мое приложение не обращается. в этом случае. Кроме того, как мое приложение будет взаимодействовать с этим драйвером блочного устройства?

Пожалуйста, просветите меня.

Также я хочу знать о том же сценарии для моего приложения, с одним отличием - вместо дисков PATA/SATA, что если у меня есть жесткие диски SCSI и их варианты - в частности, SAS, Fibre Channel и USB. И, конечно, на этот раз я буду использовать не команды libata и ATA, а команды протокола SCSI.

Хотели бы вы предложить в качестве хоста приложения живой дистрибутив CD, содержащий драйверы либаты PATA/SATA HBA (- не для подсистемы IDE, поскольку я не буду использовать его, поскольку он устарел сейчас и, следовательно, может не обновляться в отношении для водителей HBA.) для большинства HBA.

Короче говоря, какой самый прямой способ для приложения linux получить доступ к жесткому диску PATA/SATA или SCSI/SAS/Fibre Channel.

Я надеюсь, что предоставил достаточно информации по моему вопросу, но если вы хотите получить больше информации или больше разъяснений, пожалуйста, не стесняйтесь спрашивать.

Обновление 1 (27/6/2012):
После полезной дискуссии с Крисом (см. Ниже) и моих исследований я пришел к следующим выводам:

1. что готовый адаптер USB-PATA/SATA не решит мою задачу, потому что это не позволяет моему приложению. или драйвер, чтобы изменить режим передачи данных (PIO против DMA) на лету, это не позволяет моему приложению. или драйвер для чтения регистров ATA.

2. что может помочь нестандартный адаптер USB-PATA/SATA, но для этого потребуется либо встроенный процессор, который должен реализовывать протокол ATA, либо микросхема FPGA, которая реализует весь протокол ATA. Но решение со встроенным процессором использует GPIO и не подходит для SATA, так как для него требуются специализированные приемопередатчики, а производительность ввода-вывода будет проблемой как для PATA, так и для SATA - слишком медленно для моего приложения.

Такой адаптер будет общаться с моим драйвером ядра Linux (или через libusb) с моим приложением. по пользовательскому протоколу, который помогает в общении ч / б мое приложение. и протокол ATA на встроенном процессоре. В случае чипового решения FPGA мне нужно реализовать этот протокол в самой FPGA вместе с протоколом ATA.

Но на данный момент для меня невозможно с точки зрения труда, времени и денег внедрить решение FPGA и решение с встроенным процессором. Так что я застрял с программным решением.

Наконец, кажется, что мне, вероятно, придется дублировать и модифицировать все до уровня аппаратного интерфейса, чтобы соответствовать требованиям, как сказал Крис.

Итак, как мне поступить между уровнем VFS и драйвером HBA или уровнем libata. Что нужно реализовать, а что нет?

Может кто-то пролить свет на эту проблему? Есть идеи??

Обновление 2 (7/7/2012):
Я борюсь с проблемой. Есть кто-то на ТАК, кто может просветить меня?

Answer 1

Реально, если вы хотите этот уровень контроля детализации, вам придется написать свои собственные низкоуровневые драйверы.

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

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

Гораздо более простым решением, если оно будет соответствовать вашим потребностям, будет использование адаптера USB-to-SATA или PATA. Вы можете указать существующим драйверам ядра игнорировать VID/PID с помощью режима причуд modprobe, а затем общаться с устройством через libusb из пользовательского пространства. Тем не менее, там наверняка будет задержка.

Для наилучшего уровня управления вам, вероятно, необходимо подключить накопитель к встроенному процессору, который не имеет буферизации ввода / вывода, или, возможно, даже к ПЛИС. Это было не особенно трудно сделать для низких скоростей передачи данных с PATA, для SATA, вероятно, требуются специализированные приемопередатчики, но они могут быть вне пределов возможности (или, возможно, вы можете работать через один из адаптеров). Вы, вероятно, в конечном итоге подключите это пользовательское периферийное устройство к ПК через USB или даже через последовательный порт и будете использовать его для выдачи заданий и получения результатов (было бы удобно, если вы настроите его так, чтобы ПК мог загружать прошивку / битовый поток устройства, поэтому у вас есть гибкость).