Board.KolibriOS.org

Official KolibriOS board
It is currently Fri Dec 06, 2019 9:46 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 981 posts ]  Go to page Previous 13 4 5 6 766 Next
Author Message
 Post subject:
PostPosted: Tue Apr 11, 2006 7:08 pm 
Offline

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

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

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

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


Top
   
 Post subject:
PostPosted: Tue Apr 11, 2006 7:57 pm 
VaStaNi
Протестировал, отчет выслал.


Top
   
 Post subject:
PostPosted: Tue Apr 11, 2006 8:36 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Иван Поддубный

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

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


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

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


Top
   
 Post subject:
PostPosted: Tue Apr 11, 2006 10:19 pm 
Offline
User avatar

Joined: Thu May 19, 2005 4:43 pm
Posts: 896
[/offtop] VaStaNi,а до тебя мое письмо с тестами AC'97 дощло ?
[\offtop]

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

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

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


Top
   
 Post subject:
PostPosted: Wed Apr 12, 2006 1:07 pm 
Offline
Just Flooding
User avatar

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


Top
   
 Post subject:
PostPosted: Wed Apr 12, 2006 3:27 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
VaStaNi

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


Top
   
 Post subject:
PostPosted: Wed Apr 12, 2006 6:18 pm 
Offline

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

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


Top
   
 Post subject:
PostPosted: Wed Apr 12, 2006 6:28 pm 
Offline
Kernel Developer

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


Top
   
 Post subject:
PostPosted: Wed Apr 12, 2006 6:41 pm 
Offline

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

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


Top
   
 Post subject:
PostPosted: Wed Apr 12, 2006 7:07 pm 
Offline
Just Flooding
User avatar

Joined: Wed May 18, 2005 10:27 am
Posts: 430
Serge wrote:
VaStaNi
Вот только не надо ничего заране фиксировать и резервировать. Ядро не обязано знать какая железка какое прерывание использует.

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

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

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


Top
   
 Post subject:
PostPosted: Wed Apr 12, 2006 8:20 pm 
Offline
Kernel Developer

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


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

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

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


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


Top
   
 Post subject:
PostPosted: Wed Apr 12, 2006 9:32 pm 
Offline

Joined: Sat Jan 07, 2006 4:07 am
Posts: 47
Serge
Quote:
А как будут передаваться данные между программой и драйвером, если они в разных адресных пространствах?

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


Top
   
 Post subject:
PostPosted: Sat Apr 22, 2006 6:06 pm 
Offline

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


Top
   
 Post subject:
PostPosted: Sat Apr 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
После этого все становиться нормально.


Top
   
 Post subject:
PostPosted: Sun Apr 23, 2006 9:36 am 
Offline

Joined: Mon Apr 10, 2006 7:22 am
Posts: 76
Avance AC97 Audio
Размещение: PCI шина 0, устройство 31, функция 5, IRQ 17


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 981 posts ]  Go to page Previous 13 4 5 6 766 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited