|
Драйвер блочного устройства в Linux |
|
|
|
Oct 26 2005, 04:05
|

Гуру
     
Группа: Админы
Сообщений: 3 621
Регистрация: 18-10-04
Из: Москва
Пользователь №: 904

|
Цитата(3.14 @ Oct 25 2005, 23:28) Отзовитесь плиз, кто писал драйвер блочного устройства под линух. С символьным относительно быстро разобрался, а вто с блочным Примеры в uClinux не особо помогают, пока даже не могу вычленить нужные части. Я писал, причем совсем недавно. А в чем проблема, что не понятно?
--------------------
BR, Makc В недуге рождены, вскормлены тленом, подлежим распаду. (с) У.Фолкнер.
|
|
|
|
|
Oct 26 2005, 15:23
|
Знающий
   
Группа: Свой
Сообщений: 601
Регистрация: 22-09-05
Из: Kharkov
Пользователь №: 8 847

|
Цитата(3.14 @ Oct 25 2005, 23:28) Отзовитесь плиз, кто писал драйвер блочного устройства под линух. С символьным относительно быстро разобрался, а вто с блочным Примеры в uClinux не особо помогают, пока даже не могу вычленить нужные части. Для ядра 2.6 пример есть тут http://lwn.net/Articles/60368/. Можно еще посмотреть в исходниках drivers/block/xd.c
--------------------
- А мораль отсюда такова: всякому овощу свое время. Или, хочешь, я это сформулирую попроще: никогда не думай, что ты иная, чем могла бы быть иначе, чем будучи иной в тех случаях, когда иначе нельзя не быть. © Lewis Carroll. Alice's adventures in wonderland.
|
|
|
|
|
Oct 26 2005, 20:35
|

Их либе дих ...
     
Группа: СуперМодераторы
Сообщений: 2 010
Регистрация: 6-09-04
Из: Russia, Izhevsk
Пользователь №: 609

|
Нижесказанное касается uClinux, ядро 2.4. Начал я с примера "sbull" идущего с книжкой Linux Device Drivers. Модуль скомпилировался, но загружаться отказался с ошибкой Код insmod: unresolved symbol mulsi3_proc insmod: unresolved symbol divsi3_proc Тогда я взял пример по проще (драйвер Xilinx sysace), в результате, ошибка с "mulsi3_proc" все равно появляется. Объявляю init, clean модули и регистрирую драйвер (register_blkdev) - ОК. Объявляю структур block_device_operations структуру - OK Как дохожу до blk_init_queue - ошибка unresolved symbol divsi3_proc
--------------------
Усы, борода и кеды - вот мои документы :)
|
|
|
|
|
Oct 27 2005, 01:35
|
Местный
  
Группа: Свой
Сообщений: 376
Регистрация: 30-06-04
Из: Moskow
Пользователь №: 218

|
Цитата(3.14 @ Oct 26 2005, 23:35) Нижесказанное касается uClinux, ядро 2.4. Начал я с примера "sbull" идущего с книжкой Linux Device Drivers. Модуль скомпилировался, но загружаться отказался с ошибкой Код insmod: unresolved symbol mulsi3_proc insmod: unresolved symbol divsi3_proc Тогда я взял пример по проще (драйвер Xilinx sysace), в результате, ошибка с "mulsi3_proc" все равно появляется. Объявляю init, clean модули и регистрирую драйвер (register_blkdev) - ОК. Объявляю структур block_device_operations структуру - OK Как дохожу до blk_init_queue - ошибка unresolved symbol divsi3_proc  Судя по именам "mulsi3_proc" и "divsi3_proc" это функции выполнения умножения и деления? Может отсюда и копать?
--------------------
serpents on the way to paradise - dying for love, fighting for ages.
|
|
|
|
|
Oct 27 2005, 06:23
|

Гуру
     
Группа: Админы
Сообщений: 3 621
Регистрация: 18-10-04
Из: Москва
Пользователь №: 904

