Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Сб окт 20, 2018 4:48 pm

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 947 сообщений ]  На страницу Пред. 13 4 5 6 764 След.
Автор Сообщение
 Заголовок сообщения:
СообщениеДобавлено: Вт апр 11, 2006 7:08 pm 
Не в сети

Зарегистрирован: Пт ноя 12, 2004 3:20 pm
Сообщения: 90
Serge
Такой вариант годится для внутриядерного применения. Т.е., обработчик прерывания устанавливается в режиме ядра.
Позволять пользовательским программам работать с IRQ во-первых небезопасно, а во-вторых - практически невозможно с имеющейся моделью памяти.

Работа с IRQ из приложений в МеОС/Колибри осуществляется следующим образом:
1) резервируется IRQ, при этом ядру передается массив номеров портов, из которых нужно считать данные
2) в маске событий устанавливается соответствующий бит (16+номер IRQ)
3) Возникает IRQ, системный обработчик считывает заданные порты.
Для программы-владельца устанавливается событие.
4) Программа получает событие 16+#IRQ. какой-то системной функцией получает содержимое прочитанных портов.

Большая задержка связана с тем, что процессы в МеОС и Колибри построены в одну бесприоритетную очередь. Каждый из них может потреблять до 0,1 секунды. Таким образом, при полной загрузке задержка составит около 2,5 с.

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


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Вт апр 11, 2006 7:57 pm 
VaStaNi
Протестировал, отчет выслал.


Вернуться к началу
   
 Заголовок сообщения:
СообщениеДобавлено: Вт апр 11, 2006 8:36 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3952
Иван Поддубный

Проблема в том, что порты нужно записывать. А когда речь идет о PCI устройствах, то необходимо обработать прерывание до того как контроллеру прерываний будет послана команда EOI, если этого не сделать то мы сразу получим новое прерывание и система просто не сможет нормально работать.

Цитата:
Вообще, идея обработки прерываний в отдельной задаче, которая к тому же находится в своем адресном пространстве, мне кажется совсем непродуманной.


Подобная модель реализована в QNX и вполне нормально работает. Можно специально создать 16 сегментов TSS по одному на каждое прерывание IRQ. Драйвер запускается как обычная программа и устанавливает обработчик прерываний вызывая системную функцию InterruptAttach(IrqLevel, handler_proc). Когда происходит прерывание системный обработчик настраивает соответствующий TSS, записывает handler_proc в TSS.eip, pageDir в TSS.cr3 и переключает задачу вызовом call pword [irq_task]. Когда отработают все обработчики в списке система посылает контроллеру EOI.
Такая схема позволяет загружать и выгружать драйверы как обычные программы и обрабатывать прерывания в адресном пространстве драйвера. Как недостаток дополнительные затраты на инициализацию TSS и вызов задачи.

В любом случае будет ли драйвер грузиться в адресное пр-во ядра как в NT или нет, нужна какая то
приемлимая модель драйверов.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Вт апр 11, 2006 10:19 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Чт май 19, 2005 4:43 pm
Сообщения: 896
[/offtop] VaStaNi,а до тебя мое письмо с тестами AC'97 дощло ?
[\offtop]

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

А я - обычный программист,который понимает в общем виде структуру ядра,но не более того.Думаю я не один такой программист.

ПОЖАЛУЙСТА,продумайте модель драйверов,ато народ уже замучился её поднимать(покачто результат был нулевой).Надеюсь на этот раз народ будет по активнее,а результат ненулевой.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Ср апр 12, 2006 1:07 pm 
Не в сети
Just Flooding
Аватара пользователя

