Page 9 of 31
Posted: Tue Oct 17, 2006 3:51 pm
by andrew_programmer
mike.dld
ELF или COFF - это уже конкретная реализация.Я здесь не написал про них,но о подгружаемых библиотеках,как о варианте реализации - думал.Нужно не просто создать таблицу экспорта,а создать таблицу экспорта с фиксированными номерами графических функций.Иначе как ядро узнает,где в таблице экспорта находиться нужная графическая функция(например функция рисования прямоугольника).Насчет замены байт битами я тоже думал(еще до написания сообщения с драйверной моделью).В структуре должны быть учтены ВСЕ возможности видеокарты(в том числе и 3D).А уж поддерживает их драйвер или нет - это уже другое дело.
Posted: Tue Oct 17, 2006 4:04 pm
by vectoroc
Ядро узнает как и все это (в осноной своей массе) делают, по имени. О COFF-е заговорили имхо лишь потому что он очень распространён и прост, динамические библиотеки из него без изврата не получатся. Не предназначены они для этого. Стоит говорить о COFF + каком-то своём расширенном заголовке
Posted: Tue Oct 17, 2006 4:14 pm
by mike.dld
andrew_programmer
Как правильно заметил Victor, специально для того чтобы не думать о номерах придумали так называемые символические имена. Не знаю, знакомо ли тебе такое понятие, мне знакомо.
Posted: Tue Oct 17, 2006 5:02 pm
by andrew_programmer
>символические имена
Я эти имена понимаю,как название функци записанное в ASCII кодировке.
Posted: Tue Oct 17, 2006 5:40 pm
by Serge
Динамическую библиотеку из COFF сделать можно. Вообще это больше похоже на встроенный в ядро link с минимальными возможностями. Если объявить экспортируемые функции public то их имена будут в таблице символов и ядро сможет само получить их адреса правда тогда строки с именами функций должны быть в коде ядра.
Posted: Tue Oct 17, 2006 7:36 pm
by mike.dld
Я думаю мы можем на это пойти. Тем более, что при обрамлении макросами объявлений переменных и строк они все собираются в конце ядра в одном месте, что ещё более увеличивает потенциальный коэффициент сжатия.
Posted: Fri Oct 20, 2006 5:37 pm
by Serge
Написал новый загрузчик для драйверов и переписал драйверы. Теперь драйверы могут состоять из нескольких секций, но достаточно двух - одна для кода и инициализированных данных, вторая для неинициализированных данных. Секции выравниваются на 16 байт.
Все импортируемые функции должны объявлятся extrn.
Каждый драйвер должен иметь три обязательные функции START, STOP, service_proc.
START вызывается сразу после загрузки драйвера, выполняет все необходимые действия по настройке устройства и регистрирует драйвер в системе вызовом RegService.
Возвращаемое значение: eax - значение полученное после вызова RegService
STOP - зарезервирована
service_proc - основная функция. Вызывается приложениями через ф. 68.17, ядром через вызов srv_handler, другими драйверами через вызов ServiceHandler
Входные данные: указатель на структуру IOCTL
Возвращаемое значение: eax - определяется драйвером.
Posted: Thu Oct 26, 2006 11:04 pm
by hidnplayr
Serge wrote:hidnplayr
I looked on source and pdf. It's possible to write driver , but "remote e-mail debugging" takes lot of time.
You can also debug by using QEMU wich simulates a "ENSONIQ AudioPCI ES1370 sound card"
I can then test it on real hardware
I would LOVE to have this driver but hey, it's you're choice
Posted: Thu Oct 26, 2006 11:29 pm
by Serge
I don't knew about Qemu. It's a good news if it really works... Hope Qemu also emulate PCI accses
Posted: Fri Oct 27, 2006 7:05 pm
by hidnplayr
Serge wrote: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 1370
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
Posted: Thu Nov 16, 2006 8:57 am
by Serge
Добавил код для загрузки в ядро сжатых файлов. Теперь можно работать со сжатыми драйверами и ДЛЛ. Упаковщик kpack
http://meos.sysbin.com/viewtopic.php?t=355&start=30. Можно сделать такую же функцию для приложений.
Posted: Thu Nov 16, 2006 2:05 pm
by Serge
svn.212 работает на компьютерах с 16 Мб ОЗУ. Если внести в ядро некоторые изменения то можно ужать его до 8 Мб
Posted: Thu Nov 16, 2006 5:37 pm
by andrew_programmer
>Если внести в ядро некоторые изменения то можно ужать его до 8 Мб
Ого!
А что это за изменения такие и планируется ли их сделать ?
P.S.
Все версии ядра,начиная с 210 ревизии,работают через PIO или нет ?
Posted: Thu Nov 16, 2006 6:21 pm
by Serge
Если оставить одну битовую карту разрешения ввода-вывода для всех задач то сэкономится 2Мб, уплотнить данные в ядре ещё 1Мб, создавать PL0 стек в куче ядра ~768Кб.
Posted: Fri Nov 17, 2006 12:35 pm
by Mario79
Serge
Было бы замечательно.