|
Цитата(3.14 @ Oct 26 2005, 23:35) Нижесказанное касается uClinux, ядро 2.4. Начал я с примера "sbull" идущего с книжкой Linux Device Drivers. Модуль скомпилировался, но загружаться отказался с ошибкой Код insmod: unresolved symbol mulsi3_proc insmod: unresolved symbol divsi3_proc Тогда я взял пример по проще (драйвер Xilinx sysace), в результате, ошибка с "mulsi3_proc" все равно появляется. Объявляю init, clean модули и регистрирую драйвер (register_blkdev) - ОК. Объявляю структур block_device_operations структуру - OK Как дохожу до blk_init_queue - ошибка unresolved symbol divsi3_proc  У меня есть подозрение, что это функции библиотеки компилятора для выполнения операций умножения и деления. А если это так, то в ключах линковки обязательно должен быть ключик -lgcc, говорящий об использовании требуемой библиотеки.
--------------------
BR, Makc В недуге рождены, вскормлены тленом, подлежим распаду. (с) У.Фолкнер.
|
|
|
|
|
Oct 28 2005, 09:13
|
Знающий
   
Группа: Свой
Сообщений: 601
Регистрация: 22-09-05
Из: Kharkov
Пользователь №: 8 847

|
Цитата(makc @ Oct 27 2005, 09:23) Цитата(3.14 @ Oct 26 2005, 23:35) Нижесказанное касается uClinux, ядро 2.4. Начал я с примера "sbull" идущего с книжкой Linux Device Drivers. Модуль скомпилировался, но загружаться отказался с ошибкой Код insmod: unresolved symbol mulsi3_proc insmod: unresolved symbol divsi3_proc Тогда я взял пример по проще (драйвер Xilinx sysace), в результате, ошибка с "mulsi3_proc" все равно появляется. Объявляю init, clean модули и регистрирую драйвер (register_blkdev) - ОК. Объявляю структур block_device_operations структуру - OK Как дохожу до blk_init_queue - ошибка unresolved symbol divsi3_proc  У меня есть подозрение, что это функции библиотеки компилятора для выполнения операций умножения и деления. А если это так, то в ключах линковки обязательно должен быть ключик -lgcc, говорящий об использовании требуемой библиотеки. ucLinux не пользовал. Там типа на ядро патчи накладываются? С 2.4 до блочных не дошел, а теперь уже и не надо, так как перешел полностью на 2.6. mulsi3_proc и divsi3_proc - это функции для обработки операций с плавающей точкой. А какой процесссор используется? Он что, без FP модуля? Если да, то нужно обязательно включить в ядре поддержку Floating Point Emulation. Линковать _МОДУЛЬ_ ядра с библиотекой, не важно с какой, вообще бред, потому как ядро должно работать само по себе и _НЕ_ должно зависеть от бибилотек.
--------------------
- А мораль отсюда такова: всякому овощу свое время. Или, хочешь, я это сформулирую попроще: никогда не думай, что ты иная, чем могла бы быть иначе, чем будучи иной в тех случаях, когда иначе нельзя не быть. © Lewis Carroll. Alice's adventures in wonderland.
|
|
|
|
|
Oct 28 2005, 12:03
|
Знающий
   
Группа: Свой
Сообщений: 601
Регистрация: 22-09-05
Из: Kharkov
Пользователь №: 8 847

|
Цитата(makc @ Oct 27 2005, 09:23) У меня есть подозрение, что это функции библиотеки компилятора для выполнения операций умножения и деления. А если это так, то в ключах линковки обязательно должен быть ключик -lgcc, говорящий об использовании требуемой библиотеки. Вообще-то эти функции находятся обычно в libfloat и линковать надо с ключем -lfloat. Но под ucLinux может быть и по другому.
--------------------
- А мораль отсюда такова: всякому овощу свое время. Или, хочешь, я это сформулирую попроще: никогда не думай, что ты иная, чем могла бы быть иначе, чем будучи иной в тех случаях, когда иначе нельзя не быть. © Lewis Carroll. Alice's adventures in wonderland.
|
|
|
|
|
Oct 29 2005, 12:13
|

Их либе дих ...
     
Группа: СуперМодераторы
Сообщений: 2 010
Регистрация: 6-09-04
Из: Russia, Izhevsk
Пользователь №: 609

|
Всем спасибо, с мертвой точки наконец сдвинулся. Как и говорили, дело в 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 так кардинально изменилась идеология написания драйверов?
--------------------
Усы, борода и кеды - вот мои документы :)
|
|
|
|
|
Oct 30 2005, 11:14
|

