[Builder 0]

Нужно портировать драйвер для платы с Win2k на Linux.

Столкнулся с тем, что не найду - а это возможно, float point в драйвере Linux?

В Win2k были макросы - сохранить контекст/загрузить контекст FPU.

А как быть в Linux?

Переосмысливать архитектуру системы или организовывать программно?

Поверхносный поиск ничего не дал - как будто нельзя FPU...

 

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

[AA55 0]

FreeBSD5: /usr/src/sys/i386/i386/support.s -> i586_bzerosupport.s.txt

[Olej 0]

Нужно портировать драйвер для платы с Win2k на Linux.

<{POST_SNAPBACK}>

 

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

 

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

<{POST_SNAPBACK}>

 

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

[Builder 0]

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

[AA55 0]

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

[Builder 0]

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

А то в наших магазинах её не видел...

[Olej 0]

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

<{POST_SNAPBACK}>

 

Почему?:

- уникальный код - это только небольшая часть;

- вы нигде не указали, что за девайс, но даже если простейший символьный, то вам, наверное, нужно к нему создать интерфнйс /dev/zzz ... и обеспечить к нему fd = open( "/dev/zzz", ... ) и read() - write() для этого fd...

- ... а если устройство ещё чуть помудрёнее - то и интерфейс к нему /proc/zzz приделать, и API ioctl() - devctl().

Вот только тогда это будет - драйвер.

 

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

А то в наших магазинах её не видел...

<{POST_SNAPBACK}>

 

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

[Builder 0]

Правильно ли я понял - если хочу float-point в драйвере, то

придётся самому разбиратся в сопроцессором и лепить ф-и сохранения/востановления его контекста, по аналогии с

KeSaveFloatingPointState/KeRestoreFloatingPointState из DDK MS?

[Dizel 0]

Нельзя там в ядре floating point

http://www.ussg.iu.edu/hypermail/linux/ker...107.0/0757.html

 

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

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

Это будет проще чем заморачиваться с FPU.

 

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

 

 

 

 

Нужно портировать драйвер для платы с Win2k на Linux.

Столкнулся с тем, что не найду - а это возможно, float point в драйвере Linux?

В Win2k были макросы - сохранить контекст/загрузить контекст FPU.

А как быть в Linux?

Переосмысливать архитектуру системы или организовывать программно?

Поверхносный поиск ничего не дал - как будто нельзя FPU...

 

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

<{POST_SNAPBACK}>

[Dizel 0]

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

http://lwn.net/Kernel/LDD3/

 

 

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

<{POST_SNAPBACK}>

[Dizel 0]

Эта брошурка (LKMPG) в каком виде только не существует... Только ИМХО старовата....

http://www.opennet.ru/docs/RUS/lkmpg/

http://oopweb.com/OS/Documents/LKMPG/Volum...ume/node11.html

 

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

А то в наших магазинах её не видел...

<{POST_SNAPBACK}>

[Dizel 0]

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

Это я к тому, что может человеку проще QNX взять....

 

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

[Builder 0]

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

Желаемая задержка обработки прерывания- порядка 5-15 mc (очень редкие затяжки обработки на время большее 15мс не критичны).

[Dizel 0]

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

 

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

Желаемая задержка обработки прерывания- порядка 5-15 mc (очень редкие затяжки обработки на время большее 15мс не критичны).

<{POST_SNAPBACK}>

[Olej 0]

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

<{POST_SNAPBACK}>

 

Можно вставить "почти всё" ;), но сознательно дав приложению право такое делать: 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 взять....

<{POST_SNAPBACK}>

 

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