Writing drivers for KolibriOS/ru

ВНИМАНИЕ: Данная статья находится в разработке и содержит множество устаревших и непроверенных данных. В данный момент использование этой статьи в качестве справочного материала не рекомендуется.

ПРЕДУПРЕЖДЕНИЕ: Данная статья устарела и переписывается. НЕ ИСПОЛЬЗУЙТЕ ЭТУ СТАТЬЮ.

Вступление

Предупреждение 0. Данная статья описывает написание драйверов для основной ветки Колибри ОС и не включает в себя исторические моменты. Предыдущая версия статьи находится на форуме по ссылке.

Предупреждение 1. Прежде чем писать драйвер, хорошо подумайте, нельзя ли обойтись средствами прикладных API, в частности, функций работы с оборудованием 46 и 62. Во-первых, от ошибки в кривом приложении пострадает только это кривое приложение, а кривой драйвер способен без особого труда обрушить всю систему. Во-вторых, для приложений можно вылавливать баги в отладчике MTDBG, обладающем определёнными возможностями, а для драйверов этот путь закрыт (разве что встроенный отладчик эмулятора Bochs, но он заведомо непригоден для отладки с реальным железом), так что единственным средством остаётся отладочный вывод на доску отладки BOARD со всеми недостатками.

Далее допустим, что вы всё ещё читаете эту статью. Мало ли, может, вы всегда пишете код с первого раза безошибочно (чего только на свете не бывает), или в совершенстве владеете отладкой прямо в мозгу и считаете всякие отладочные средства баловством, или просто считаете, что настоящий мужчина (настоящая леди?) не боится трудностей и несколькими строчками текста вас не напугать.