Их либе дих ...
     
Группа: СуперМодераторы
Сообщений: 2 010
Регистрация: 6-09-04
Из: Russia, Izhevsk
Пользователь №: 609

|
Мне вот еще что не понятно. В примере с символьным драйвером обращение к устройству сводится к вызову функций чтения/записи которые прописаны в структуре 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 передается приложению пользователя
--------------------
Усы, борода и кеды - вот мои документы :)
|
|
|
|
|
Nov 1 2005, 16:33
|
Знающий
   
Группа: Свой
Сообщений: 601
Регистрация: 22-09-05
Из: Kharkov
Пользователь №: 8 847

|
Цитата(3.14 @ Oct 29 2005, 15:13) Всем спасибо, с мертвой точки наконец сдвинулся. Как и говорили, дело в FPU. Когда добавил ключик -mno-xl-soft-mul, ошибка пропала. Хотя не понятно, в других примерах используются ключи -mxl-soft-mul или -DNO_FPU. Никакой информации на эти ключи в доке на компилятор не нашел (mg-gcc). Ага, я тоже когда-то что-то типа этого долго искал, в смысле ключи gcc подбирал. Цитата(3.14 @ Oct 29 2005, 15:13) 2 amw Я ставлю эксперименты на MicroBlaze - синтезируемый процессор (Xilinx) ver3. В четвертой версии появилась поддержка плавающей точки, но у меня ресурсрв FPGA мало (Spartan3-200), вместе со всеми необходимуми корками (RS232,Контр.пр.таймер,SDRAM,Ethernet,GPIO) осталось свободных 2 слайса  Как из Linux делается uClinux не знаю  А разве с ядра 2.6 так кардинально изменилась идеология написания драйверов? В ядрах 2.4 и 2.6 отдичается идеология. Много функций переписаны, в смысле их вызов и действия.
--------------------
- А мораль отсюда такова: всякому овощу свое время. Или, хочешь, я это сформулирую попроще: никогда не думай, что ты иная, чем могла бы быть иначе, чем будучи иной в тех случаях, когда иначе нельзя не быть. © Lewis Carroll. Alice's adventures in wonderland.
|
|
|
|
|
Nov 1 2005, 16:50
|
Знающий
   
Группа: Свой
Сообщений: 601
Регистрация: 22-09-05
Из: Kharkov
Пользователь №: 8 847

