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

Я писал, причем совсем недавно. А в чем проблема, что не понятно?

Для ядра 2.6 пример есть тут http://lwn.net/Articles/60368/.
Можно еще посмотреть в исходниках drivers/block/xd.c

Нижесказанное касается uClinux, ядро 2.4.
Начал я с примера "sbull" идущего с книжкой Linux Device Drivers.
Модуль скомпилировался, но загружаться отказался с ошибкой

Тогда я взял пример по проще (драйвер Xilinx sysace), в результате, ошибка с "mulsi3_proc" все равно появляется.
Объявляю init, clean модули и регистрирую драйвер (register_blkdev) - ОК.
Объявляю структур block_device_operations структуру - OK
Как дохожу до blk_init_queue - ошибка unresolved symbol divsi3_proc

Судя по именам "mulsi3_proc" и "divsi3_proc" это функции выполнения умножения и деления?
Может отсюда и копать?

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

ucLinux не пользовал. Там типа на ядро патчи накладываются?
С 2.4 до блочных не дошел, а теперь уже и не надо, так как перешел полностью на 2.6.
mulsi3_proc и divsi3_proc - это функции для обработки операций с плавающей точкой. А какой процесссор используется? Он что, без FP модуля? Если да, то нужно обязательно включить в ядре поддержку Floating Point Emulation.
Линковать _МОДУЛЬ_ ядра с библиотекой, не важно с какой, вообще бред, потому как ядро должно работать само по себе и _НЕ_ должно зависеть от бибилотек.

Вообще-то эти функции находятся обычно в libfloat и линковать надо с ключем -lfloat. Но под ucLinux может быть и по другому.

Всем спасибо, с мертвой точки наконец сдвинулся.
Как и говорили, дело в FPU.
Когда добавил ключик -mno-xl-soft-mul, ошибка пропала. Хотя не понятно, в других примерах используются ключи -mxl-soft-mul или -DNO_FPU. Никакой информации на эти ключи в доке на компилятор не нашел (mg-gcc).

2 amw
Я ставлю эксперименты на MicroBlaze - синтезируемый процессор (Xilinx) ver3. В четвертой версии появилась поддержка плавающей точки, но у меня ресурсрв FPGA мало (Spartan3-200), вместе со всеми необходимуми корками (RS232,Контр.пр.таймер,SDRAM,Ethernet,GPIO) осталось свободных 2 слайса
Как из Linux делается uClinux не знаю
А разве с ядра 2.6 так кардинально изменилась идеология написания драйверов?

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

Ага, я тоже когда-то что-то типа этого долго искал, в смысле ключи gcc подбирал.

В ядрах 2.4 и 2.6 отдичается идеология. Много функций переписаны, в смысле их вызов и действия.

С блочными все по другому (по сравнению с символьными).
Во первых на блочные устройсва имеется кеш в ядре, и функция сброса очереди (в данном случае это static void xsysace_do_request(request_queue_t * q)) вызывается менеджером кеша для записи данных на устройство.
Во вторых, блочное устройство, это как-бы не совсем самостоятельное устроство, вернее - не самодостаточное.
Например, когда пользовательский процесс вызывает функции fopen(), fread(), fwrite(), то тут участвует в первую очередь файловая система (в терминах ядра - VFS), через нее (VFS) все и роисходит.
Если обратится на прямую, например

то запрос на чтение сектора пройдет мимо VFS (условно говоря, потому как VFS участвует во всех оперциях с устройсвами) но через кеш. Ядро будет читать не один сектор, а несколько (количество зависит от аппаратуры, менеджера памяти и параметров очереди request_queue_t). Один сектор попадет пользовательскому процессу, а остальные дальше кеша не пойдут.

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

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

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



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



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

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

Можно.



Книга 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, который нужно захватывать во избежание нарушения структуры системной очереди.

Есть такая, и даже 3-е издание, но появилась недавно, пока читаю.

Ага! Поковыряюсь, а то по исходикам не совсем понятно была последовательность действий.
В ядрах с 2.6.12 (помоему) есть такая полезная функция:
blk_queue_ordered(queue, QUEUE_ORDERED_FLUSH);
Вызывать при инициализации очереди.

Спасибо!

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

Отучение может быть выполнено лишь одним способом - задачи прерывания выполнять путем последовательного опроса состояния устройства (polling). Т.е. программно ждать флагов и делать то же самое, что делает обработчик при появлении прерывания.

Ждать флагов можно разными способами. Один из них - опрос флагов с помощью потока уровня ядра (kernel thread).

А если я сделаю так:
в фунции xsysace_do_request вместо объявления функций обмена, провожу чтение/запись данных и перед выходом вызываю xsa_complete_request(1).
Интересно, как себя при этом поведет xsa_thread?

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

Не понятно:
1) В доке сказано, что файловая система может находиться только на блочных устройствах, дык зачем тогда регистрировать устройство как devfs?
2) MBR сектор для разных файловых систем разный?
2) При объявлении диска нужно указать количество головок, секторов и цилиндров. В MBR секторе флешки есть значения количества головок и секторов, а как определить количество цилиндров?

По логике такого драйвера xsa_thread вообще не нужен.

Маленькое лирическое отступление. Когда я только начинал писать драйвера (что под винды, что под линукс) я очень быстро понял, что чужой драйвер - справочное средство, а железо бывает на столько разное, что это почти всегда полностью меняет архитектуру драйвера. Именно поэтому я всегда смотрю на драйвера других людей, но пишу свой.

Поэтому мой совет - переписать драйвер и оставить в нем только функцию-обработчик запросов ввода-вывода. Все потоки и пр. убрать. Так будет гораздо понятнее. Да и отладить это драйвер будет проще. Но это только в данном конкретном случае.



