mike.dld
ELF или COFF - это уже конкретная реализация.Я здесь не написал про них,но о подгружаемых библиотеках,как о варианте реализации - думал.Нужно не просто создать таблицу экспорта,а создать таблицу экспорта с фиксированными номерами графических функций.Иначе как ядро узнает,где в таблице экспорта находиться нужная графическая функция(например функция рисования прямоугольника).Насчет замены байт битами я тоже думал(еще до написания сообщения с драйверной моделью).В структуре должны быть учтены ВСЕ возможности видеокарты(в том числе и 3D).А уж поддерживает их драйвер или нет - это уже другое дело.
Новая модель ядра
Ядро узнает как и все это (в осноной своей массе) делают, по имени. О COFF-е заговорили имхо лишь потому что он очень распространён и прост, динамические библиотеки из него без изврата не получатся. Не предназначены они для этого. Стоит говорить о COFF + каком-то своём расширенном заголовке
Last edited by vectoroc on Tue Oct 17, 2006 5:17 pm, edited 1 time in total.
andrew_programmer
Как правильно заметил Victor, специально для того чтобы не думать о номерах придумали так называемые символические имена. Не знаю, знакомо ли тебе такое понятие, мне знакомо.
Как правильно заметил Victor, специально для того чтобы не думать о номерах придумали так называемые символические имена. Не знаю, знакомо ли тебе такое понятие, мне знакомо.
>символические имена
Я эти имена понимаю,как название функци записанное в ASCII кодировке.
Я эти имена понимаю,как название функци записанное в ASCII кодировке.
Динамическую библиотеку из COFF сделать можно. Вообще это больше похоже на встроенный в ядро link с минимальными возможностями. Если объявить экспортируемые функции public то их имена будут в таблице символов и ядро сможет само получить их адреса правда тогда строки с именами функций должны быть в коде ядра.
Я думаю мы можем на это пойти. Тем более, что при обрамлении макросами объявлений переменных и строк они все собираются в конце ядра в одном месте, что ещё более увеличивает потенциальный коэффициент сжатия.
Написал новый загрузчик для драйверов и переписал драйверы. Теперь драйверы могут состоять из нескольких секций, но достаточно двух - одна для кода и инициализированных данных, вторая для неинициализированных данных. Секции выравниваются на 16 байт.
Все импортируемые функции должны объявлятся extrn.
Каждый драйвер должен иметь три обязательные функции START, STOP, service_proc.
START вызывается сразу после загрузки драйвера, выполняет все необходимые действия по настройке устройства и регистрирует драйвер в системе вызовом RegService.
Возвращаемое значение: eax - значение полученное после вызова RegService
STOP - зарезервирована
service_proc - основная функция. Вызывается приложениями через ф. 68.17, ядром через вызов srv_handler, другими драйверами через вызов ServiceHandler
Входные данные: указатель на структуру IOCTL
Возвращаемое значение: eax - определяется драйвером.
Все импортируемые функции должны объявлятся extrn.
Каждый драйвер должен иметь три обязательные функции START, STOP, service_proc.
START вызывается сразу после загрузки драйвера, выполняет все необходимые действия по настройке устройства и регистрирует драйвер в системе вызовом RegService.
Возвращаемое значение: eax - значение полученное после вызова RegService
STOP - зарезервирована
service_proc - основная функция. Вызывается приложениями через ф. 68.17, ядром через вызов srv_handler, другими драйверами через вызов ServiceHandler
Входные данные: указатель на структуру IOCTL
Возвращаемое значение: eax - определяется драйвером.
Last edited by Serge on Fri May 11, 2007 6:35 pm, edited 1 time in total.
You can also debug by using QEMU wich simulates a "ENSONIQ AudioPCI ES1370 sound card"Serge wrote:hidnplayr
I looked on source and pdf. It's possible to write driver , but "remote e-mail debugging" takes lot of time.
I can then test it on real hardware
I would LOVE to have this driver but hey, it's you're choice
I don't knew about Qemu. It's a good news if it really works... Hope Qemu also emulate PCI accses
PS: the source code of the program i gave you is for an ES1371 and not 1370Serge wrote:I don't knew about Qemu. It's a good news if it really works... Hope Qemu also emulate PCI accses
I have both cards..
You can find the source code of a driver for ES1370 (written in c++) on my server:
ftp://hidnplayr.be:2100/es1370_cpp_source.rar
for more info:
http://en.wikipedia.org/wiki/Ensoniq_ES1370
Datasheet:
http://www.hh.iij4u.or.jp/~tokumi/ES1370.PDF
Bug:
http://www.alsa-project.org/alsa/ftp/da ... /esbug.pdf
Добавил код для загрузки в ядро сжатых файлов. Теперь можно работать со сжатыми драйверами и ДЛЛ. Упаковщик kpack http://meos.sysbin.com/viewtopic.php?t=355&start=30. Можно сделать такую же функцию для приложений.
svn.212 работает на компьютерах с 16 Мб ОЗУ. Если внести в ядро некоторые изменения то можно ужать его до 8 Мб
>Если внести в ядро некоторые изменения то можно ужать его до 8 Мб
Ого!
А что это за изменения такие и планируется ли их сделать ?
P.S.
Все версии ядра,начиная с 210 ревизии,работают через PIO или нет ?
Ого!
А что это за изменения такие и планируется ли их сделать ?
P.S.
Все версии ядра,начиная с 210 ревизии,работают через PIO или нет ?
Если оставить одну битовую карту разрешения ввода-вывода для всех задач то сэкономится 2Мб, уплотнить данные в ядре ещё 1Мб, создавать PL0 стек в куче ядра ~768Кб.
Serge
Было бы замечательно.
Было бы замечательно.
Who is online
Users browsing this forum: No registered users and 2 guests