|
Цитата(3.14 @ Oct 30 2005, 14: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 передается приложению пользователя  С блочными все по другому (по сравнению с символьными). Во первых на блочные устройсва имеется кеш в ядре, и функция сброса очереди (в данном случае это static void xsysace_do_request(request_queue_t * q)) вызывается менеджером кеша для записи данных на устройство. Во вторых, блочное устройство, это как-бы не совсем самостоятельное устроство, вернее - не самодостаточное. Например, когда пользовательский процесс вызывает функции fopen(), fread(), fwrite(), то тут участвует в первую очередь файловая система (в терминах ядра - VFS), через нее (VFS) все и роисходит. Если обратится на прямую, например Код dd if=/dev/hda of=example.file bs=512 count=1 то запрос на чтение сектора пройдет мимо VFS (условно говоря, потому как VFS участвует во всех оперциях с устройсвами) но через кеш. Ядро будет читать не один сектор, а несколько (количество зависит от аппаратуры, менеджера памяти и параметров очереди request_queue_t). Один сектор попадет пользовательскому процессу, а остальные дальше кеша не пойдут.
--------------------
- А мораль отсюда такова: всякому овощу свое время. Или, хочешь, я это сформулирую попроще: никогда не думай, что ты иная, чем могла бы быть иначе, чем будучи иной в тех случаях, когда иначе нельзя не быть. © Lewis Carroll. Alice's adventures in wonderland.
|
|
|
|
|
Nov 1 2005, 17:01
|
Знающий
   
Группа: Свой
Сообщений: 601
Регистрация: 22-09-05
Из: Kharkov
Пользователь №: 8 847

|
В ядрах 2.6 есть еще так называемые шедулеры ввода/вывода которые занимаются планированием очереди, предсказанием номеров секторов, которые могут потребоватся в следующей оперции чтения/записи и много другого. Как в 2.4 с этим - я не знаю, но стоит посмотреть есть ли в исходниках ядра файл с именем elevator.c (ну или похожим). Если есть, то стоит его изучить, хотя это занятие неблагодарное. После изучения этого файла (и сопутствующих ему) появится понимание (а может наоборот - пропадет вовсе  ), но использовать это понимание на практике будет затруднительно. Драйвер блочного устройства знает как выполнять чтение/запись секторов, но не знает когда это происходит.
--------------------
- А мораль отсюда такова: всякому овощу свое время. Или, хочешь, я это сформулирую попроще: никогда не думай, что ты иная, чем могла бы быть иначе, чем будучи иной в тех случаях, когда иначе нельзя не быть. © Lewis Carroll. Alice's adventures in wonderland.
|
|
|
|
|
Nov 1 2005, 17:21
|

Гуру
     
Группа: Админы
Сообщений: 3 621
Регистрация: 18-10-04
Из: Москва
Пользователь №: 904

|
Цитата(amw @ Nov 1 2005, 20:01) В ядрах 2.6 есть еще так называемые шедулеры ввода/вывода которые занимаются планированием очереди, предсказанием номеров секторов, которые могут потребоватся в следующей оперции чтения/записи и много другого. Как в 2.4 с этим - я не знаю, но стоит посмотреть есть ли в исходниках ядра файл с именем elevator.c (ну или похожим). В 2.4 элеватор и все, что с ним связано тоже есть. Немного не в том виде, что в 2.6, но есть. Цитата Если есть, то стоит его изучить, хотя это занятие неблагодарное. После изучения этого файла (и сопутствующих ему) появится понимание (а может наоборот - пропадет вовсе  ), но использовать это понимание на практике будет затруднительно. Изучать его особенного интереса нет, если только нет цели реализовать пакетный режим обработки запросов ввода-вывода. У меня однажды была такая задача - устройство быстро работало если с ним общаться большими наборами последовательных блоков, а на единичных запросах все очень сильно тормозило. В 2.4 элеватор отлично справлялся с запрошенной группировкой запросов, а вот для 2.2 мне пришлось писать свое подобие элеватора и очереди запросов ввода-вывода. Цитата Драйвер блочного устройства знает как выполнять чтение/запись секторов, но не знает когда это происходит. Когда именно - не знает, но у него есть возможность поддерживать свою очередь запросов на ввод-вывод. Это дает большую свободу.
--------------------
BR, Makc В недуге рождены, вскормлены тленом, подлежим распаду. (с) У.Фолкнер.
|
|
|
|
|
Nov 2 2005, 14:13
|
Знающий
   
Группа: Свой
Сообщений: 601
Регистрация: 22-09-05
Из: Kharkov
Пользователь №: 8 847

|
Цитата(makc @ Nov 1 2005, 20:21) Цитата Драйвер блочного устройства знает как выполнять чтение/запись секторов, но не знает когда это происходит. Когда именно - не знает, но у него есть возможность поддерживать свою очередь запросов на ввод-вывод. Это дает большую свободу. А можна с этого места чуть подробнее. Я не особо крутой спец по блочным устройствам, а сейчас как раз занимаюсь повышением поизводительности блочного драйвера. Я не претендую на полное изложение здесь, но может какая нибудь ссылка поконкретнее есть? А то ковыряюсь по исходникам в изучении этой самой очереди - времени уходит прорва, а результат мизерный.
--------------------
- А мораль отсюда такова: всякому овощу свое время. Или, хочешь, я это сформулирую попроще: никогда не думай, что ты иная, чем могла бы быть иначе, чем будучи иной в тех случаях, когда иначе нельзя не быть. © Lewis Carroll. Alice's adventures in wonderland.
|
|
|
|
|
Nov 2 2005, 16:37
|

Гуру
     
Группа: Админы
Сообщений: 3 621
Регистрация: 18-10-04
Из: Москва
Пользователь №: 904

|
Цитата(amw @ Nov 2 2005, 17:13) А можна с этого места чуть подробнее. Можно.  Цитата Я не особо крутой спец по блочным устройствам, а сейчас как раз занимаюсь повышением поизводительности блочного драйвера. Я не претендую на полное изложение здесь, но может какая нибудь ссылка поконкретнее есть? Книга 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, который нужно захватывать во избежание нарушения структуры системной очереди.
--------------------
BR, Makc В недуге рождены, вскормлены тленом, подлежим распаду. (с) У.Фолкнер.
|
|
|
|
|
Nov 3 2005, 09:47
|
Знающий
   
Группа: Свой
Сообщений: 601
Регистрация: 22-09-05
Из: Kharkov
Пользователь №: 8 847

|
Цитата(makc @ Nov 2 2005, 19:37) Книга Linux Device Drivers 2nd edition, CH12, P. Handling Requests: The Detailed View. Есть такая, и даже 3-е издание, но появилась недавно, пока читаю. Цитата Что касается "ручного" создания своей очереди, то это довольно просто. 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. Все повторяется заново, пока в системной очереди есть запросы. Ага! Поковыряюсь, а то по исходикам не совсем понятно была последовательность действий. В ядрах с 2.6.12 (помоему) есть такая полезная функция: blk_queue_ordered(queue, QUEUE_ORDERED_FLUSH); Вызывать при инициализации очереди. Цитата Только не забудьте про глобальный спинлок io_request_lock, который нужно захватывать во избежание нарушения структуры системной очереди. Спасибо!
--------------------
- А мораль отсюда такова: всякому овощу свое время. Или, хочешь, я это сформулирую попроще: никогда не думай, что ты иная, чем могла бы быть иначе, чем будучи иной в тех случаях, когда иначе нельзя не быть. © Lewis Carroll. Alice's adventures in wonderland.
|
|
|
|
|
Nov 4 2005, 16:01
|

Их либе дих ...
     
Группа: СуперМодераторы
Сообщений: 2 010
Регистрация: 6-09-04
Из: Russia, Izhevsk
Пользователь №: 609

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

Гуру
     
Группа: Админы
Сообщений: 3 621
Регистрация: 18-10-04
Из: Москва
Пользователь №: 904

|
Цитата(3.14 @ Nov 4 2005, 00:48) А если я сделаю так: в фунции xsysace_do_request вместо объявления функций обмена, провожу чтение/запись данных и перед выходом вызываю xsa_complete_request(1). Интересно, как себя при этом поведет xsa_thread? По логике такого драйвера xsa_thread вообще не нужен.
--------------------
BR, Makc В недуге рождены, вскормлены тленом, подлежим распаду. (с) У.Фолкнер.
|
|
|
|
|
Nov 4 2005, 20:28
|

Гуру
     
Группа: Админы
Сообщений: 3 621
Регистрация: 18-10-04
Из: Москва
Пользователь №: 904

|
Цитата(3.14 @ Nov 4 2005, 19:01) В общем, как то кастрировал этот драйвер, правда манипуляции с очередями я как то слабо понял, взгляните плиз на прикрепленный файл, может чего заметите. Маленькое лирическое отступление. Когда я только начинал писать драйвера (что под винды, что под линукс) я очень быстро понял, что чужой драйвер - справочное средство, а железо бывает на столько разное, что это почти всегда полностью меняет архитектуру драйвера. Именно поэтому я всегда смотрю на драйвера других людей, но пишу свой.  Поэтому мой совет - переписать драйвер и оставить в нем только функцию-обработчик запросов ввода-вывода. Все потоки и пр. убрать. Так будет гораздо понятнее. Да и отладить это драйвер будет проще. Но это только в данном конкретном случае. Цитата Не понятно: 1) В доке сказано, что файловая система может находиться только на блочных устройствах, дык зачем тогда регистрировать устройство как devfs? Все верно, т.к. операция монтирования применима только к блочным устройствам. А devfs - это немного для другого: http://wiki.linuxquestions.org/wiki/DevfsЦитата 2) MBR сектор для разных файловых систем разный? MBR - содержит главную загрузочную запись диска и начало таблицы разделов. Т.е. для разных файловых систем он будет одним и тем же, по формату, конечно. А вот содержимое его будет различаться. По крайней мере полями типов файловых систем. Цитата 2) При объявлении диска нужно указать количество головок, секторов и цилиндров. В MBR секторе флешки есть значения количества головок и секторов, а как определить количество цилиндров? Что подразумевается под объявлением диска? Если известен объем диска (раздела), то количество цилиндров можно легко вычислить, поскольку общий объем диска равен Nсекторов*Nголовок*Nцилиндров*РазмерСектора. Т.е. для получения числа цилиндров нужно разделить объем на произведение (Nсекторов*Nголовок*РазмерСектора).
--------------------
BR, Makc В недуге рождены, вскормлены тленом, подлежим распаду. (с) У.Фолкнер.
|
|
|
|
|
Nov 5 2005, 14:42
|

Их либе дих ...
     
Группа: СуперМодераторы
Сообщений: 2 010
Регистрация: 6-09-04
Из: Russia, Izhevsk
Пользователь №: 609

|
Блин, чем дальше, тем ... На данный момент, мой "кастрат" не выходит из request (или не так выходит). Создал тестик, который открывает файл устройства и читает из него 10 байт и закрывает файл. Для отладки, натыкал в драйвере индикаторов выполнения. После вызова fread, ядро вызвает xsysace_do_request, выполняет команду READ, после этого система виснет, но не так чтобы совсем замереть, терминалка реагирует на нажатие клавиш. Насчет MBR, меня смутило то что FAT может сохранять свои параметры прямо в MBR. Насчет цилиндров, например, если посчитать суммарную емкость флешки из параметров которые показывает WinHex, то она не совпадает с общей на 9000 секторов, хотя FAT занимает 971х2, резервных 34 и скрытых 32 сектора. Еще, когда мой драйвер грузится, то вываливается сообщение о неизвестной таблице партишинов, это что означает, что я не смогу его смонтировать?
--------------------
Усы, борода и кеды - вот мои документы :)
|
|
|
|
|
Nov 5 2005, 17:18
|

Гуру
     
Группа: Админы
Сообщений: 3 621
Регистрация: 18-10-04
Из: Москва
Пользователь №: 904