Предупреждение 2. Драйвера, естественно, тесно связаны с ядром. А в ядро КолибриОС вносятся изменения несколько раз в неделю. Разумеется, большинство изменений никак не касается драйверной подсистемы, но иногда добавляются/исчезают/изменяются важные системные функции, экспортируемые драйверам. Поэтому если вы возьмёте и скомпилируете прилагаемый к статье код, то, возможно, он прямо в таком виде работать не будет. Так что внимательно читайте текст - я постараюсь выделить по возможности все причины неработоспособности в будущем и требуемые модификации. Прилагаемый к статье код рассчитан на ревизию {{#svn_rev:450}}, последнюю на момент написания этих строк (в дистрибутиве 0.6.5.0 работать в таком виде не будет).

Вообще-то основная задача драйверов - обеспечить работу с оборудованием. Но поскольку эта статья ставит своей целью показать принципы работы драйверов, а для реализации основной задачи нужно много кода, работающего именно с железом и не имеющего никакого отношения к драйверной подсистеме, то процесс написания драйвера показан на следующем примере: создадим драйвер, перехватывающий и записывающий все обращения приложений к файловой системе, и управляющую программу, которая получает данные от драйвера и отображает их. В качестве средства разработки используется FASM. Архив к статье находится здесь.

Описание работы с драйверной подсистемой

Драйверная подсистема позволяет ядру загружать драйвера в формате PE и работать с ними. Для загрузки драйверов предусмотрено 2 системных вызова: 68.16 и 68.21, а для управления драйвером системный вызов 68.17. Драйвер должен иметь точку входа с функцией, которая должна возвращать хандлер структуры драйвера в случае успеха, и ноль в случае, если драйвер не инициализировался. Для работы драйвер импортирует некоторые функции ядра, которые экспортируются ядром как core.dll.

Драйвер

Специально для желающих написать свой драйвер предоставляется каркас драйвера. Он находится в git-репозитории в папке drivers. Ну что же, давайте посмотрим sceletone.asm):

<syntaxhighlight lang="asm">

;;

Copyright (C) KolibriOS team 2004-2007. All rights reserved. ;;

Distributed under terms of the GNU General Public License  ;;

;;

driver sceletone

format PE DLL native 0.05 entry START

section '.flat' code readable writable executable include 'proc32.inc' include 'struct.inc' include 'macros.inc' include 'peimport.inc'

</syntaxhighlight>

Ну, "Copyright" - он и есть копирайт, комментарий в следующей строке извещает нас, куда же мы собственно попали, это неинтересно. Дальше мы должны известить компилятор, какой формат мы хотим получить. Драйвера должны иметь формат PE. В общем, так должно быть для всех драйверов. Дальше идёт указание функции START как точки входа, которую вызовет ядро после загрузки драйвера. После этого объявляется секция ".flat", в которой будет располагаться код нашего драйвера, после объявления секции подключаем вспомогательные файлы. proc32.inc содержит макросы для определения и вызова стандартных процедур (proc/endp, stdcall/ccall/invoke/cinvoke, local для создания локальных переменных) и находится в той же папке, что и sceletone.asm. Его можно включать или не включать, макросы оттуда можно использовать или не использовать, в этой статье они используются, чтобы не усложнять восприятие (вообще говоря, при стремлении к максимальной эффективности использование макросов может повредить, но это тема отдельных жарких споров). peimport.inc содержит объявления для всех экспортируемых функций ядра. Загляните туда, ничего сложного там нет, просто куча стереотипных конструкций. На самом деле (в смысле того, как разрешается импорт при загрузке драйвера) список всех экспортируемых функций и данных ядра находится в файле {{#svn:/kernel/trunk/core/exports.inc|core/exports.inc}} (метка kernel_export), так что если вам как программисту ядра вдруг понадобиться что-нибудь своё экспортировать, лезьте туда (ну peimport.inc отредактируйте из вежливости к другим).

Внимание! Здесь появляется возможность несовместимости: если вы используете какие-нибудь функции, которых (ещё или уже) нет в ядре, на которое вы рассчитываете, ядро откажется грузить ваш драйвер (ругнувшись на доске отладки нехорошим словом на ненашем языке "unresolved" с указанием имени функции).

Ну что же, идём дальше:

<syntaxhighlight lang="asm"> DEBUG equ 1 ; for debug output in board

API_VERSION equ 0 ;version api this driver

STRIDE equ 4 ;size of row in devices table

SRV_GETVERSION equ 0 ; number function for get api version

</syntaxhighlight>

Это просто объявление констант

<syntaxhighlight lang="asm">

proc START c, state:dword, cmdline:dword

       cmp     [state], 1
       jne     .exit

.entry:

       push    esi
    if DEBUG
       mov     esi, msgInit
       invoke  SysMsgBoardStr
    end if
       call    detect
       pop     esi
       test    eax, eax
       jz      .fail

       invoke  RegService, my_service, service_proc
       ret

.fail: .exit:

       xor     eax, eax
       ret

endp

</syntaxhighlight>

Выше мы создали функцию START, о которой уже говорилось ранее. Данная функция принимает 2 аргумента: state и cmdline и возвращает хэндлер драйвера, полученный при вызове RegService. Если эта функция вернёт 0, то это будет означать, что драйвер по какой-то причине не может работать(либо нет нужного оборудования, с которым бы драйвер работал, либо его что-то не устраивает и чтобы не создавать ошибок, драйвер завершает работу). Параметр cmdline это командная строка в ascii кодировке, state это действие, которое требует от этой функции ядро. Сейчас есть 2 значения этого аргумента: DRV_ENTRY передаваемое при старте драйвера и DRV_EXIT передаваемое при завершении работы драйвера. Эти значения определены в файле {{#svn:/drivers/macros.inc|macros.inc}}. В этом коде вызываются 2 функции импортированные из ядра: SysMsgBoardStr и RegService, функции ядра имеют разные соглашения о вызовах, в одних параметры передаются через стек, в других через регистры. Описание соглашения о вызовах функций можно найти в файле {{#svn:/kernel/trunk/core/exports.inc|exports.inc}} в комментарии возле экспортируемой функции.

Процедура START - это процедура, которая вызывается системой при загрузке драйвера и при завершении работы. В первом случае она должна инициализировать драйвер, во втором - наоборот. О ней речь пойдёт чуть позже.

Процедуру service_proc экспортировать совершенно ненужно, о её размещении ядро узнаёт по другим каналам, о ней речь пойдёт ещё позже.

Последняя порция констант

<syntaxhighlight lang="asm"> DEBUG equ 1

STRIDE equ 4 ;size of row in devices table </syntaxhighlight>

(из которых первая включает код отладочного вывода в блоках if DEBUG/end if, последняя нужна для красоты и ни для чего больше) и мы наконец-то переходим к изучению кода:

<syntaxhighlight lang="asm"> section '.flat' code readable align 16 </syntaxhighlight>

означает ровно-таки то, что написано;

<syntaxhighlight lang="asm"> proc START stdcall, state:dword

          cmp [state], 1
          jne .exit

.entry:

    if DEBUG
          mov esi, msgInit
          call SysMsgBoardStr
    end if

          stdcall RegService, my_service, service_proc

ret .fail: .exit:

          xor eax, eax
          ret

endp </syntaxhighlight>

Это код процедуры инициализации/финализации. При загрузке драйвера она вызывается с аргументом DRV_ENTRY = 1 и должна вернуть ненулевое значение при успехе. При завершении системы она вызывается с аргументом DRV_EXIT = -1. В нашем случае драйвер не работает ни с каким железом, так что ни инициализации никакого железа, ни вообще никакой финализации нет, а есть только минимально необходимые действия, чтобы драйвер считался загруженным, а именно, регистрация. Функция RegService экспортируется ядром и принимает два аргумента: имя драйвера (до 16 символов, включая завершающий 0) и указатель на процедуру обработки I/O, а возвращает 0 при неудаче или (ненулевой) зарегистрированный хэндл при успехе. Кстати, как узнать, что делает та или иная экспортируемая функция? Допустим, нам позарез нужно выделить пару страниц памяти ядра. Лезем в исходники ядра, файл {{#svn:/kernel/trunk/core/exports.inc|core/exports.inc}}, просматриваем экспортируемые имена (они осмысленны) и видим szKernelAlloc. Пролистываем вниз до метки kernel_export и ищем szKernelAlloc - обнаруживаем, что ему соответствует процедура kernel_alloc. Теперь ищем реализацию kernel_alloc, она обнаруживается в {{#svn:/kernel/trunk/core/heap.inc|core/heap.inc}}. Комментариев около функции нет, но есть объявление proc, из которого следует, что функция принимает один аргумент size типа dword. Теперь по названию ясно, что kernel_alloc выделяет память ядра в размере, равном единственному аргументу. Причём первые же три строчки кода функции показывают, что размер выравнивается вверх на границу 4096 (т.е. размер одной страницы), следовательно, функция выделяет некоторое целое количество страниц, а размер задаётся в байтах.

Дальше идёт процедура обработки запросов service_proc:

<syntaxhighlight lang="asm"> handle equ IOCTL.handle io_code equ IOCTL.io_code input equ IOCTL.input inp_size equ IOCTL.inp_size output equ IOCTL.output out_size equ IOCTL.out_size

align 4 proc service_proc stdcall, ioctl:dword

mov edi, [ioctl]

mov eax, [edi+io_code]

xor eax, eax ret endp

restore handle restore io_code restore input restore inp_size restore output restore out_size </syntaxhighlight>

Процедура обработки запросов вызывается, когда какой-то внешний код возжаждал общения именно с нашим драйвером. Это может быть как другой драйвер (формально драйвер может вызывать сам себя через механизм I/O, но смысла в этом нет), надыбавший где-то наш хэндл и вызвавший ServiceHandler, или даже само ядро (srv_handler, srv_handlerEx из {{#svn:/kernel/trunk/core/dll.inc|core/dll.inc}}), так и приложение функцией 68.17 (хэндл приложение может добыть при загрузке драйвера функцией 68.16). Нулевое возвращаемое значение означает успех, ненулевое соответствует ошибке. Вначале определяем сокращённые имена для членов структуры, описывающей запрос. В поле handle содержится хэндл драйвера (такой же, как и возвращаемое значение RegService), io_code - dword-идентификатор запроса, остальные поля вопросов вызывать не должны. Возвращаемое значение напрямую передаётся вызвавшему нас коду (драйвер/ядро/приложение). В конце восстанавливаем значения, переназначенные было на короткие имена членов структуры. В данном случае это без надобности, но в случае сложных драйверов короткие имена типа "input" запросто могут встречаться не один раз.

Дальше в {{#svn:/kernel/trunk/drivers/sceletone.asm|sceletone.asm|450}} содержится код поиска заданного оборудования на PCI-шине, нам он без надобности, при необходимости разберитесь сами.

Итак, с каркасом драйвера разобрались. А теперь будем писать свой драйвер. Начало стандартное:

<syntaxhighlight lang="asm">

;;

Copyright (C) KolibriOS team 2004-2007. All rights reserved. ;;

Distributed under terms of the GNU General Public License  ;;

;;

FileMon

driver part

format MS COFF

include 'proc32.inc' include 'imports.inc' </syntaxhighlight>

Ориентируемся на {{#svn_rev:450}} (для 0.6.5.0 нужно было бы писать "new_app_base equ 0x60400000"):

<syntaxhighlight lang="asm"> OS_BASE equ 0; new_app_base equ 0x80000000 </syntaxhighlight>

Небольшая порция объявлений:

<syntaxhighlight lang="asm"> struc IOCTL { .handle dd ?

  .io_code     dd ?
  .input       dd ?
  .inp_size    dd ?
  .output      dd ?
  .out_size    dd ?

}

virtual at 0

 IOCTL IOCTL

end virtual

public START public version

DRV_ENTRY equ 1 DRV_EXIT equ -1

section '.flat' code readable align 16 </syntaxhighlight>

Пока что всё стереотипно. Но прежде чем писать код, нужно определиться, чего мы от этого кода хотим. Итак, наш драйвер будет понимать четыре кода запроса ввода/вывода. Код 0 для всех драйверов специально предназначен для получения версии драйвера (здесь уже идёт работа с версией самого драйвера, а не версией интерфейса ядра). Строго говоря, реализовывать обработку этого запроса необязательно (ядру глубоко наплевать на версию драйвера), но весьма желательно, поскольку практически всегда драйвер можно развивать и изменять, а тогда для кода, использующего наш драйвер, знать версию всегда полезно. Версию драйвера можно возвращать в любом формате, в нашем примере для простоты будем использовать просто dword-номер версии, равный 1. Далее, код 1 означает "начать лог", код 2 - "выдать лог до текущего момента и сбросить", код 3 - "остановить лог". Лог будет записываться во внутренний буфер размера 16 Кб (учитывая, что опрашивать драйвер мы будем раз в секунду, этого должно хватить за глаза, но если вдруг не хватит, присутствие лишних записей мы сигнализируем, но сами записи не принимаем). Формат выдаваемой информации о логе: вначале общий размер записанных данных лога; потом байт со значением 0 или 1, причём 1 означает, что какие-то записи не поместились в буфере; потом массив структур переменного размера, первый байт которых содержит номер вызванной функции файловой системы и определяет дальнейшее содержимое записи. Инициализировать что-либо в драйвере нам не надо, так что процедура START выглядит так:

<syntaxhighlight lang="asm"> proc START stdcall, state:dword

          cmp [state], DRV_ENTRY
          jne .exit

.entry:

          stdcall RegService, my_service, service_proc

ret .fail: .exit:

          xor eax, eax
          ret

endp </syntaxhighlight>

Далее - обработка запросов:

<syntaxhighlight lang="asm"> handle equ IOCTL.handle io_code equ IOCTL.io_code input equ IOCTL.input inp_size equ IOCTL.inp_size output equ IOCTL.output out_size equ IOCTL.out_size

proc service_proc stdcall, ioctl:dword mov edi, [ioctl] mov eax, [edi+io_code] test eax, eax jz .getversion dec eax jz .startlog dec eax jz .getlog dec eax jz .endlog xor eax, eax ret .getversion: cmp [edi+out_size], 4 jb .err mov edi, [edi+output] mov dword [edi], 1 ; version of driver .ok: xor eax, eax ret .err: or eax, -1 ret .startlog: mov al, 1 xchg al, [bLogStarted] test al, al jnz .ok mov [logptr], logbuf call hook jnc .ok mov [bLogStarted], 0 jmp .err .getlog: cli mov esi, logbuf mov ecx, [logptr] sub ecx, esi add ecx, 5 cmp ecx, [edi+out_size] jbe @f mov ecx, [edi+out_size] mov [bOverflow], 1 @@: sub ecx, 5 xor eax, eax xchg al, [bOverflow] mov edi, [edi+output] mov [edi], ecx add edi, 4 stosb rep movsb mov [logptr], logbuf sti xor eax, eax ret .endlog: xchg al, [bLogStarted] test al, al jz @f call unhook @@: xor eax, eax ret endp

restore handle restore io_code restore input restore inp_size restore output restore out_size </syntaxhighlight>

Здесь стоит отметить, что входных данных для драйвера не нужно, поля input/inp_size мы не используем. В поле out_size вызывающий код должен поместить размер буфера output. Если нас вызывает приложение, то все манипуляции с переводом указателей приложения в указатели ядра осуществляет ядро, а в структуре ioctl передаются уже подправленные указатели.

Ну а теперь часть, отвечающая за взаимодействие с драйверной подсистемой, закончилась и начинается собственно работа. Мы перехватываем функции файловой системы 6,32,33,58,70. Для этого мы используем тот факт, что общий обработчик int 0x40 вызывает конкретную функцию косвенным вызовом из таблицы servetable (код этот обработчика располагается в файле {{#svn:/kernel/trunk/core/syscall.inc|core/syscall.inc}}). Следовательно, если подменить нужные элементы в этой таблице на адреса наших обработчиков, то вызываться будет наш код. Узнать адрес servetable можно сканированием кода обработчика int 0x40. Адрес функции i40 легко узнать из IDT, а команда вызова в текущей реализации имеет вид "call dword [servetable+edi*4]", в машинном коде "FF 14 BD <servetable>" (в принципе никто не гарантирует, что так будет и дальше, в частности, потенциально возможна замена edi на eax; тогда нужно будет соответственно менять код).

<syntaxhighlight lang="asm"> hook: cli sub esp, 6 sidt [esp] pop ax ; limit pop eax ; base mov edx, [eax+40h*8+4] mov dx, [eax+40h*8]

edx contains address of i40

mov ecx, 100 .find: cmp byte [edx], 0xFF jnz .cont cmp byte [edx+1], 0x14 jnz .cont cmp byte [edx+2], 0xBD jz .found .cont: inc edx loop .find sti mov esi, msg_failed call SysMsgBoardStr stc ret .found: mov eax, [edx+3]

eax contains address of servetable

mov [servetable_ptr], eax mov edx, newfn06 xchg [eax+6*4], edx mov [oldfn06], edx mov edx, newfn32 xchg [eax+32*4], edx mov [oldfn32], edx mov edx, newfn33 xchg [eax+33*4], edx mov [oldfn33], edx mov edx, newfn58 xchg [eax+58*4], edx mov [oldfn58], edx mov edx, newfn70 xchg [eax+70*4], edx mov [oldfn70], edx sti clc ret

unhook: cli mov eax, [servetable_ptr] mov edx, [oldfn06] mov [eax+6*4], edx mov edx, [oldfn32] mov [eax+32*4], edx mov edx, [oldfn33] mov [eax+33*4], edx mov edx, [oldfn58] mov [eax+58*4], edx mov edx, [oldfn70] mov [eax+70*4], edx sti ret </syntaxhighlight>

Две вспомогательные функции:

<syntaxhighlight lang="asm"> write_log_byte:

in

al=byte

push ecx mov ecx, [logptr] inc ecx cmp ecx, logbuf + logbufsize ja @f mov [logptr], ecx mov [ecx-1], al pop ecx ret @@: mov [bOverflow], 1 pop ecx ret

write_log_dword:

in

eax=dword

push ecx mov ecx, [logptr] add ecx, 4 cmp ecx, logbuf + logbufsize ja @f mov [logptr], ecx mov [ecx-4], eax pop ecx ret @@: mov [bOverflow], 1 pop ecx ret </syntaxhighlight>

При написании самих обработчиков следует учитывать, что регистры циклически сдвигаются по сравнению с вызовом int 0x40 в приложении и что все указатели - это указатели 3-кольца.

<syntaxhighlight lang="asm"> newfn06: cli push [logptr] push eax mov al, 6 ; function 6 call write_log_byte mov eax, ebx ; start block call write_log_dword mov eax, ecx ; number of blocks call write_log_dword mov eax, edx ; output buffer call write_log_dword pop eax push eax push esi lea esi, [eax+new_app_base] ; pointer to file name @@: lodsb call write_log_byte test al, al jnz @b pop esi pop eax cmp [bOverflow], 0 jz .nooverflow pop [logptr] jmp @f .nooverflow: add esp, 4 @@: sti jmp [oldfn06]

newfn32: cli push [logptr] push eax mov al, 32 ; function 32 call write_log_byte pop eax push eax push esi lea esi, [eax+new_app_base] ; pointer to file name @@: lodsb call write_log_byte test al, al jnz @b pop esi pop eax cmp [bOverflow], 0 jz .nooverflow pop [logptr] jmp @f .nooverflow: add esp, 4 @@: sti jmp [oldfn32]

newfn33: cli push [logptr] push eax mov al, 33 ; function 33 call write_log_byte mov eax, ebx ; input buffer call write_log_dword mov eax, ecx ; number of bytes call write_log_dword pop eax push eax push esi lea esi, [eax+new_app_base] ; pointer to file name @@: lodsb call write_log_byte test al, al jnz @b pop esi pop eax cmp [bOverflow], 0 jz .nooverflow pop [logptr] jmp @f .nooverflow: add esp, 4 @@: sti jmp [oldfn33]

newfn58: cli push [logptr] push eax push ebx lea ebx, [eax+new_app_base] mov al, 58 ; function 58 call write_log_byte

dump information structure

mov eax, [ebx] call write_log_dword mov eax, [ebx+4] call write_log_dword mov eax, [ebx+8] call write_log_dword mov eax, [ebx+12] call write_log_dword push esi lea esi, [ebx+20] ; pointer to file name @@: lodsb call write_log_byte test al, al jnz @b pop esi pop ebx pop eax cmp [bOverflow], 0 jz .nooverflow pop [logptr] jmp @f .nooverflow: add esp, 4 @@: sti jmp [oldfn58]

newfn70: cli push [logptr] push eax push ebx lea ebx, [eax+new_app_base] mov al, 70 ; function 70 call write_log_byte

dump information structure

mov eax, [ebx] call write_log_dword mov eax, [ebx+4] call write_log_dword mov eax, [ebx+8] call write_log_dword mov eax, [ebx+12] call write_log_dword mov eax, [ebx+16] call write_log_dword push esi lea esi, [ebx+20] ; pointer to file name lodsb test al, al jnz @f lodsd lea esi, [eax+new_app_base+1] @@: dec esi @@: lodsb call write_log_byte test al, al jnz @b pop esi pop ebx pop eax cmp [bOverflow], 0 jz .nooverflow pop [logptr] jmp @f .nooverflow: add esp, 4 @@: sti jmp [oldfn70] </syntaxhighlight>

На этом код заканчивается. Теперь используемые данные (мы ориентируемся на {{#svn_rev:450}}, для 0.6.5.0 version должна быть 0x00030003):

<syntaxhighlight lang="asm"> version dd 0x00040004 my_service db 'fmondrv',0

msg_failed db 'Cannot hook required functions',13,10,0

section '.data' data readable writable align 16

servetable_ptr dd ?

oldfn06 dd ? oldfn32 dd ? oldfn33 dd ? oldfn58 dd ? oldfn70 dd ?

logptr dd ? logbufsize = 16*1024 logbuf rb logbufsize

bOverflow db ? bLogStarted db ? </syntaxhighlight>

Собрав весь приведённый код в один файл fmondrv.asm, получаем окончательный исходник драйвера. Кроме того, этот файл входит в архив к статье. Компиляция:

fasm fmondrv.asm

После этого по желанию можно упаковать fmondrv.obj с помощью KPACK, ядро прекрасно загружает kpack'ованные файлы, а такая мера в данном случае уменьшает размер с 1850 байт до 757 байт. Кстати, маленькая хитрость: по смещению +4 в COFF-объектнике хранится штамп даты/времени компиляции, ядру на него глубоко наплевать, так что можно забить его нулями любым hex-редактором, после чего сжатый файл будет чуть-чуть меньше (в данном случае 756 байт). Для установки драйвера скопируйте его в /rd/1/drivers, после этого он готов к загрузке.

Управляющая программа

Управляющая программа у нас будет выводить текстовую информацию на консоль и завершать работу при нажатии Esc. Для этого потребуется консольная DLL версии как минимум 3, причём в дистрибутив 0.6.5.0 входит версия 2, так что скачивайте последнюю версию из http://diamondz.land.ru/console.7z. В качестве шаблона используем testcon.asm (можно было бы и testcon2.asm) со следующими изменениями: в REQ_DLL_VER подставляем 3, в таблице импорта (метка myimport) убираем con_write_asciiz и добавляем con_printf, con_kbhit, con_getch2 и, разумеется, после строчки с комментарием "Now do some work" пишем свой код.

<syntaxhighlight lang="asm"> use32

       db      'MENUET01'
       dd      1
       dd      start
       dd      i_end
       dd      mem
       dd      mem
       dd      0
       dd      0

REQ_DLL_VER = 3 DLL_ENTRY = 1

start:

First 3 steps are intended to load/init console DLL

and are identical for all console programs

load DLL

       mov     eax, 68
       mov     ebx, 19
       mov     ecx, dll_name
       int     0x40
       test    eax, eax
       jz      exit

initialize import

       mov	edx, eax
       mov     esi, myimport

import_loop:

       lodsd
       test    eax, eax
       jz      import_done
       push    edx

import_find:

       mov     ebx, [edx]
       test    ebx, ebx
       jz      exit;import_not_found
       push    eax

@@:

       mov     cl, [eax]
       cmp     cl, [ebx]
       jnz     import_find_next
       test    cl, cl
       jz      import_found
       inc     eax
       inc     ebx
       jmp     @b

import_find_next:

       pop     eax
       add     edx, 8
       jmp     import_find

import_found:

       pop     eax
       mov     eax, [edx+4]
       mov     [esi-4], eax
       pop     edx
       jmp     import_loop

import_done:

check version

       cmp     word [dll_ver], REQ_DLL_VER
       jb      exit
       cmp     word [dll_ver+2], REQ_DLL_VER
       ja      exit
       push    DLL_ENTRY
       call    [dll_start]

yes! Now do some work (say helloworld in this case).

       push    caption
       push    -1
       push    -1
       push    -1
       push    -1
       call    [con_init]

</syntaxhighlight>

Загружаем драйвер, при ошибке ругаемся на консоли и выходим, оставляя консоль на экране:

<syntaxhighlight lang="asm">

       mov     eax, 68
       mov     ebx, 16
       mov     ecx, drivername
       int     0x40
       mov     [hDriver], eax
       test    eax, eax
       jnz     @f

loaderr:

       push    aCantLoadDriver
       call    [con_printf]
       add     esp, 4
       push    0
       call    [con_exit]
       jmp     exit

@@: </syntaxhighlight>

Проверяем версию драйвера, для чего посылаем ему запрос с кодом 0:

<syntaxhighlight lang="asm">

       and     [ioctl_code], 0
       and     [inp_size], 0
       mov     [outp_size], 4
       mov     [output], driver_ver
       mov     eax, 68
       mov     ebx, 17
       mov     ecx, ioctl
       int     0x40
       test    eax, eax
       jnz     loaderr
       cmp     [driver_ver], 1
       jnz     loaderr

</syntaxhighlight>

Запускаем лог - запрос с кодом 1:

<syntaxhighlight lang="asm">

       mov     [ioctl_code], 1
       and     [inp_size], 0
       and     [outp_size], 0
       mov     eax, 68
       mov     ebx, 17
       mov     ecx, ioctl
       int     0x40
       test    eax, eax
       jnz     loaderr

</syntaxhighlight>

Итак, драйвер загружен и ведёт лог. Сообщим пользователю, что происходит:

<syntaxhighlight lang="asm">

       push    str0
       call    [con_printf]
       add     esp, 4

</syntaxhighlight>

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

<syntaxhighlight lang="asm"> mainloop:

       mov     eax, 5
       mov     ebx, 100
       int     0x40
       mov     [ioctl_code], 2
       and     [inp_size], 0
       mov     [outp_size], 1+16*1024
       mov     [output], logbuf
       mov     eax, 68
       mov     ebx, 17
       mov     ecx, ioctl
       int     0x40
       push    eax
       mov     ecx, dword [logbuf]
       mov     esi, logbuf+5

message:

       test    ecx, ecx
       jz      done
       movzx   eax, byte [esi]
       push    eax
       push    str1
       call    [con_printf]
       add     esp, 8
       lodsb
       cmp     al, 6
       jz      fn06
       cmp     al, 32
       jz      fn32
       cmp     al, 33
       jz      fn33
       cmp     al, 58
       jz      fn58
       sub     ecx, 1+4*5      ; size of log data for fn70 (excluding filename)
       lodsd
       cmp     eax, 10
       jae     fn70unk
       jmp     [fn70+eax*4]

fn70unk:

       push    dword [esi+12]
       push    dword [esi+8]
       push    dword [esi+4]
       push    dword [esi]
       push    eax
       push    str2
       call    [con_printf]
       add     esp, 6*4
       add     esi, 16
       jmp     print_name

fn70readfile:

       push    dword [esi+12]
       push    dword [esi+8]
       push    dword [esi]
       push    str3
       call    [con_printf]
       add     esp, 4*4
       add     esi, 16
       jmp     print_name

fn70readfolder:

       mov     eax, str41
       test    byte [esi+4], 1
       jz      @f
       mov     eax, str42

@@:

       push    dword [esi+12]
       push    dword [esi+8]
       push    dword [esi]
       push    eax
       push    str4
       call    [con_printf]
       add     esp, 5*4
       add     esi, 16
       jmp     print_name

fn70create:

       push    dword [esi+12]
       push    dword [esi+8]
       push    str5
       call    [con_printf]
       add     esp, 3*4
       add     esi, 16
       jmp     print_name

fn70write:

       push    dword [esi+12]
       push    dword [esi+8]
       push    dword [esi+4]
       push    str6
       call    [con_printf]
       add     esp, 4*4
       add     esi, 16
       jmp     print_name

fn70setsize:

       push    dword [esi]
       push    str7
       call    [con_printf]
       add     esp, 4*2
       add     esi, 16
       jmp     print_name

fn70getattr:

       push    dword [esi+12]
       push    str8
       call    [con_printf]
       add     esp, 4*2
       add     esi, 16
       jmp     print_name

fn70setattr:

       push    dword [esi+12]
       push    str9
       call    [con_printf]
       add     esp, 4*2
       add     esi, 16
       jmp     print_name

fn70execute:

       push    str10
       call    [con_printf]
       add     esp, 4
       lodsd
       test    al, 1
       jz      @f
       push    str10_1
       call    [con_printf]
       add     esp, 4

@@:

       lodsd
       test    eax, eax
       jz      @f
       push    eax
       push    str10_2
       call    [con_printf]
       add     esp, 8

@@:

       add     esi, 8
       jmp     print_name

fn70delete:

       push    str11
       call    [con_printf]
       add     esp, 4
       add     esi, 16
       jmp     print_name

fn70createfolder:

       push    str12
       call    [con_printf]
       add     esp, 4
       add     esi, 16
       jmp     print_name

fn58:

       sub     ecx, 1+4*4      ; size of log data for fn58 (excluding filename)
       lodsd
       test    eax, eax
       jz      fn58read
       cmp     eax, 1
       jz      fn58write
       cmp     eax, 8
       jz      fn58lba
       cmp     eax, 15
       jz      fn58fsinfo

fn58unk:

       push    dword [esi+8]
       push    dword [esi+4]
       push    dword [esi]
       push    eax
       push    str13
       call    [con_printf]
       add     esp, 5*4
       add     esi, 12
       jmp     print_name

fn58read:

       push    dword [esi+8]
       mov     eax, [esi+4]
       shl     eax, 9
       push    eax
       mov     eax, [esi]
       shl     eax, 9
       push    eax
       push    str3
       call    [con_printf]
       add     esp, 4*4
       add     esi, 12
       jmp     print_name

fn58write:

       push    dword [esi+8]
       push    dword [esi+4]
       push    str5
       call    [con_printf]
       add     esp, 3*4
       add     esi, 12
       jmp     print_name

fn58lba:

       push    dword [esi+8]
       push    dword [esi]
       push    str14
       call    [con_printf]
       add     esp, 3*4
       add     esi, 12
       jmp     print_name

fn58fsinfo:

       push    str15
       call    [con_printf]
       add     esp, 4
       add     esi, 12
       jmp     print_name

fn33:

       sub     ecx, 1+2*4      ; size of log data for fn33
       lodsd
       push    eax
       lodsd
       push    eax
       push    str5
       call    [con_printf]
       add     esp, 3*4
       push    aRamdisk
       call    [con_printf]
       add     esp, 4
       jmp     print_name

fn32:

       dec     ecx             ; only filename is logged
       push    str11
       call    [con_printf]
       push    aRamdisk
       call    [con_printf]
       add     esp, 4+4
       jmp     print_name

fn06:

       sub     ecx, 1+3*4      ; size of log data for fn06
       push    dword [esi+8]
       mov     eax, [esi+4]
       test    eax, eax
       jnz     @f
       inc     eax

@@:

       shl     eax, 9
       push    eax
       lodsd
       test    eax, eax
       jnz     @f
       inc     eax

@@:

       dec     eax
       shl     eax, 9
       push    eax
       push    str3
       call    [con_printf]
       add     esp, 4*4
       push    aRamdisk
       call    [con_printf]
       add     esp, 4
       add     esi, 8

print_name:

       push    esi
       push    str_final
       call    [con_printf]
       add     esp, 8

@@:

       lodsb
       test    al, al
       jnz     @b
       jmp     message

done:

       cmp     byte [logbuf+4], 0
       jz      @f
       push    str_skipped
       call    [con_printf]

@@:

we has output all driver data, now check console (did user press Esc?)

       call    [con_kbhit]
       test    al, al
       jz      mainloop
       call    [con_getch2]
       cmp     al, 27
       jnz     mainloop

</syntaxhighlight>

По нажатию Esc сообщим драйверу, что больше логгинг нам не нужен,

<syntaxhighlight lang="asm">

       mov     [ioctl_code], 3
       and     [inp_size], 0
       and     [outp_size], 0
       mov     eax, 68
       mov     ebx, 17
       mov     ecx, ioctl
       int     0x40

</syntaxhighlight>

завершим работу с консолью, убрав с экрана её окно,

<syntaxhighlight lang="asm">

       push    1
       call    [con_exit]

</syntaxhighlight>

и завершим работу программы.

<syntaxhighlight lang="asm"> exit:

       or      eax, -1
       int     0x40

</syntaxhighlight>

Данные программы:

<syntaxhighlight lang="asm"> dll_name db '/rd/1/console.obj',0 caption db 'FileMon',0 drivername db 'fmondrv',0 aCantLoadDriver db "Can't load driver",13,10,0

str0 db 'Monitoring file system calls... Press Esc to exit',10,0

str1 db 'Fn%2d: ',0 str2 db 'unknown subfunction %d, parameters: 0x%X, 0x%X, 0x%X, 0x%X, name ',0 str3 db 'read file, starting from 0x%X, %d bytes, to 0x%X; name ',0 str4 db 'read folder (%s version), starting from %d, %d blocks, to 0x%X; name ',0 str41 db 'ANSI',0 str42 db 'UNICODE',0 str5 db 'create/rewrite file, %d bytes from 0x%X; name ',0 str6 db 'write file, starting from 0x%X, %d bytes, from 0x%X; name ',0 str7 db 'set file size to %d bytes; name ',0 str8 db 'get file attributes to 0x%X; name ',0 str9 db 'set file attributes from 0x%X; name ',0 str10 db 'execute ',0 str10_1 db '(in debug mode) ',0 str10_2 db '(with parameters 0x%X) ',0 str11 db 'delete ',0 str12 db 'create folder ',0 str13 db 'unknown subfunction %d, parameters: 0x%X, 0x%X, 0x%X, name ',0 str14 db 'LBA read sector 0x%X to 0x%X from device ',0 str15 db '(obsolete!) query fs information of ',0 aRamdisk db '/rd/1/',0 str_final db '%s',10,0 str_skipped db '[Some information skipped]',10,0

align 4 label fn70 dword

       dd      fn70readfile
       dd      fn70readfolder
       dd      fn70create
       dd      fn70write
       dd      fn70setsize
       dd      fn70getattr
       dd      fn70setattr
       dd      fn70execute
       dd      fn70delete
       dd      fn70createfolder

align 4 myimport: dll_start dd aStart dll_ver dd aVersion con_init dd aConInit con_printf dd aConPrintf con_exit dd aConExit con_kbhit dd aConKbhit con_getch2 dd aConGetch2

               dd      0

aStart db 'START',0 aVersion db 'version',0 aConInit db 'con_init',0 aConPrintf db 'con_printf',0 aConExit db 'con_exit',0 aConKbhit db 'con_kbhit',0 aConGetch2 db 'con_getch2',0

i_end:

align 4 ioctl: hDriver dd  ? ioctl_code dd  ? input dd  ? inp_size dd  ? output dd  ? outp_size dd  ?

driver_ver dd  ? logbuf rb 16*1024+5

align 4 rb 2048 ; stack mem: </syntaxhighlight>

Загрузка и установка драйвера

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

По этой причине для загрузки внешних драйверов можно применить другие методы. Одним из оптимальных методов является использование программы "loaddrv", которая принимает в качестве аргумента командной строки имя драйвера без его расширения и загружает его через системную функцию 68.16. Например, при исполнении команды "loaddrv sdhci" программа загрузит драйвер "/sys/drivers/sdhci.sys". Данный способ загрузки позволяет без дополнительных изменений ядра добавить загрузку драйвера, прописав его в файл "/sys/settings/autorun.dat". Этот метод предпочтителен при добавлении новых драйверов в основной образ системы.

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

Существует также ситуация, когда драйвер необходимо загрузить во время инициализации самого ядра, например для работы USB подсистемы ядро само загружает драйвера хост-контроллеров и драйвера классов устройств. Загрузка драйверов из ядра аналогична загрузке через системную функцию 68.16. Данный метод не рекомендуется, но может быть применён в специализированных под определённое железо сборках ядра.

Краткое описание экспортируемых ядром функций

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

Мьютексы и семафоры

В большинстве случаев для обработки нескольких одновременных вызовов функций необходимы средства синхронизации и блокировки доступа к ресурсам, с которыми работает данная функция. Для обеспечения такой блокировки драйвер импортирует функции, реализующие мьютексы и семафоры <syntaxhighlight lang="C"> struct mutex { struct list_head wait_list; atomic_t count; };

void fastcall mutex_init(struct mutex *lock); void fastcall mutex_lock(struct mutex *lock); void fastcall mutex_unlock(struct mutex *lock); void fastcall init_rwsem(struct rw_semaphore *sem); void fastcall down_read(struct rw_semaphore *sem); void fastcall down_write(struct rw_semaphore *sem); void fastcall up_read(struct rw_semaphore *sem); void fastcall up_write(struct rw_semaphore *sem); </syntaxhighlight>

Работа с подсистемой событий

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

Интерфейс работы с дисковой подсистемой

Ядро предоставляет интерфейс для добавления, удаления и работы с логическими дисками. Данный интерфейс позволяет реализовывать драйвера различных дисковых устройств, вне зависимости от их физического интерфейса, в том числе и виртуальные.
Для добавления нового диска используется функция DiskAdd. Описание передаваемых в неё параметров приведено ниже по тексту.
Для удаления диска используется функция DiskDel, в которую передаётся полученный ранее указатель. Эта функция удаляет диск из единого списка логических дисков. <syntaxhighlight lang="C"> void* DiskAdd(DISKFUNC* functions, const char* name, uint32_t userdata, uint32_t flags); void DiskDel(void* hDisk); void DiskMediaChanged(void* hDisk, int newstate);

Flags for add new disk

DISK_NO_INSERT_NOTIFICATION = 1 </syntaxhighlight>

Некоторые диски имеют возможность изменения содержимого, например CD приводы, и по этому в ядре предусмотрена функция "DiskMediaChanged". Эта функция информирует ядро о том, что носитель был вставлен, удален или изменен. Значение "newstate" должно быть равно нулю, если в данный момент носитель не вставлен, и ненулевым в противном случае. Эта функция не должна вызываться с ненулевым значением newstate ни из одной callback функции. Эта функция не должна вызываться, если активен другой вызов этой функции.

Если при добавлении диска был установлен флаг DISK_NO_INSERT_NOTIFICATION, то драйвер не должен вызывать функцию "DiskMediaChanged" и ядро будет проверять наличие носителя при каждой операции. Данный подход может использоваться для дисков, подключение или изъятие носителей которых не может быть определено драйвером, например данный флаг применяется в драйвере контроллера floppy дисков.

Callback функции драйвера диска

Как уже было описано выше, при добавлении нового диска, драйвер должен передать ядру указатель на структуру DISKFUNC, которая содержит общий размер структуры(поле strucsize) и массив указателей на функции. Если функция отсутствует, то вместо неё должен быть записан ноль. <syntaxhighlight lang="asm"> struct DISKFUNC

       strucsize       dd ?
       close           dd ?
       closemedia      dd ?
       querymedia      dd ?
       read            dd ?
       write           dd ?
       flush           dd ?
       adjust_cache_size       dd ?
       LoadTray        dd ?

ends

Error codes for callback functions.

DISK_STATUS_OK = 0 ; success DISK_STATUS_GENERAL_ERROR = -1; if no other code is suitable DISK_STATUS_INVALID_CALL = 1 ; invalid input parameters DISK_STATUS_NO_MEDIA = 2 ; no media present DISK_STATUS_END_OF_MEDIA = 3 ; end of media while reading/writing data DISK_STATUS_NO_MEMORY = 4 ; insufficient memory for driver operation </syntaxhighlight>

<syntaxhighlight lang="C"> void close(void* userdata); </syntaxhighlight> Необязательная функция. Функция которая освобождает все ресурсы, зависящие от драйвера, для диска.

<syntaxhighlight lang="C"> void closemedia(void* userdata); </syntaxhighlight> Необязательная функция, может отсутствовать если носитель не является съемным. Функция, вызов которой информирует драйвер о том, что ядро завершило всю обработку с текущим носителем. Если носитель удален, драйвер должен отклонять все запросы к этому носителю с помощью команды DISK_STATUS_NO_MEDIA, даже если вставлен новый носитель, до тех пор, пока не будет вызвана эта функция. Если носитель удален, новый вызов 'disk_media_changed' не разрешен до тех пор, пока не будет вызвана эта функция.

<syntaxhighlight lang="C"> int querymedia(void* userdata, DISKMEDIAINFO* info);

Media flags. Represent bits in DISKMEDIAINFO.Flags.

DISK_MEDIA_READONLY = 1

struct DISKMEDIAINFO

       Flags           dd ? ; Combination of DISK_MEDIA_* bits.
       SectorSize      dd ? ; Size of the sector.
       Capacity        dq ? ; Size of the media in sectors.
       LastSessionSector       dd ? ; Number last session sectors for CDFS

ends

</syntaxhighlight> Обязательная функция, которая производит заполнение структуры DISKMEDIAINFO и возвращает DISK_STATUS_* код.

<syntaxhighlight lang="C"> int read(void* userdata, void* buffer, __int64 startsector, int* numsectors); </syntaxhighlight> Обязательная функция. Функция для чтения секторов диска в буфер "buffer", начиная с сектора "startsector". Количество считываемых секторов находится по указателю "numsectors". Функция должна возвращать DISK_STATUS_* код и записать количество успешно прочитанных секторов по указателю "numsectors". Указатель на буфер является виртуальным адресом.

<syntaxhighlight lang="C">

int write(void* userdata, void* buffer, __int64 startsector, int* numsectors);

</syntaxhighlight> Необязательная функция. Функция для записи секторов диска из буфера "buffer", начиная с сектора "startsector". Количество записываемых секторов находится по указателю "numsectors".Функция должна возвращать DISK_STATUS_* код и записать количество успешно записанных секторов по указателю "numsectors". Указатель на буфер является виртуальным адресом.

<syntaxhighlight lang="C"> int flush(void* userdata); </syntaxhighlight> Необязательная функция. Функция очищает внутренний кэш устройства и возвращает DISK_STATUS_* код. Обратите внимание, что функции чтения/записи вызываются менеджером кэша, поэтому драйвер не должен создавать программный кэш. Эта функция реализована для очистки аппаратного кэша, если он существует.

<syntaxhighlight lang="C"> unsigned int adjust_cache_size(void* userdata, unsigned int suggested_size); </syntaxhighlight> Необязательная функция. Функция возвращает размер кэша для данного устройства в байтах. При возврате нуля программный кэш не используется.

<syntaxhighlight lang="C"> int LoadTray(void* userdata, int flags); </syntaxhighlight> Необязательная функция. Функция для загрузки/выгрузки носителя, операция определяется флагом: 0 - загрузить, 1 - выгрузить. Функция возвращает DISK_STATUS_* код.

Интерфейс работы со встроенными устройствами

Встроенные устройства включают в себя всевозможные устройства, расположенные непосредственно на материнской плате или подключаемым к внутренним шинам, например ISA или PCIe.

Прерывания

Прерывания используются многими встроенными устройствами для оповещения драйверов об изменении их состояния, например, для оповещения о подключении сетевого кабеля или нажатие на клавишу клавиатуры. Для добавления своего обработчика прерывания, драйвер должен вызвать функцию в которую передаётся номер прерывания, указатель на функцию обработчика прерывания и необходимые ей данные в виде 4 байт. <syntaxhighlight lang="C"> int32_t stdcall AttachIntHandler(uint32_t irq, void* handler, uint32_t userdata); </syntaxhighlight> Обработчик прерывания должен соблюдать CDECL соглашение о вызовах и принимать необходимые ей данные в виде 4 байт. <syntaxhighlight lang="C"> int32_t cdecl irq_handler(uint32_t userdata); </syntaxhighlight> Если вызванный обработчик прерывания не обнаружил взаимодействия от настроенного на него контроллера, то обработчик должен вернуть 1 в качестве ответа. В иных случаях обработчик должен вернуть ноль.

Шина PCI

Большинство подключённых к ПК устройств используют шину PCI(PCIe). Для работы с этой шиной драйвера импортируют ряд функций, через которые можно прочесть и записать данные в конфигурационное пространство PCI устройства. Подробнее об этом говорится в статье PCI.
Ядро экспортирует как сами функции работы с PCI шиной, так и функцию GetPCIList для получения указателя на список найденных им устройств. Этот список устройств представляет из себя двусвязный список структур PCIDEV. На основе этой структуры можно произвести поиск PCI устройства без обращения к самой шине, что упрощает написание самого драйвера.

<syntaxhighlight lang="asm">

struct PCIDEV

       bk              dd ?
       fd              dd ?
       vendor_device_id dd ?
       class           dd ?
       devfn           db ?
       bus             db ?
                       rb 2
       owner           dd ? ; pointer to SRV or 0

ends </syntaxhighlight> Для чтения и записи используется набор функций со схожим интерфейсом. <syntaxhighlight lang="C"> uint8_t stdcall PciRead8(uint23_t bus, uint32_t devfn, uint32_t reg); uint16_t stdcall PciRead16(uint23_t bus, uint32_t devfn, uint32_t reg); uint32_t stdcall PciRead32(uint23_t bus, uint32_t devfn, uint32_t reg);

void stdcall PciWrite8(uint23_t bus, uint32_t devfn, uint32_t reg, uint32_t value); void stdcall PciWrite16(uint23_t bus, uint32_t devfn, uint32_t reg, uint32_t value); void stdcall PciWrite32(uint23_t bus, uint32_t devfn, uint32_t reg, uint32_t value);

PCIDEV* fastcall GetPCIList(); </syntaxhighlight> Кроме этих функций существует также функция PciApi, через которую также возможно осуществить чтение и запись конфигурационного пространства. Интерфейс этой функции повторяет интерфейс системной функции 62.

Шина USB

Подробное описание интерфейса находится в статье USB API.

Порты ввода/вывода

Драйверы могут взаимодействовать со всеми портами ввода/вывода, но для избежание вредоносного взаимодействия со стороны пользовательского ПО необходимо зарезервировать необходимые порты через функцию ReservePortArea.

<syntaxhighlight lang="asm">

reserve/free group of ports

* eax = 46 - number function

* ebx = 0 - reserve, 1 - free

* ecx = number start arrea of ports

* edx = number end arrea of ports (include last number of port)

Return value

* eax = 0 - succesful

* eax = 1 - error

* The system has reserve this ports

0..0x2d, 0x30..0x4d, 0x50..0xdf, 0xe5..0xff (include last number of port).

destroys all registers

ReservePortArea </syntaxhighlight> Кроме этого ядро при загрузке само резервирует некоторый диапазон портов:

* 0-45
* 48-77
* 80-223
* 229-255

Многие устройства предоставляют интерфейс работы через спроецированные на память регистры контроллера. Для работы с этими регистрами используется функция MapIoMem, в которую передаётся базовый адрес физической памяти, на который указывает устройство(во многих PCI устройствах такой адрес будет находится в BAR регистрах конфигурационного пространства PCI) размер и флаги страниц памяти. Функция вернёт указатель на базовый адрес в виртуальной памяти либо ноль в случае неудачи. <syntaxhighlight lang="C"> void* stdcall MapIoMem(void* base, uint32_t size, uint32_t flags); </syntaxhighlight>

Интерфейс взаимодействия с сетевой подсистемой

Краткое описание интерфейса находится в статье о сетевых драйверах.

Интерфейс взаимодействия с графической подсистемой

Взаимодействие с графической подсистемой происходит в основном через экспортируемую ядром структуру display_t и нескольких дополнительных функций. Получить структуру display_t можно через вызов функции "GetDisplay".

Регистрация аппаратного курсора

Для изменения функций курсора указатели на них изменяются в структуре display_t. TODO: написать описание функций и пример аппаратного курсора для AMD видеокарты.

Работа с фреймбуфером

Для изменения размеров области вывода изображения в фреймбуфер, без изменения его физического расположения(адрес не меняется ), применяется функция "SetScreen". <syntaxhighlight lang="asm">

in

eax - new Screen_Max_X

ecx - new BytesPerScanLine

edx - new Screen_Max_Y

set_screen: </syntaxhighlight>

Кроме изменения размера возможно изменить физическое расположение самого фреимбуфера с помощью функции "SetFramebuffer" <syntaxhighlight lang="asm"> struct FRB

       list            LHEAD
       magic           rd 1
       handle          rd 1
       destroy         rd 1

       width           rd 1
       height          rd 1
       pitch           rd 1
       format          rd 1
       private         rd 1
       pde             rd 8

ends </syntaxhighlight> <syntaxhighlight lang="C"> void fastcall SetFramebuffer(struct FBR* _fbr); </syntaxhighlight>

Работа с оконной подсистемой

Для взаимодействия с оконной подсистемой ядро экспортирует функцию "GetWindowRect" с помощью которой можно получить координаты границ окна текущего потока. <syntaxhighlight lang="C"> void fastcall get_window_rect(struct RECT* rc); </syntaxhighlight>

Остальные импортируемые ядром функции

Функция для драйверов мыши

<syntaxhighlight lang="C"> void stdcall SetMouseData(uint32_t BtnState, uint32_t XMoving, uint32_t YMoving, uint32_t VScroll, uint32_t HScroll); </syntaxhighlight>

Функции для драйверов клавиатуры

<syntaxhighlight lang="C"> KEYBOARD* stdcall RegKeyboard(KBDFUNC* func, uint32_t userdata); </syntaxhighlight>

<syntaxhighlight lang="C"> void stdcall DelKeyboard(KEYBOARD* handle); </syntaxhighlight>

<syntaxhighlight lang="C"> void fastcall SetKeyboardData(uint32_t scancode); </syntaxhighlight>

Функции таймера

<syntaxhighlight lang="C"> void* TimerHS(unsigned int deltaStart, unsigned int interval,

             void* timerFunc, void* userData);

void CancelTimerHS(void* hTimer); </syntaxhighlight> TODO

Звуковая подсистема

Краткое описание интерфейса находится в статье о драйверах звуковых карт.

Полезные макросы языка fasm и особенности их применения

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