Все верно, т.к. операция монтирования применима только к блочным устройствам. А devfs - это немного для другого: http://wiki.linuxquestions.org/wiki/Devfs



MBR - содержит главную загрузочную запись диска и начало таблицы разделов. Т.е. для разных файловых систем он будет одним и тем же, по формату, конечно. А вот содержимое его будет различаться. По крайней мере полями типов файловых систем.



Что подразумевается под объявлением диска?

Если известен объем диска (раздела), то количество цилиндров можно легко вычислить, поскольку общий объем диска равен Nсекторов*Nголовок*Nцилиндров*РазмерСектора. Т.е. для получения числа цилиндров нужно разделить объем на произведение (Nсекторов*Nголовок*РазмерСектора).

Блин, чем дальше, тем ...
На данный момент, мой "кастрат" не выходит из request (или не так выходит). Создал тестик, который открывает файл устройства и читает из него 10 байт и закрывает файл. Для отладки, натыкал в драйвере индикаторов выполнения.
После вызова fread, ядро вызвает xsysace_do_request, выполняет команду READ, после этого система виснет, но не так чтобы совсем замереть, терминалка реагирует на нажатие клавиш.

Насчет MBR, меня смутило то что FAT может сохранять свои параметры прямо в MBR.

Насчет цилиндров, например, если посчитать суммарную емкость флешки из параметров которые показывает WinHex, то она не совпадает с общей на 9000 секторов, хотя FAT занимает 971х2, резервных 34 и скрытых 32 сектора.

Еще, когда мой драйвер грузится, то вываливается сообщение о неизвестной таблице партишинов, это что означает, что я не смогу его смонтировать?

На самом деле - ничего страшного. Все эти проблемы от того, что нет ясности в том, как драйвер должен работать.




Явная проблема xsysace_do_request - нарушена логика его работы. Поясню. Драйвер должен работать следующим образом:
1. Выполняется инициализация и регистрируется блочное устройство. При этом выделяются и резервируются все те аппаратные ресурсы (порты, области памяти, прерывания), которые использует устройство.
2. Рабочий цикл драйвера, в котором он принимает запросы ввода-вывода от различных подсистем ядра (файловая система, интерфейс с пользовательским ПО). При приходе запроса ввода-вывода вызывается зарегистрированная функция-обработчик запросов, которая выполняет передачу данных в запрошенном направлении (READ или WRITE), при этом очередь запросов должна быть обработана полностью. (В этом, кстати, проблема твоего драйвера, но об этом ниже). Обработка запросов может выполняться в отложенном режиме (по таймеру, по прерыванию или иначе), но главное - должна выполняться. Если запрос на ввод-вывод не будет обработан, но подсистема или процесс его сделавший будет "висеть" до тех пор, пока запрос не завершится тем или иным образом. А у тебя этого не происходит, т.к. в функции обработки запросов нет цикла (а должет быть). При этом цикл должен в общем случае выполняться до тех пор, пока есть запросы в очереди (условие ! QUERY_EMPTY).
3. Останов драйвера.



Откуда дровишки? Не имеет FAT права сохранять что-либо в MBR. В Boot Record раздела - пожалуйста, но в MBR - никогда.



Нужно смотреть на то, что показывает fdisk под линуксом. Он не обманет.



Нет, твой драйвер умеет работать с таблицей разделов, просто на карточке ее нет. Т.е. FAT занимает всю карточк монопольно.

Спасибо!
Поправил с учетом последних указаний, вроде как то заработало.

Была у меня флешка (сжег вчера), в которой 0 сектор содержал бутовый сектор FAT, на месте таблицы партишинов было текстовое сообщение загрузчика. От этого всего с этой флешкой упорно не хотела работать библиотека EFLS, а винда ее понимала без проблем.

Это хорошо.
Но я бы все-равно драйвер почистил от всего лишнего.



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

Далее.
1) Когда мой тестик читает из устройства 512 байт, драйвер получает запрос на чтение двух секторов (хотя параметр обмена макс. кол. секторов с драйвером установлен 1 сектор) и возвращаемый приложению буфер имеет содержимое 2 сектора. Думаю это связано с параметром блок/сектор который равен двум секторам на блок.

Я вставил в драйвер функции инициализации и чтения/записи MMC, если не учитывать ошибку №1, то обмен происходит правильно.

2) Пытаюсь монтировать флешку mount /dev/my_mmc /var/mnt:
драйвер читает 2 сектора начиная со 2-го,
ругается что не нашел ext2
драйвер читает 1 сектор начиная со 0-го,
ругается что не нашел FAT UMSDOS
драйвер читает 1 сектор начиная со 0-го,
ругается что не нашел FAT
драйвер читает 1 сектор начиная со 0-го,
ругается что не нашел FAT
драйвер читает 2 сектора начиная со 0-го,
ругается что не нашел ROMFS
Заметил особенность, если монтировать mount -t msdos/dev/my_mmc /var/mnt, как полагается закончится руганью, но если после этого запустить тестовую програму, драйвер будет получать запросы на чтение по 1 сектору (а не по 2, как ранее).

Я полагаю, ошибка №2 связана с тем, что система ищет в этих секторах бутовые записи и обламывается, так как там находится только ссылка на раздел. При загрузке драйвера, он продолдает ругаться на неизвестную таблицу разделов, хотя никих обращений к 0 сектору не происходит.

Уф-ф, монтировал!
1-я ошибка была в моем драйвере.
2-я в содержимом флешки.
Теперь возьмусь за драйвер сетевухи.
Спасибо тебе makc огромное , не первый раз выручаешь, так бы не знаю сколько я провозился.

Понимаю, для меня это тоже была большая радость, когда заработал драйвер.



Да... Это отдельная песня. Тоже в свое время прошел через это.



Не за что. Рад был помочь.