|
Цитата(3.14 @ Nov 5 2005, 17:42) Блин, чем дальше, тем ... На самом деле - ничего страшного. Все эти проблемы от того, что нет ясности в том, как драйвер должен работать. Цитата На данный момент, мой "кастрат" не выходит из request (или не так выходит). Создал тестик, который открывает файл устройства и читает из него 10 байт и закрывает файл. Для отладки, натыкал в драйвере индикаторов выполнения. После вызова fread, ядро вызвает xsysace_do_request, выполняет команду READ, после этого система виснет, но не так чтобы совсем замереть, терминалка реагирует на нажатие клавиш.  Явная проблема xsysace_do_request - нарушена логика его работы. Поясню. Драйвер должен работать следующим образом: 1. Выполняется инициализация и регистрируется блочное устройство. При этом выделяются и резервируются все те аппаратные ресурсы (порты, области памяти, прерывания), которые использует устройство. 2. Рабочий цикл драйвера, в котором он принимает запросы ввода-вывода от различных подсистем ядра (файловая система, интерфейс с пользовательским ПО). При приходе запроса ввода-вывода вызывается зарегистрированная функция-обработчик запросов, которая выполняет передачу данных в запрошенном направлении (READ или WRITE), при этом очередь запросов должна быть обработана полностью. (В этом, кстати, проблема твоего драйвера, но об этом ниже). Обработка запросов может выполняться в отложенном режиме (по таймеру, по прерыванию или иначе), но главное - должна выполняться. Если запрос на ввод-вывод не будет обработан, но подсистема или процесс его сделавший будет "висеть" до тех пор, пока запрос не завершится тем или иным образом. А у тебя этого не происходит, т.к. в функции обработки запросов нет цикла (а должет быть). При этом цикл должен в общем случае выполняться до тех пор, пока есть запросы в очереди (условие ! QUERY_EMPTY). 3. Останов драйвера. Цитата Насчет MBR, меня смутило то что FAT может сохранять свои параметры прямо в MBR. Откуда дровишки?  Не имеет FAT права сохранять что-либо в MBR. В Boot Record раздела - пожалуйста, но в MBR - никогда. Цитата Насчет цилиндров, например, если посчитать суммарную емкость флешки из параметров которые показывает WinHex, то она не совпадает с общей на 9000 секторов, хотя FAT занимает 971х2, резервных 34 и скрытых 32 сектора. Нужно смотреть на то, что показывает fdisk под линуксом. Он не обманет. Цитата Еще, когда мой драйвер грузится, то вываливается сообщение о неизвестной таблице партишинов, это что означает, что я не смогу его смонтировать? Нет, твой драйвер умеет работать с таблицей разделов, просто на карточке ее нет. Т.е. FAT занимает всю карточк монопольно.
--------------------
BR, Makc В недуге рождены, вскормлены тленом, подлежим распаду. (с) У.Фолкнер.
|
|
|
|
|
Nov 5 2005, 18:35
|

