Драйвер блочного устройства в Linux Опции

[3.14]

Отзовитесь плиз, кто писал драйвер блочного устройства под линух.
С символьным относительно быстро разобрался, а вто с блочным
Примеры в uClinux не особо помогают, пока даже не могу вычленить нужные части.

[3.14]

Мне вот еще что не понятно.
В примере с символьным драйвером обращение к устройству сводится к вызову функций чтения/записи которые прописаны в структуре fosp, соответсвенно когда обращаюсь к устройству через read/write и т.п. то передаю указатель на буфер обмена.
В драйвере блочного устройства я не пойму как передается указатель на буфер обмена. В примере, осуществляется такое объявление функции запроса

Код

...
static XStatus(*req_fnc) (XSysAce * InstancePtr, u32 StartSector,
    int NumSectors, u8 * BufferPtr);
...
static void xsysace_do_request(request_queue_t * q)
{
    if (req_active)
 return;

    for (;;) {
 INIT_REQUEST;

 switch (CURRENT->cmd) {
 case READ:
     req_str = "reading";
     req_fnc = XSysAce_SectorRead;
     break;
 case WRITE:
     req_str = "writing";
  req_fnc = XSysAce_SectorWrite;
     break;
 default:
     printk(KERN_CRIT "%s: unknown request %d.\n",
         DEVICE_NAME, CURRENT->cmd);
     end_request(0);    
     continue;      
 }
 req_active = 1;
 wake_up(&req_wait);
 return;
    }
}

Т.е., например вызывается XSysAce_SectorRead, которая заполняет BufferPtr относящийся к структуре InstancePtr, но вот как этот BufferPtr передается приложению пользователя

[amw]

В ядрах 2.6 есть еще так называемые шедулеры ввода/вывода которые занимаются планированием очереди, предсказанием номеров секторов, которые могут потребоватся в следующей оперции чтения/записи и много другого.
Как в 2.4 с этим - я не знаю, но стоит посмотреть есть ли в исходниках ядра файл с именем elevator.c (ну или похожим). Если есть, то стоит его изучить, хотя это занятие неблагодарное. После изучения этого файла (и сопутствующих ему) появится понимание (а может наоборот - пропадет вовсе ), но использовать это понимание на практике будет затруднительно.

Драйвер блочного устройства знает как выполнять чтение/запись секторов, но не знает когда это происходит.

[makc]

В ядрах 2.6 есть еще так называемые шедулеры ввода/вывода которые занимаются планированием очереди, предсказанием номеров секторов, которые могут потребоватся в следующей оперции чтения/записи и много другого.
Как в 2.4 с этим - я не знаю, но стоит посмотреть есть ли в исходниках ядра файл с именем elevator.c (ну или похожим).

В 2.4 элеватор и все, что с ним связано тоже есть. Немного не в том виде, что в 2.6, но есть.

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

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

Драйвер блочного устройства знает как выполнять чтение/запись секторов, но не знает когда это происходит.

Когда именно - не знает, но у него есть возможность поддерживать свою очередь запросов на ввод-вывод. Это дает большую свободу.

[amw]

Драйвер блочного устройства знает как выполнять чтение/запись секторов, но не знает когда это происходит.

Когда именно - не знает, но у него есть возможность поддерживать свою очередь запросов на ввод-вывод. Это дает большую свободу.

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

[makc]

А можна с этого места чуть подробнее.

Можно.

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

Книга Linux Device Drivers 2nd edition, CH12, P. Handling Requests: The Detailed View.

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

Это точно. Тем более, что смысла изучать эту очередь мало - она основана на самых общих принципах организации блочных запросов.

Что касается "ручного" создания своей очереди, то это довольно просто.
1. Отказаться от использования в функции-обработчике запросов драйвера блочного устройства макросов типа INIT_REQUEST и ему подобных. Эти макросы подходят лишь для очень простых драйверов, для более сложных (о которых и идет речь) нужно работу этих макросов выполнять самим.
2. С помощью функции blkdev_entry_next_request извлекаете из системной очереди запросов следующий запрос. (По очереди можно перемещаться с помощью функций blkdev_next_request и blkdev_prev_request).
3. Исключаете запрос из системной очереди с помощью функции blkdev_dequeue_request.
4. Добавляете запрос в свою внутреннюю очередь, которой управляете оптимальным для устройства образом. (Я хранил очередь как связанный список и пытался группировать последовательные пакеты запросов, избегая при этом увеличения длины очереди больше максимальной величины).
5. Просматриваете внутреннюю очередь на предмет того, какие запросы теперь можно обработать.
6. Если есть запросы для обработки - выполняете обработку отдельных блоков в внутри запросов (обработку блока подтверждаете с помощью функции b_end_io блока) и завершаете обработку запросов с помощью функции blkdev_release_request для каждого запроса.
7. Все повторяется заново, пока в системной очереди есть запросы.

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