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



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

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