Их либе дих ...
     
Группа: СуперМодераторы
Сообщений: 2 010
Регистрация: 6-09-04
Из: Russia, Izhevsk
Пользователь №: 609

|
Спасибо! Поправил с учетом последних указаний, вроде как то заработало. Цитата Откуда дровишки? Не имеет FAT права сохранять что-либо в MBR. В Boot Record раздела - пожалуйста, но в MBR - никогда. Была у меня флешка (сжег вчера), в которой 0 сектор содержал бутовый сектор FAT, на месте таблицы партишинов было текстовое сообщение загрузчика. От этого всего с этой флешкой упорно не хотела работать библиотека EFLS, а винда ее понимала без проблем.
--------------------
Усы, борода и кеды - вот мои документы :)
|
|
|
|
|
Nov 5 2005, 19:18
|

Гуру
     
Группа: Админы
Сообщений: 3 621
Регистрация: 18-10-04
Из: Москва
Пользователь №: 904

|
Цитата(3.14 @ Nov 5 2005, 21:35) Спасибо! Поправил с учетом последних указаний, вроде как то заработало. Это хорошо. Но я бы все-равно драйвер почистил от всего лишнего. Цитата Цитата Откуда дровишки? Не имеет FAT права сохранять что-либо в MBR. В Boot Record раздела - пожалуйста, но в MBR - никогда. Была у меня флешка (сжег вчера), в которой 0 сектор содержал бутовый сектор FAT, на месте таблицы партишинов было текстовое сообщение загрузчика. От этого всего с этой флешкой упорно не хотела работать библиотека EFLS, а винда ее понимала без проблем. Тогда скорее всего эта карточка была отформатирована в WindowsXP, которая таблицы разделов не создает. А вот EFLS хотела все-таки получить таблицу разделов и потому не работала. Это наиболее вероятная версия.
--------------------
BR, Makc В недуге рождены, вскормлены тленом, подлежим распаду. (с) У.Фолкнер.
|
|
|
|
|
Nov 5 2005, 21:52
|

Их либе дих ...
     
Группа: СуперМодераторы
Сообщений: 2 010
Регистрация: 6-09-04
Из: Russia, Izhevsk
Пользователь №: 609

|
Далее. 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 сектору не происходит.
--------------------
Усы, борода и кеды - вот мои документы :)
|
|
|
|
|
Nov 6 2005, 15:56
|

Их либе дих ...
     
Группа: СуперМодераторы
Сообщений: 2 010
Регистрация: 6-09-04
Из: Russia, Izhevsk
Пользователь №: 609

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

Гуру
     
Группа: Админы
Сообщений: 3 621
Регистрация: 18-10-04
Из: Москва
Пользователь №: 904

|
Цитата(3.14 @ Nov 6 2005, 18:56)  Уф-ф, монтировал! 1-я ошибка была в моем драйвере. 2-я в содержимом флешки. Понимаю, для меня это тоже была большая радость, когда заработал драйвер.  Цитата Теперь возьмусь за драйвер сетевухи. Да... Это отдельная песня. Тоже в свое время прошел через это.  Цитата Спасибо тебе makc огромное  , не первый раз выручаешь, так бы не знаю сколько я провозился. Не за что. Рад был помочь.
--------------------
BR, Makc В недуге рождены, вскормлены тленом, подлежим распаду. (с) У.Фолкнер.
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|