Нужно портировать драйвер для платы с Win2k на Linux.
Столкнулся с тем, что не найду - а это возможно, float point в драйвере Linux?
В Win2k были макросы - сохранить контекст/загрузить контекст FPU.
А как быть в Linux?
Переосмысливать архитектуру системы или организовывать программно?
Поверхносный поиск ничего не дал - как будто нельзя FPU...

Попутно, может кто подскажет хорошие форумы по Linux драйверам?

FreeBSD5: /usr/src/sys/i386/i386/support.s -> i586_bzeroНажмите для просмотра прикрепленного файла

Сам термин "портировать драйвер с Win2k на Linux" и намерение - это безумие - всё совсем по другому...



Есть такая брошюрка (112 стр.): Померанц О. "Ядро Linux. Программирование модулей": пер. с англ. - М.: "КУДИЦ-ОБРАЗ", 2000 - для общей "системы взглядов" относительно драйверов Linux - очень неплохо.

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

В догонку: посмотри вот это.

А эта брошурка в эл. виде существует где?
А то в наших магазинах её не видел...

Почему?:
- уникальный код - это только небольшая часть;
- вы нигде не указали, что за девайс, но даже если простейший символьный, то вам, наверное, нужно к нему создать интерфнйс /dev/zzz ... и обеспечить к нему fd = open( "/dev/zzz", ... ) и read() - write() для этого fd...
- ... а если устройство ещё чуть помудрёнее - то и интерфейс к нему /proc/zzz приделать, и API ioctl() - devctl().
Вот только тогда это будет - драйвер.



1. Эта - не знаю , но вот есть другая "брошюрка"
http://ad.adriver.ru/cgi-bin/erle.cgi?sid=...?rnd=1126239260 :
"The Linux Kernel Module Programming Guide"
Авторы: Peter Jay Salzman, Michael Burian, Ori Pomerantz
Copyright 2001, Peter Jay Salzman.
2004-05-16 ver 2.6.0
Перевод: Андрей Киселёв.

2. Но и "первоначальную" - найдите, любопытная... Ведь кроме магазинов есть друзья-приятели, ... библиотека, в конце-концов .

P.S. Вот ещё книга - думал уже потерял uRL:
http://www.xml.com/ldd/chapter/book/bookindexpdf.html
Linux Device Drivers, 2nd Edition
By Alessandro Rubini & Jonathan Corbet
2nd Edition June 2001
0-59600-008-1, Order Number: 0081
586 pages, $39.95

Правильно ли я понял - если хочу float-point в драйвере, то
придётся самому разбиратся в сопроцессором и лепить ф-и сохранения/востановления его контекста, по аналогии с
KeSaveFloatingPointState/KeRestoreFloatingPointState из DDK MS?

Нельзя там в ядре floating point
http://www.ussg.iu.edu/hypermail/linux/ker...107.0/0757.html

Нужно всю float point часть перенести на уровень приложения, которое к примеру все время будет весеть на драйвере с помощью select(). Т.е. оперативно реагировать на любые изм. в статусе железа, чего-то там считать и отдавать обратно железу.
Или (если FP нужна в обработчике, к примеру, прерывания, или там для моментальной генерации управляющего воздействия во внешнюю среду) то можно нагородить эмуляцию на целых числах, которая возможно даже окажется быстрее (осбенно если заменить всякие синусы таблицами)
Это будет проще чем заморачиваться с FPU.

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

Если уж на то пошло, то лучше сразу взять 3-ье издание... Ибо про 2.6, и многие на него уже перешли окончательно... Темболее там немного поменялось API, и если уж учить так сразу новое.
http://lwn.net/Kernel/LDD3/

Эта брошурка (LKMPG) в каком виде только не существует... Только ИМХО старовата....
http://www.opennet.ru/docs/RUS/lkmpg/
http://oopweb.com/OS/Documents/LKMPG/Volum...ume/node11.html

Вопрос в тему уважаемому QNX-гуру Olej: в QNX, если я ничего не путаю, в user-space приложение можно вставить все что душе угодно: обработчик прерывания, работу с портами ввода/вывода. Соответственно если воткнуть работу с сопроцессором прямо в прерывание что произойдет? т.е. она сохраняет контекст FPU перед входом в прерывание?
Это я к тому, что может человеку проще QNX взять....

Что касается драйвера - это драйве PCI платы, висит на прерывании. По прерыванию нужно опросить плату, кой чего посчитать с использованием FPU и выдать результат дбратно в PCI.
Желаемая задержка обработки прерывания- порядка 5-15 mc (очень редкие затяжки обработки на время большее 15мс не критичны).

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

Можно вставить "почти всё" , но сознательно дав приложению право такое делать: ThreadCtl() - после чего ответственность за последствия приложение берёт на себя. В QNX есть 2 разных техники работы с прерываниями:
- InterruptAttach() - это, собственно, классическкая схема ISR (подобная в других ОС: с нижней-верхней частью...), и выполняется ISR а контексте микроядра, что, понятно, опасно...
- InterruptAttachEvent() - более дружественный способ, когда по IRQ будет только возбуждено зарегистрированное событие, а оно уже может вызвать передиспетчеризацию user-space потоков. И вот тогда, естественно уже можно пользовать FPU и всё-всё-всё режима юзера...

Это по своей идее - сильно близко к тому, что предлагалось здесь уже об использовании select() ... Поэтому всё то же можно сделать и в Linux, особенно учитывая описанную позже логику устройства, и уж совсем не жёсткие требования на время реакции (5-15 mc - это весьма много ). Что-то типа:
- сделать в пользовательском приложении поток обработчика (FPU + отправка ответа), с SCHED_RR или SCHED_FIFO (т.е. сразу поставить его в приоритетный режим), который только ожидал бы для насчала своих операций ... например, сигнала SIGRTMIN...
- по IRQ ISR только опрашивал бы устройство, приводил бы всё в порядок с IRQ ... и возбуждал бы SIGRTMIN для активации потока ответа.
Что-то такое...



Вряд ли, ... в виду стоимости QNX для любых коммерческих проектов, да и динамика в Linux/*BSD настолько высокая, что всё меньше "ниши" где мог бы управиться "только QNX" ...

В общем вырисовывается 2 варианта:
1) софтово эмулировать - благо библиотеки вроде есть. (В моём случае - хороший вариант - расчётов не очень много).
2) Организовать передачу расчётов на пользовательский уровень ожидающему потоку, скажем сообщением.

Но всё-же, для полной картины. Я так и не понял, если я сделаю сохранение/востановления контекста FPU на уровне ядра (MMX юзать изначально не буду, а то его контекст не сохраняется), а на это время запрещаю прерывания, что-б не меня не прервали (не более нескольких мкс) - это будет работать?

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

Почему не стоит, если запретить прерывания на 5-10 мкс, по моему в обычном Linux (не RT), этого никто и не заметит.

Builder

Надо ещё окружать операции с fp при помощи kernel_fpu_begin() и kernel_fpu_end()
(/Documentation/preempt-locking.txt)