Зарегистрирован: Ср май 18, 2005 10:27 am
Сообщения: 430
Спасибо всем откликнувшимся! Всем отписал ответы.
Теперь по поводу прерываний. На мой взгляд, надо двигаться как полководец к победе, последовательно и приоритетно, если уж начинать дело.
А зачит:
- однозначное понимание проблемы и необходимости решать, менять;
- глобально качественно менять и браться за глобальные перемены, это занчит, базироваться на серьезных знаниях, либо опыте или и то и другое, поэтому надо подходить реально к "кадровому" вопросу и реально-достижимой цели. Вывод- цель рихтуется под кадры и реальные сроки, эффект;
- во избежание простоя, застоя, упадка и т.п. надо НАЧИНАТЬ менять закладывая новые основы и принципы, которые Виллис СОЗНАТЕЛЬНО ИЗБЕГАЛ и ОБХОДИЛ СУРРОГАТНЫМИ МЕТОДАМИ, надо идти "в лобовую атаку";
- изложенный мною выше(а именно пропись в IDT фиксированных векторов обработчиков, закрепленных за одним единственным железом и отдача драйвером ядру нового сервиса железа(функции), а не пользовательского доступа к портам и прерываниям) прост, эффективен, понятен, даже гибок, т.к. система может иметь 5 вариантов обработчика, например, а перебрав их на предмет реального тест-ответа железки, оставить в работе именно правильно ответивший адрес обработчика...;
- работы глобального драйверного направления, выработки модели, не противоречат данной концепции, а лишь будут подкреплены и базироваться на оных, как принципиально так и результативно, т.к. НЕ делая ВООБЩЕ никакого драйвера ИМЕННО, как драйвера, а не приложения(и ему подобная реализация, принцип) ничего вообще не получишь и не продвинешься + откатка массы Vendor`озависимости и нюансы овладения ЛЮБОЙ железяки сильно расходуют и время и силы и здоровье если хотите. Наскоком эти дела вообще не двигаются, даже всем миром, поверьте! Только скурпулёзный труд, опыты и пробы, кучи висяков, чтение до опупения фирменных мануалов железок...
Ребята, проанализируйте хотя бы кадрово-профессиональный вопрос своих рядов, что, кем и как реально, а что нет.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Ср апр 12, 2006 3:27 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3952
VaStaNi

Вот только не надо ничего заране фиксировать и резервировать. Ядро не обязано знать какая железка какое прерывание использует. Это не его забота. Разные железки могут использовать одно прерывание. Это особенно характерно для PCI устройств.
Драйвер просто определяет присутствие "родного" устройства через вызовы PCI.
Считывает номер IRQ из конфигурационного пр-ва PCI и устанавливет на этот номер свой обработчик, используя системный сервис. Все, что требуется от ядра системы -
это дать драйверу такую возможность и обеспечить передачу управления при прерывании.
Не важно работает ли драйвер, как отдельная программа в стиле QNX или грузится в адресное пр-во ядра в стиле NT kernel-mode drivers, важно чтобы драйвер можно было загрузить и при необходимости выгрузить.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Ср апр 12, 2006 6:18 pm 
Не в сети

Зарегистрирован: Сб янв 07, 2006 4:07 am
Сообщения: 47
Цитата:
Не важно работает ли драйвер, как отдельная программа в стиле QNX или грузится в адресное пр-во ядра в стиле NT kernel-mode drivers, важно чтобы драйвер можно было загрузить и при необходимости выгрузить

А я собирался драйвер звуковой карты прикручивать к разрабатываемой подсистеме в виде отдельной программы. В драйвере будет область с фиксированной структурой, где будут характеристики звуковухи и необходимые для звуковой подсистемы ссылки. После запуска будет происходить поиск железки, после чего будет обращение к 55 функции (подсистеме). Например:
mov eax,55
mov ebx,3
int 0x40
А дальше звуковая подсистема сама будет обращаться к вложенным в драйвер процедурам используя ссылки, которые находятся в области описывающую железку. По сути, драйвер будет состоять из: заголовка, описания, ссылок, основного цикла процесса и набора процедур. А можно сделать и многофункциональный драйвер, который, будучи запущенным как обычное приложение, выводил бы окно, где можно настроить железку.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Ср апр 12, 2006 6:28 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3952
А как будут передаваться данные между программой и драйвером, если они в разных адресных пространствах?


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Ср апр 12, 2006 6:41 pm 
Не в сети

Зарегистрирован: Пт ноя 12, 2004 3:20 pm
Сообщения: 90
Сделать поддержку драйверов-программ 3его кольца:
а) сложно - нужно добавить в ядро довольно много кода
б) крайне неэффективно по скорости; мне даже страшно представить, что N раз в секунду будет происходить переключение задач со сменой адресного пространства...

А вот сделать установку обработчиков внутри ядра как предлагает Serge - имхо проще пареной репы.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Ср апр 12, 2006 7:07 pm 
Не в сети
Just Flooding
Аватара пользователя

Зарегистрирован: Ср май 18, 2005 10:27 am
Сообщения: 430
Serge писал(а):
VaStaNi
Вот только не надо ничего заране фиксировать и резервировать. Ядро не обязано знать какая железка какое прерывание использует.

А я разве сказал, что заранее резервировать?
Как раз и предполагается, что после того как:
Serge писал(а):
Драйвер просто определяет присутствие "родного" устройства через вызовы PCI.
Считывает номер IRQ из конфигурационного пр-ва PCI и устанавливет на этот номер свой обработчик, используя системный сервис.

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

ну так об том то и речь, что ХОТЯБЫ ПОКА так - это уже развязывало бы "руки и ноги" :) драйверному развитию оси!


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Ср апр 12, 2006 8:20 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3952
VaStaNi
Цитата:
система окончательно убедившись в правильности данного драйвера и фиксирует (не позволяет его менять приложениям и т.д.), закрепляет его ЗА этим устройством.


Ну, это совсем другое дело!

Иван Поддубный писал

Цитата:
мне даже страшно представить, что N раз в секунду будет происходить переключение задач со сменой адресного пространства...


Я тоже думаю что это не самое удачное по скорости решение. Еще одна проблема взаимодействие с драйвером когда программа в одном адресном пространстве а драйвер в другом


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Ср апр 12, 2006 9:32 pm 
Не в сети

Зарегистрирован: Сб янв 07, 2006 4:07 am
Сообщения: 47
Serge
Цитата:
А как будут передаваться данные между программой и драйвером, если они в разных адресных пространствах?

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


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Сб апр 22, 2006 6:06 pm 
Не в сети

Зарегистрирован: Пн апр 10, 2006 7:22 am
Сообщения: 76
Надо сделать DLL и всё получится. Кстати AC97WAV из комплекта KolibriOS 0.5.3.0b2 работает, но очень странно - при изменении громкости изменяется скорость звука, а также на разных форматах WAV32KHZ 8b Mono скорость получается ниже чем в нормальном, а кроме AC97 никакого звука нет. А при компиляции из исходников AC97WAV запускается и тутже выключается.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Сб апр 22, 2006 9:00 pm 
O01eg
В программе используется программное преобразование всех файлов к 48 Кгц, потому что менять частоту самого кодека мы пока не можем (для разных фирм разные способы). По этому, возможно, что в коде, внедренном мной, не совсем корректно идет преобразование некоторых частот.
Но вот насчет того, что при изменении громкости изменяется скорость - это я впервые слышу. Какой у тебя кодек: номер, фирма?
В исходники попали немного устаревшие файлы, но для нормальной работы нужно всего лишь изменить в файле meosfunc.inc данные для 68 функции на:
MF_INTERNAL_SERVICES = 68
ALLOC_PHYS_MEM =5
FREE_PHYS_MEM =6
SET_PHYS_BUFFER =7
GET_PHYS_BUFFER =8
После этого все становиться нормально.


Вернуться к началу
   
 Заголовок сообщения:
СообщениеДобавлено: Вс апр 23, 2006 9:36 am 
Не в сети

Зарегистрирован: Пн апр 10, 2006 7:22 am
Сообщения: 76
Avance AC97 Audio
Размещение: PCI шина 0, устройство 31, функция 5, IRQ 17


Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 947 сообщений ]  На страницу Пред. 13 4 5 6 764 След.

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB