1.1. Краткое описание

В этом разделе рассматривается процесс загрузки и инициализации системы начиная с BIOS (firmware) POST и заканчивая созданием первого пользовательского процесса. Начальные шаги загрузки системы сильно архитектурно зависимы, и поэтому в качестве примера будет рассматриваться архитектура IA-32.

1.2. Обзор

Компьютер под управлением FreeBSD может быть загружен несколькими способами, из которых самым обычным является загрузка с жёсткого диска, на котором установлена ОС. Этот вариант мы здесь и рассмотрим. Процесс загрузки осуществляется в несколько этапов:

• BIOS POST

• этап boot0

• этап boot2

• стадия загрузчика

• инициализация ядра

Стадии boot0 и boot2 являются соответственно стадиями загрузки 1 и 2, описанными в boot(8), как первые стадии трёх-этапного процесса загрузки FreeBSD. Во время прохождения каждой стадии на экран выводится различная информация, поэтому вы можете визуально определить стадию, на которой находитесь, с помощью нижеприведённой таблицы. Однако учтите, что на различных машинах сами данные могут различаться:

F1    FreeBSD
F2    BSD
F5    Disk 2

>>FreeBSD/i386 BOOT
Default: 1:ad(1,a)/boot/loader
boot:

BTX loader 1.0 BTX version is 1.01
BIOS drive A: is disk0
BIOS drive C: is disk1
BIOS 639kB/64512kB available memory
FreeBSD/i386 bootstrap loader, Revision 0.8
Console internal video/keyboard
(jkh@bento.freebsd.org, Mon Nov 20 11:41:23 GMT 2000)
/kernel text=0x1234 data=0x2345 syms=[0x4+0x3456]
Hit [Enter] to boot immediately, or any other key for command prompt
Booting [kernel] in 9 seconds..._

Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD 4.6-RC #0: Sat May  4 22:49:02 GMT 2002
    devnull@kukas:/usr/obj/usr/src/sys/DEVNULL
Timecounter "i8254"  frequency 1193182 Hz

1.3. BIOS POST

При включении питания компьютера регистрам процессора присваиваются некоторые заранее определённые значения. Одним из регистров является регистр указателя на инструкцию (instruction pointer), и его значение после включения питания компьютера точно определено - это 32-битное значение 0xfffffff0. Регистр указателя на инструкцию указывает на код, который должен быть выполнен процессором. Ещё один регистр - 32-битный регистр управления cr1, значение которого сразу после загрузки равно 0. Один из битов cr1, а именно бит PE (Protected Enabled), указывает на то, работает ли процессор в защищённом (Protected mode) или в реальном режиме (Real mode). Поскольку во время загрузки этот бит не установлен, процессор загружается в реальном режиме. Реальный режим, помимо других вещей, определяет, что линейные и физические адреса идентичны.

Значение 0xfffffff0 немного меньше, чем 4Гб; поэтому если машинa не имеет 4Гб физической памяти, то она не сможет обратиться к существующему адресу в памяти. Аппаратное обеспечение компьютера преобразовывает этот адрес так, что он указывает на область памяти BIOS.

BIOS расшифровывается, как Basic Input Output System (Базовая Система Ввода Вывода) и представляет собой микросхему на материнской плате с относительно небольшим объёмом памяти, доступной только для чтения (ROM). В этой памяти хранятся различные низкоуровневые процедуры, являющиеся специфическими для этого аппаратного обеспечения. Итак, процессор вначале перейдёт на адрес 0xfffffff0, который на самом деле находится в области памяти BIOS. Обычно по этому адресу располагается инструкция перехода к процедурам BIOS POST.

POST расшифровывается, как Power On Self Test (Самотестирование при включении питания). Это набор процедур, включающий проверку памяти, проверку системной шины и другие низкоуровневые процедуры, при помощи которых процессор может должным образом инициализировать компьютер. Важным шагом на данной стадии является определение загрузочного устройства. Все современные BIOS позволяют устанавливать загрузочное устройство вручную, поэтому вы можете загружаться с флоппи-диска, компакт-диска, жёсткого диска и т.д.

Самое последние действие POST - это инструкция INT 0x19. Эта инструкция читает 512 байт из первого сектора загрузочного устройства и записывает их в память по адресу 0x7c00. Термин первый сектор происходит от архитектуры жёсткого диска, в котором магнитный диск разделён на цилиндрические дорожки. Дорожки пронумерованы и каждая из них разделена на сектора (обычно 64). Нулевая дорожка располагается на внешний стороне у самого края магнитного диска, и её первый сектор (дорожки или цилиндры нумеруются с нуля, но сектора - с единицы) имеет особое значение. Его также называют Главная Загрузочная Запись (Master Boot Record), или сокращённо - MBR. Оставшиеся сектора на первой дорожке никогда не используются [1].

1.4. Этап boot0

Обратите внимание на файл /boot/boot0. Это маленький файл размером 512 байт, и именно его процедура установки FreeBSD запишет в MBR вашего жёсткого диска, если вы выбрали опцию ''bootmanager'' во время установки.

Как уже отмечалось, инструкция INT 0x19 загружает MBR, т.е. содержимое boot0, в память по адресу 0x7c00. Взгляните на файл sys/boot/i386/boot0/boot0.s, который вам поможет разобраться в том, что происходит на данной стадии. Это менеджер загрузки, написанный Робертом Нордиером (Robert Nordier).

MBR, или boot0, содержит специальную структуру - таблицу разделов (partition table), располагающуюся со смещения 0x1be. Она содержит 4 записи по 16 байт каждая, называемые записями о разделах, которые указывают, каким образом диск(и) делится на разделы, или слайсы, если пользоваться терминологией FreeBSD. Один байт из этих 16 указывает на то, является ли раздел (слайс) загрузочным, или нет. Только одна запись должна содержать этот флаг установленным, в противном случае код boot0 не будет выполняться далее.

Запись о разделе содержит следующие поля:

• 1 байт, определяющий тип файловой системы

• 1 байт для загрузочного флага

• шести-байтовый дескриптор в формате CHS

• восьми-байтовый дескриптор в формате LBA

Дескриптор записи о разделе хранит информацию о точном расположении раздела на диске. Оба дескриптора CHS и LBA описывают одну и ту же информацию, но каждый по-своему: LBA (Logical Block Addressing, Логическая блоковая адресация) содержит информацию о начальном секторе и длине раздела, в то время как CHS (Cylinder Head Sector, Цилиндр-Головка-Сектор) хранит координаты начального и конечного секторов раздела.

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

• модифицирует загрузочный флаг выбранного раздела, делая его загрузочным и сбрасывает этот флаг с предыдущего загрузочного раздела

• сохраняет себя на диск, чтобы запомнить какой раздел (слайс) был выбран для загрузки; таким образом, в следующий раз он будет разделом для загрузки по умолчанию

• загружает первый сектор выбранного раздела (слайса) в память и передаёт управление туда

Какие данные должны располагаться в самом первом секторе загрузочного раздела (слайса), в нашем случае, слайса FreeBSD? Как вы уже наверное догадались, это boot2.

1.5. Этап boot2

Вам наверное интересно, почему за boot0 следует boot2, а не boot1. На самом деле, в каталоге /boot также есть и файл boot1 размером 512 байт. Он используется для загрузки с флоппи-диска и выполняет ту же работу, что и boot0 при загрузке с жёсткого диска: он обнаруживает boot2 и передаёт ему управление.

Вы могли заметить, что также существует и файл /boot/mbr. Это упрощённая версия boot0. Код mbr не предоставляет меню для пользователя: он просто слепо загружает раздел, помеченный, как активный.

Исходные тексты boot2 находятся в каталоге sys/boot/i386/boot2/, а сам исполняемый файл в /boot. Файлы boot0 и boot2 из /boot не используются в процессе загрузки, однако используются такими утилитами, как boot0cfg. Действительное местоположение boot0 - в MBR, а boot2 - в начале загрузочного слайса FreeBSD. Эти места не находятся под контролем файловой системы, поэтому являются невидимыми для таких команд, как ls.

Основная задача boot2 состоит в загрузке файла /boot/loader, который является третьей стадией процесса загрузки. Код из boot2 не может использовать какие-либо сервисы вроде open() и read(), потому как ядро ещё не загружено. Он должен просмотреть жёсткий диск, зная о структуре файловой системы, найти файл /boot/loader, считать его в память с помощью средств BIOS и затем передать управление в точку входа загрузчика.

Кроме того, boot2 с помощью командной строки позволяет пользователю загрузить загрузчик с другого диска, юнита, слайса и раздела.

Двоичный файл boot2 создаётся особым образом:

sys/boot/i386/boot2/Makefile
boot2: boot2.ldr boot2.bin ${BTX}/btx/btx
    btxld -v -E ${ORG2} -f bin -b ${BTX}/btx/btx -l boot2.ldr \
        -o boot2.ld -P 1 boot2.bin

Этот фрагмент Makefile показывает, что btxld(8) используется для компоновки двоичного файла. BTX, чьё название происходит от BooT eXtender (расширитель загрузки) является фрагментом когда, предоставляющим окружение защищённого режима для программы, называемой клиентом, c которой он скомпонован. Итак, boot2 - это BTX клиент, т.е. он использует сервисы предоставляемые BTX.

Утилита btxld является компоновщиком. Она связывает два двоичных файла. Разница между btxld(8) и ld(1) заключается в том, что ld обычно компонует объектные файлы в разделяемый объект или в исполняемый файл, в то время как btxld связывает объектный файл с BTX, создавая двоичный файл, пригодный для размещения в начале раздела для загрузки системы.

boot0 передаёт управление в точку входа BTX. После этого BTX переключает процессор в защищённый режим и подготавливает простое окружение перед вызовом клиента. Это включает в себя:

• виртуальный режим v86. Означает, что BTX является v86 монитором. Инструкции реального режима, такие как pushf, popf, cli, sti доступны для клиента.

• Устанавливается Таблица Дескрипторов Прерываний (Interrupt Descriptor Table, IDT). Таким образом, все аппаратные прерывания перенаправляются к стандартным процедурам BIOS, а также устанавливается прерывание 0x30 для того, чтобы быть шлюзом к системным вызовам.

• Определены два системных вызова: exec и exit:

  sys/boot/i386/btx/lib/btxsys.s:
          .set INT_SYS,0x30       # Interrupt number
  #
  # System call: exit
  #
  __exit:     xorl %eax,%eax          # BTX system
          int $INT_SYS            #  call 0x0
  #
  # System call: exec
  #
  __exec:     movl $0x1,%eax          # BTX system
          int $INT_SYS            #  call 0x1
  

BTX создаёт Глобальную Таблицу Дескрипторов (Global Descriptors Table, GDT):

sys/boot/i386/btx/btx/btx.s:
gdt:        .word 0x0,0x0,0x0,0x0       # Null entry
        .word 0xffff,0x0,0x9a00,0xcf    # SEL_SCODE
        .word 0xffff,0x0,0x9200,0xcf    # SEL_SDATA
        .word 0xffff,0x0,0x9a00,0x0 # SEL_RCODE
        .word 0xffff,0x0,0x9200,0x0 # SEL_RDATA
        .word 0xffff,MEM_USR,0xfa00,0xcf# SEL_UCODE
        .word 0xffff,MEM_USR,0xf200,0xcf# SEL_UDATA
        .word _TSSLM,MEM_TSS,0x8900,0x0 # SEL_TSS

Код и данные клиента начинаются с адреса MEM_USR (0xa000), а селектор (SEL_UCODE) указывает на сегмент кода клиента. Дескриптор SEL_UCODE имеет Уровень Привилегий Дескриптора (Descriptor Privilege Level, DPL) равный 3, который является наименьшим уровнем привилегий. Однако обработчик инструкции INT 0x30 располагается в сегменте, на который указывает селектор SEL_SCODE (код супервизора), как показано в коде создания IDT:

       mov $SEL_SCODE,%dh      # Segment selector
init.2:     shr %bx             # Handle this int?
        jnc init.3          # No
        mov %ax,(%di)           # Set handler offset
        mov %dh,0x2(%di)        #  and selector
        mov %dl,0x5(%di)        # Set P:DPL:type
        add $0x4,%ax            # Next handler

Таким образом, когда клиент вызывает __exec() код будет исполнен с наивысшими привилегиями. Это позволяет ядру позже, при необходимости, изменять структуры данных защищённого режима, таких как таблицы страниц, GDT, IDT и т.д.

boot2 определяет важную структуру struct bootinfo. Эта структура инициализируется кодом boot2 и передаётся загрузчику, а затем дальше ядру. Некоторые поля данной структуры устанавливаются boot2, остальные загрузчиком. Кроме всей прочей информации, эта структура содержит имя файла ядра, BIOS геометрию жёсткого диска, BIOS номер привода загрузочного устройства, доступную физическую память, указатель envp и т.д. Вот её определение:

/usr/include/machine/bootinfo.h
struct bootinfo {
    u_int32_t   bi_version;
    u_int32_t   bi_kernelname;      /* represents a char * */
    u_int32_t   bi_nfs_diskless;    /* struct nfs_diskless * */
                /* End of fields that are always present. */
#define bi_endcommon    bi_n_bios_used
    u_int32_t   bi_n_bios_used;
    u_int32_t   bi_bios_geom[N_BIOS_GEOM];
    u_int32_t   bi_size;
    u_int8_t    bi_memsizes_valid;
    u_int8_t    bi_bios_dev;        /* bootdev BIOS unit number */
    u_int8_t    bi_pad[2];
    u_int32_t   bi_basemem;
    u_int32_t   bi_extmem;
    u_int32_t   bi_symtab;      /* struct symtab * */
    u_int32_t   bi_esymtab;     /* struct symtab * */
                /* Items below only from advanced bootloader */
    u_int32_t   bi_kernend;     /* end of kernel space */
    u_int32_t   bi_envp;        /* environment */
    u_int32_t   bi_modulep;     /* preloaded modules */
};

boot2 в бесконечном цикле ожидает пользовательского ввода, после чего вызывает load(). Если же пользователь ничего не нажал, цикл прерывается по тайм-ауту и load() загрузит файл по умолчанию (/boot/loader). Функции ino_t lookup(char *filename) и int xfsread(ino_t inode, void *buf, size_t nbyte) используются для считывания содержимого файла в память. /boot/loader является двоичным файлом формата ELF, однако его ELF заголовок дополнительно содержит структуру struct exec формата a.out. load() просматривает ELF заголовок загрузчика, загружая содержимое /boot/loader в память и передаёт управление в точку входа загрузчика:

sys/boot/i386/boot2/boot2.c:
    __exec((caddr_t)addr, RB_BOOTINFO | (opts & RBX_MASK),
       MAKEBOOTDEV(dev_maj[dsk.type], 0, dsk.slice, dsk.unit, dsk.part),
       0, 0, 0, VTOP(&bootinfo));

1.6. Стадия загрузчика

Загрузчик (loader) также является клиентом BTX. Я не буду здесь его детально описывать, потому как есть исчерпывающая страница руководства loader(8), написанная Майком Смитом (Mike Smith). Нижележащие механизмы и BTX были описаны выше.

Основной задачей загрузчика является загрузка ядра. Когда ядро загружено в память, оно вызывается загрузчиком:

sys/boot/common/boot.c:
    /* Call the exec handler from the loader matching the kernel */
    module_formats[km->m_loader]->l_exec(km);

1.7. Инициализация ядра

Куда именно выполнение передаётся загрузчиком, т.е. что является самой точкой входа в ядро. Давайте взглянем на команду, которая компонует ядро:

sys/conf/Makefile.i386:
ld -elf -Bdynamic -T /usr/src/sys/conf/ldscript.i386  -export-dynamic \
-dynamic-linker /red/herring -o kernel -X locore.o \
<lots of kernel .o files>

Несколько интересных вещей можно заметить в данной строке. Во-первых, ядро - это динамически скомпонованный двоичный файл формата ELF, однако динамическим компоновщиком для ядра является определённо фиктивный файл /red/herring. Во-вторых, просмотр файла sys/conf/ldscript.i386 даёт представление о том, с какими опциями используется ld при компиляции ядра. Одна из первых строк файла

sys/conf/ldscript.i386:
ENTRY(btext)

говорит о том, что точка входа в ядро - символ `btext'. Данный символ определён в locore.s:

sys/i386/i386/locore.s:
    .text
/**********************************************************************
 *
 * This is where the bootblocks start us, set the ball rolling...
 *
 */
NON_GPROF_ENTRY(btext)

Первое, что происходит - это установка регистра EFLAGS в предопределённое значение 0x00000002, затем инициализируются все сегментные регистры:

sys/i386/i386/locore.s
/* Don't trust what the BIOS gives for eflags. */
    pushl   $PSL_KERNEL
    popfl

/*
 * Don't trust what the BIOS gives for %fs and %gs.  Trust the bootstrap
 * to set %cs, %ds, %es and %ss.
 */
    mov %ds, %ax
    mov %ax, %fs
    mov %ax, %gs

btext вызывает процедуры recover_bootinfo(), identify_cpu(), create_pagetables(), которые также определены в locore.s. Далее следует описание того, что они делают:

Следующие шаги - включение VME, если процессор его поддерживает:

   testl   $CPUID_VME, R(_cpu_feature)
    jz  1f
    movl    %cr4, %eax
    orl $CR4_VME, %eax
    movl    %eax, %cr4

Затем включение страничного режима:

/* Now enable paging */
    movl    R(_IdlePTD), %eax
    movl    %eax,%cr3           /* load ptd addr into mmu */
    movl    %cr0,%eax           /* get control word */
    orl $CR0_PE|CR0_PG,%eax     /* enable paging */
    movl    %eax,%cr0           /* and let's page NOW! */

Следующие три строчки кода появляются из-за включения страничного режима, потому как для продолжения выполнения в виртуальном адресном пространстве необходим переход:

   pushl   $begin              /* jump to high virtualized address */
    ret

/* now running relocated at KERNBASE where the system is linked to run */
begin:

Вызывается функция init386() с указателем на первую свободную физическую страницу, после чего происходит вызов mi_startup(). init386 является архитектурно-зависимой функцией инициализации, а mi_startup() - архитектурно-независимой (префикс 'mi_' означает машинно-независимый (Machine Independent)). Ядро никогда не возвращается из mi_startup(), и вызвав её, оно заканчивает загрузку:

sys/i386/i386/locore.s:
    movl    physfree, %esi
    pushl   %esi                /* value of first for init386(first) */
    call    _init386            /* wire 386 chip for unix operation */
    call    _mi_startup         /* autoconfiguration, mountroot etc */
    hlt     /* never returns to here */

sys/i386/i386/machdep.c:
        kern_envp = (caddr_t)bootinfo.bi_envp + KERNBASE;

    /* Init basic tunables, hz etc */
    init_param1();

sys/kern/subr_param.c
    hz = HZ;
    TUNABLE_INT_FETCH("kern.hz", &hz);

/usr/src/sys/sys/kernel.h
#define TUNABLE_INT_FETCH(path, var)    getenv_int((path), (var))

sys/i386/i386/machdep.c:
union descriptor gdt[NGDT * MAXCPU];    /* global descriptor table */

sys/i386/include/segments.h:
/*
 * Entries in the Global Descriptor Table (GDT)
 */
#define GNULL_SEL   0   /* Null Descriptor */
#define GCODE_SEL   1   /* Kernel Code Descriptor */
#define GDATA_SEL   2   /* Kernel Data Descriptor */
#define GPRIV_SEL   3   /* SMP Per-Processor Private Data */
#define GPROC0_SEL  4   /* Task state process slot zero and up */
#define GLDT_SEL    5   /* LDT - eventually one per process */
#define GUSERLDT_SEL    6   /* User LDT */
#define GTGATE_SEL  7   /* Process task switch gate */
#define GBIOSLOWMEM_SEL 8   /* BIOS low memory access (must be entry 8) */
#define GPANIC_SEL  9   /* Task state to consider panic from */
#define GBIOSCODE32_SEL 10  /* BIOS interface (32bit Code) */
#define GBIOSCODE16_SEL 11  /* BIOS interface (16bit Code) */
#define GBIOSDATA_SEL   12  /* BIOS interface (Data) */
#define GBIOSUTIL_SEL   13  /* BIOS interface (Utility) */
#define GBIOSARGS_SEL   14  /* BIOS interface (Arguments) */

sys/i386/i386/machdep.c:
static struct gate_descriptor idt0[NIDT];
struct gate_descriptor *idt = &idt0[0]; /* interrupt descriptor table */

sys/i386/i386/machdep.c:
    setidt(0x80, &IDTVEC(int0x80_syscall),
            SDT_SYS386TGT, SEL_UPL, GSEL(GCODE_SEL, SEL_KPL));

sys/i386/i386/machdep.c:
    cninit();
/* skipped */
#ifdef DDB
    kdb_init();
    if (boothowto & RB_KDB)
        Debugger("Boot flags requested debugger");
#endif

/usr/include/machine/segments.h
#define LSYS5CALLS_SEL  0   /* forced by intel BCS */
#define LSYS5SIGR_SEL   1
#define L43BSDCALLS_SEL 2   /* notyet */
#define LUCODE_SEL  3
#define LSOL26CALLS_SEL 4   /* Solaris >= 2.6 system call gate */
#define LUDATA_SEL  5
/* separate stack, es,fs,gs sels ? */
/* #define  LPOSIXCALLS_SEL 5*/ /* notyet */
#define LBSDICALLS_SEL  16  /* BSDI system call gate */
#define NLDT        (LBSDICALLS_SEL + 1)

sys/kern/kern_init.c:
    struct  proc proc0;

sys/kern/init_main.c:
    for (sipp = sysinit; *sipp; sipp++) {

        /* ... skipped ... */

        /* Call function */
        (*((*sipp)->func))((*sipp)->udata);
        /* ... skipped ... */
    }

sys/kern/init_main.c:
static void
print_caddr_t(void *data __unused)
{
    printf("%s", (char *)data);
}
SYSINIT(announce, SI_SUB_COPYRIGHT, SI_ORDER_FIRST, print_caddr_t, copyright)

/usr/include/sys/kernel.h:
      #define C_SYSINIT(uniquifier, subsystem, order, func, ident) \
      static struct sysinit uniquifier ## _sys_init = { \ subsystem, \
      order, \ func, \ ident \ }; \ DATA_SET(sysinit_set,uniquifier ##
      _sys_init);

#define SYSINIT(uniquifier, subsystem, order, func, ident)  \
    C_SYSINIT(uniquifier, subsystem, order,         \
    (sysinit_cfunc_t)(sysinit_nfunc_t)func, (void *)ident)

/usr/include/linker_set.h
#define MAKE_SET(set, sym)                      \
    static void const * const __set_##set##_sym_##sym = &sym;   \
    __asm(".section .set." #set ",\"aw\"");             \
    __asm(".long " #sym);                       \
    __asm(".previous")
#endif
#define TEXT_SET(set, sym) MAKE_SET(set, sym)
#define DATA_SET(set, sym) MAKE_SET(set, sym)

static struct sysinit announce_sys_init = {
    SI_SUB_COPYRIGHT,
    SI_ORDER_FIRST,
    (sysinit_cfunc_t)(sysinit_nfunc_t)  print_caddr_t,
    (void *) copyright
};

static void const *const __set_sysinit_set_sym_announce_sys_init =
    &announce_sys_init;
__asm(".section .set.sysinit_set" ",\"aw\"");
__asm(".long " "announce_sys_init");
__asm(".previous");

% objdump -h /kernel
  7 .set.cons_set 00000014  c03164c0  c03164c0  002154c0  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  8 .set.kbddriver_set 00000010  c03164d4  c03164d4  002154d4  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  9 .set.scrndr_set 00000024  c03164e4  c03164e4  002154e4  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 10 .set.scterm_set 0000000c  c0316508  c0316508  00215508  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 11 .set.sysctl_set 0000097c  c0316514  c0316514  00215514  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 12 .set.sysinit_set 00000664  c0316e90  c0316e90  00215e90  2**2
                  CONTENTS, ALLOC, LOAD, DATA

sys/kern/init_main.c:
      extern struct linker_set sysinit_set; /* XXX */

/usr/include/linker_set.h:
  struct linker_set {
    int ls_length;
    void    *ls_items[1];       /* really ls_length of them, trailing NULL */
};

/usr/include/sys/kernel.h:
enum sysinit_sub_id {
    SI_SUB_DUMMY        = 0x0000000,    /* not executed; for linker*/
    SI_SUB_DONE     = 0x0000001,    /* processed*/
    SI_SUB_CONSOLE      = 0x0800000,    /* console*/
    SI_SUB_COPYRIGHT    = 0x0800001,    /* first use of console*/
...
    SI_SUB_RUN_SCHEDULER    = 0xfffffff /* scheduler: no return*/
};

sys/kern/init_main.c:
static void
create_init(const void *udata __unused)
{
    int error;
    int s;

    s = splhigh();
    error = fork1(&proc0, RFFDG | RFPROC, &initproc);
    if (error)
        panic("cannot fork init: %d\n", error);
    initproc->p_flag |= P_INMEM | P_SYSTEM;
    cpu_set_fork_handler(initproc, start_init, NULL);
    remrunqueue(initproc);
    splx(s);
}
SYSINIT(init,SI_SUB_CREATE_INIT, SI_ORDER_FIRST, create_init, NULL)

sys/kern/init_main.c:
static char init_path[MAXPATHLEN] =
#ifdef  INIT_PATH
    __XSTRING(INIT_PATH);
#else
    "/sbin/init:/sbin/oinit:/sbin/init.bak:/stand/sysinstall";
#endif

2.1. Мьютексы

Мьютекс (mutex) - это просто блокировка, используемая для реализации гарантированной исключительности. В частности, в каждый момент времени мьютексом может владеть только один объект. Если какой-то объект хочет получить мьютекс, который уже кто-то занял, он должен дождаться момента его освобождения. В ядре FreeBSD владельцами мьютексов являются процессы.

Мьютексы могут быть затребованы рекурсивно, но предполагается, что они занимаются на короткое время. В частности, владельцу мьютекса нельзя выдерживать паузу. Если вам нужно выполнить блокировку на время паузы, используйте блокировку через lockmgr(9).

Каждый мьютекс имеет несколько представляющих интерес характеристик:

2.2. Разделяемые эксклюзивные блокировки

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

2.3. Атомарно защищенные переменные

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

• mtx.mtx_lock

3.1. Терминология

3.2. Работа Kobj

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

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

Это описание можно изобразить следующим образом:

object->cache<->class

3.3. Использование Kobj

struct kobj_method

void kobj_class_compile(kobj_class_t cls);
void kobj_class_compile_static(kobj_class_t cls, kobj_ops_t ops);
void kobj_class_free(kobj_class_t cls);
kobj_t kobj_create(kobj_class_t cls, struct malloc_type *mtype, int mflags);
void kobj_init(kobj_t obj, kobj_class_t cls);
void kobj_delete(kobj_t obj, struct malloc_type *mtype);

KOBJ_CLASS_FIELDS
KOBJ_FIELDS
DEFINE_CLASS(name, methods, size)
KOBJMETHOD(NAME, FUNC)

<sys/param.h>
<sys/kobj.h>

#include <sys/foo.h>

INTERFACE foo;

CODE {
    struct foo * foo_alloc_null(struct bar *)
    {
        return NULL;
}
};

METHOD int bar {
    struct object *;
    struct foo *;
    struct bar;
};

METHOD int bar {
    struct object *;
    struct foo *;
    int bar;
} DEFAULT foo_hack;

src/sys/kern/bus_if.m
src/sys/kern/device_if.m

DEFINE_CLASS(fooclass, foomethods, sizeof(struct foodata));

kobj_method_t foomethods[] = {
    KOBJMETHOD(bar_doo, foo_doo),
    KOBJMETHOD(bar_foo, foo_foo),
    { NULL, NULL}
};

struct foo_data {
    KOBJ_FIELDS;
    foo_foo;
    foo_bar;
};

[return value = ] FOO_BAR(object [, other parameters]);

4.1. Архитектура

Jail состоит из двух частей: непривилегированной (user-space) программы, jail, и кода в ядре: системного вызова jail и соответствующих ограничений. Сначала я рассмотрю user-space утилиту jail, а затем то, как jail реализованa в ядре.

/usr/include/sys/jail.h:

struct jail {
        u_int32_t       version;
        char            *path;
        char            *hostname;
        u_int32_t       ip_number;
};

/usr/src/usr.sbin/jail.c
j.version = 0;
j.path = argv[1];
j.hostname = argv[2];

/usr/src/usr.sbin/jail/jail.c:
struct in.addr in;
...
i = inet.aton(argv[3], &in);
...
j.ip_number = ntohl(in.s.addr);

/usr/src/sys/usr.sbin/jail/jail.c
i = jail(&j);
...
i = execv(argv[4], argv + 4);

/usr/src/sys/kern/kern_jail.c:

int     jail_set_hostname_allowed = 1;
SYSCTL_INT(_jail, OID_AUTO, set_hostname_allowed, CTLFLAG_RW,
    &jail_set_hostname_allowed, 0,
    "Processes in jail can set their hostnames");

int     jail_socket_unixiproute_only = 1;
SYSCTL_INT(_jail, OID_AUTO, socket_unixiproute_only, CTLFLAG_RW,
    &jail_socket_unixiproute_only, 0,
    "Processes in jail are limited to creating UNIX®/IPv4/route sockets only
");

int     jail_sysvipc_allowed = 0;
SYSCTL_INT(_jail, OID_AUTO, sysvipc_allowed, CTLFLAG_RW,
    &jail_sysvipc_allowed, 0,
    "Processes in jail can use System V IPC primitives");

/usr/src/sys/kern/kern_jail.c:
int
jail(p, uap)
        struct proc *p;
        struct jail_args /* {
                syscallarg(struct jail *) jail;
        } */ *uap;

/usr/src/sys/kern/kern_jail.c: 
error = copyin(uap->jail, &j, sizeof j);

/usr/include/sys/jail.h:
struct prison {
        int             pr_ref;
        char            pr_host[MAXHOSTNAMELEN];
        u_int32_t       pr_ip;
        void            *pr_linux;
};

/usr/src/sys/kern/kern_jail.c:
 MALLOC(pr, struct prison *, sizeof *pr , M_PRISON, M_WAITOK);
 bzero((caddr_t)pr, sizeof *pr);
 error = copyinstr(j.hostname, &pr->pr_host, sizeof pr->pr_host, 0);
 if (error)
         goto bail;

/usr/src/sys/kern/kern_jail.c:
ca.path = j.path;
error = chroot(p, &ca);

/usr/include/sys/proc.h: 
struct proc {
...
struct prison *p_prison;
...
};

/usr/src/sys/kern/kern_jail.c
p->p.prison = pr;
p->p.flag |= P.JAILED;

/usr/src/sys/kern/kern_fork.c:
if (p2->p_prison) {
        p2->p_prison->pr_ref++;
        p2->p_flag |= P_JAILED;
}

4.2. Ограничения

Для реализации jail, во многих местах в коде ядра встречаются соответствующие проверки и ограничения. Как правило, большинство этих проверок сводятся к проверке, является ли данный процесс ``заключенным'' (jailed) и возврат кода ошибки, если да. К примеру:

if (p->p_prison)
        return EPERM;

/usr/src/sys/kern/sysv msg.c:
if (!jail.sysvipc.allowed && p->p_prison != NULL)
        return (ENOSYS);

/usr/src/sys/kern/uipc_socket.c:
int socreate(dom, aso, type, proto, p)
...
register struct protosw *prp;
...
{
        if (p->p_prison && jail_socket_unixiproute_only &&
            prp->pr_domain->dom_family != PR_LOCAL && prp->pr_domain->dom_family != PF_INET
            && prp->pr_domain->dom_family != PF_ROUTE)
                return (EPROTONOSUPPORT);
...
}

/usr/src/sys/net/bpf.c:
static int bpfopen(dev, flags, fmt, p)
...
{
        if (p->p_prison)
                return (EPERM);
...
}

/usr/src/sys/kern/netinet/in_pcb.c:
int in.pcbbind(int, nam, p)
...
        struct sockaddr *nam;
        struct proc *p;
{
        ...
        struct sockaddr.in *sin;
        ...
        if (nam) {
                sin = (struct sockaddr.in *)nam;
                ...
                if (sin->sin_addr.s_addr != INADDR_ANY)
                       if (prison.ip(p, 0, &sin->sin.addr.s_addr))
                              return (EINVAL);
                ....
        }
...
}

/usr/src/sys/kern/kern_jail.c:
int prison_ip(struct proc *p, int flag, u_int32_t *ip) {
        u_int32_t tmp;

       if (!p->p_prison)
              return (0);
       if (flag)
              tmp = *ip;
       else tmp = ntohl (*ip);

       if (tmp == INADDR_ANY) {
              if (flag)
                     *ip = p->p_prison->pr_ip;
              else *ip = htonl(p->p_prison->pr_ip);
              return (0);
       }

       if (p->p_prison->pr_ip != tmp)
              return (1);
       return (0);
}

/usr/src/sys/net inet/in_pcb.c
        if (nam) {
               ...
               lport = sin->sin.port;
               ... if (lport) {
                          ...
                         if (p && p->p_prison)
                                prison = 1;
                         if (prison &&
                             prison_ip(p, 0, &sin->sin_addr.s_addr))
                                    return (EADDRNOTAVAIL);

/usr/src/sys/ufs/ufs/ufs_vnops.c:
int ufs.setattr(ap)
        ...
{
        if ((cred->cr.uid == 0) && (p->prison == NULL)) {
                if ((ip->i_flags
                     & (SF_NOUNLINK | SF_IMMUTABLE | SF_APPEND)) &&
                     securelevel > 0)
                       return (EPERM);
}

5.1. Терминология

5.2. Работа SYSINIT

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

SYSINIT использует два приоритета при организации последовательности вызовов функций. Первый приоритет это идентификатор (ID) подсистемы, дающий общий порядок диспетчеризации функции через SYSINIT. Текущие предопределенные ID перечислены в файле <sys/kernel.h> в списке sysinit_sub_id. Второй используемый приоритет является порядковым номером элемента в подсистеме. Текущие предопределенные порядковые номера элементов подсистемы находятся в <sys/kernel.h> с списке sysinit_elem_order.

На данный момент есть два применения SYSINIT. Диспетчеризация функций при загрузке системы и модулей ядра, и диспетчеризация функций при выключении системы и выгрузке модулей ядра. Подсистемы ядра часто используют SYSINIT при загрузке системы для инициализации структур данных. К примеру, подсистема планирования процессов использует SYSINIT для инициализации структуры с данными живой очереди. Драйверы устройств не должны напрямую использовать SYSINIT(). Вместо этого, драйверы реальных устройств должны использовать DRIVER_MODULE() для вызова функции, которая определит устройство, и если оно присутствует - произведёт его инициализацию. Также будут сделаны некоторые вещи, специфичные для устройств и только после этого будет произведён вызов SYSINIT(). Для псевдо устройств используйте DEV_MODULE().

5.3. Использование SYSINIT

<sys/kernel.h>

SYSINIT(uniquifier, subsystem, order, func, ident)
SYSUNINIT(uniquifier, subsystem, order, func, ident)

#include <sys/kernel.h>

void foo_null(void *unused)
{
        foo_doo();
}
SYSINIT(foo, SI_SUB_FOO, SI_ORDER_FOO, foo_null, NULL);

struct foo foo_voodoo = {
        FOO_VOODOO;
}

void foo_arg(void *vdata)
{
        struct foo *foo = (struct foo *)vdata;
        foo_data(foo);
}
SYSINIT(bar, SI_SUB_FOO, SI_ORDER_FOO, foo_arg, &foo_voodoo);
     

static void
mptable_register(void *dummy __unused)
{

       apic_register_enumerator(&mptable_enumerator);
}

SYSINIT(mptable_register, SI_SUB_TUNABLES - 1, SI_ORDER_FIRST,
    mptable_register, NULL);

#include <sys/kernel.h>

void foo_cleanup(void *unused)
{
        foo_kill();
}
SYSUNINIT(foobar, SI_SUB_FOO, SI_ORDER_FOO, foo_cleanup, NULL);

struct foo_stack foo_stack = {
        FOO_STACK_VOODOO;
}

void foo_flush(void *vdata)
{
}
SYSUNINIT(barfoo, SI_SUB_FOO, SI_ORDER_FOO, foo_flush, &foo_stack);
     

6.1. Управление физической памятью--vm_page_t

Физическая память управляется на уровне отдельных страниц посредством структур vm_page_t. Страницы физической памяти разделены на категории через помещение соответствующих им структур vm_page_t в одну из нескольких очередей страниц.

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

Для реализации алгоритма подгонки страниц во FreeBSD в основном применяется очередь для кэшированных и свободных страниц. Каждое из этих состояний затрагивает несколько очередей, которые строятся согласно размерам кэшей L1 и L2 процессора. Когда требуется выделение новой страницы, FreeBSD пытается получить ту, что расположена в достаточной мере рядом с точки зрения кэшей L1 и L2 относительно объекта VM, для которого выделяется страница.

Кроме того, страница может удерживаться счетчиком ссылок или может быть заблокирована счетчиком занятости. Система VM также реализует состояние ''безусловной блокировки'' для страницы установкой бита PG_BUSY в поле флагов страницы.

Говоря общими словами, каждая из очередей страниц работает по принципу LRU. Первоначально страница обычно приводится в связанное или активное состояние. Если она связана, то страница обычно указана где-то в таблице страниц. Система VM отслеживает устаревание страницы, сканируя страницы в более активной очереди страниц (LRU) для того, чтобы переместить их в менее активную очередь страниц. Страницы, которые перемещены в кэш, остаются связанными с объектом VM, но являются кандидатами на немедленное повторное использование. Страницы в очереди свободных страниц действительно являются свободными. FreeBSD пытается минимизировать количество страниц в очереди свободных страниц, однако для обеспечения выделения страниц во время обработки прерываний должно поддерживаться некоторое минимальное количество действительно свободных страниц.

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

FreeBSD динамически изменяет свои очереди страниц, и пытается поддерживать разумное соотношение страниц в различных очередях, а также пытается поддерживать разумную схему работы с чистыми и грязными страницами. Количество случающихся перемещений зависит от нагрузки на память системы. Это перемещение выполняется даемоном выгрузки страниц и затрагивает стирание грязных страниц (синхронизируя их с хранилищем), пометку страниц при активной работе с ними (обновляя их расположение в очередях LRU или перемещая их между очередями), постепенное перемещение страниц между очередями при нарушении баланса между очередями, и так далее. VM-система FreeBSD старается обработать достаточное количество ошибок доступа к странице для реактивации, чтобы определить реальную активность или простой страницы. Это приводит к повышению качества решений, принимаемых при стирании или выгрузке страницы в раздел подкачки.

6.2. Универсальный буферизирующий кэш--vm_object_t

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

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

Должно быть отмечено, что vm_page_t может быть одновременно связана только с одним объектов VM. Затенение VM-объекта реализует эффективное совместное использование одной и той же страницы между несколькими экземплярами.

6.3. Ввод/вывод в файловой системе--struct buf

Объектам VM, хранящимся в vnode-узлах, таким, как объекты с хранением в файле, как правило, нужно поддерживать собственную информацию о чистоте/использованности независимо от предположении системы VM о чистоте/использованности. Например, когда система VM решает синхронизировать физическую страницу с ее хранилищем, то ей нужно помечать страницу как очищенную перед тем, как она действительно будет записана в хранилище. Кроме того, файловым системам нужно отображать части файла или метаданных файла в KVM для работы с ним.

Структуры, используемые для этого, известны как буферы файловой системы, struct buf, или bp. Когда файловой системе нужно произвести операцию с частью объекта VM, она обычно отображает часть объекта в struct buf и отображает страницы из struct buf в KVM. Таким же образом дисковый ввод/вывод обычно осуществляется отображением частей объектов в буферные структуры с последующим выполнением ввода/вывода этих структур. Низлежащие vm_page_t, как правило, на время ввода/вывода становятся занятыми, что удобно с точки зрения кода драйвера файловой системы, которому нужно будет работать с буферами файловой системы, а не прямо со страницами VM..

FreeBSD резервирует ограниченное число KVM для хранения отображений из struct bufs, но должно быть понятно, что эти KVM используются строго для хранения отображений и не ограничивают возможности по кэшированию данных. Кэширование физических данных является исключительно функцией vm_page_t, а не буферов файловой системы. Однако, так как буферы файловой системы являются заменителями ввода/вывода, они соответственно ограничивают количество выполняемых одновременно операций ввода/вывода. Так как обычно доступно несколько тысяч буферов файловой системы, то это, как правило, проблем не вызывает.

6.4. Таблицы отображения страниц--vm_map_t, vm_entry_t

Во FreeBSD таблица расположения физических страниц отделена от системы VM. Все жесткие таблицы страниц для каждого процесса могут быть перестроены на лету и обычно являются временными. Специальные таблицы страниц, например, те, что управляют KVM, обычно выделяются предварительно и перманентно. Эти таблицы страниц не являются временными.

FreeBSD связывает группы объектов vm_object с диапазонами адресов в виртуальной памяти посредством структур vm_map_t и vm_entry_t. Таблицы страниц строятся непосредственно из иерархии vm_map_t/vm_entry_t/ vm_object_t. Вернёмся к тому моменту, где я говорил о том, что физические страницы являются единственными, прямо связанными с vm_object. На самом деле это не совсем так. Объекты vm_page_t также объединяют в таблицы страниц и связывают с vm_object. Один vm_page_t может быть связан в несколько карт pmaps, так называются таблицы страниц. Однако иерархическая связь хранит все ссылки так, что одна и та же страница в том же самом объекте ссылается на одну и ту же vm_page_t, что дает нам универсальный кэширующий буфер.

6.5. Отображение памяти KVM

FreeBSD использует KVM для хранения различных структур ядра. Самым большим единственным объектом, хранящимся в KVM, является кэширующий буфер файловой системы. Это отображения, связанные с объектами struct buf.

В отличие от Linux, FreeBSD не отображает всю физическую память в KVM. Это значит, что FreeBSD на 32-разрядных платформах может работать с конфигурациями памяти до 4ГБ. На самом деле, если бы аппаратный модуль управления памятью мог это делать, то на 32-разрядных платформах FreeBSD может теоретически работать с конфигурациями памяти до 8ТБ. Однако, так как большинство 32-разрядных платформ могут отображать только 4ГБ оперативной памяти, то этот вопрос остается теоретическим.

KVM управляется посредством нескольких методов. Основным механизмом, используемым для управления KVM, является zone allocator. Распределитель зоны берет кусок KVM и разделяет его на блоки памяти постоянного размера для того, чтобы выделить место под некоторый тип структуры. Вы можете воспользоваться командой vmstat -m для получения статистики текущего использования KVM до уровня зон.

6.6. Тонкая настройка системы VM во FreeBSD

Прилагались совместные усилия для того, чтобы сделать ядро FreeBSD самонастраивающимся. Обычно вам не нужно разбираться ни с чем, кроме параметров конфигурации ядра maxusers и NMBCLUSTERS. Это те параметры компиляции ядра, что указываются (обычно) в файле /usr/src/sys/i386/conf/CONFIG_FILE. Описание всех доступных параметров настройки ядра может быть найдено в файле /usr/src/sys/i386/conf/LINT.

В случае большой системы вам может понадобиться увеличить значение maxusers. Значения этого параметра, как правило, располагаются в диапазоне от 10 до 128. Заметьте, что слишком большое значение maxusers может привести к переполнению доступной KVM, что влечет за собой непредсказуемые результаты. Лучше задать некоторое разумное значение maxusers и добавить другие параметры, такие, как NMBCLUSTERS, для увеличения конкретных ресурсов.

Если ваша система будет интенсивно работать с сетью, вам может потребоваться увеличить значение NMBCLUSTERS. Обычно значения этого параметра находятся в пределах от 1024 до 4096.

Параметр NBUF традиционно использовался для масштабирования системы. Этот параметр определяет количество KVA, которое может использоваться системой для отображения буферов файловой системы для ввода/вывода. Заметьте, что этот параметр не имеет никакого отношения с единым кэшируемым буфером! Этот параметр динамически настраивается в ядрах версии 3.0-CURRENT и более поздних и не должен изменяться вручную. Мы рекомендуем вам НЕ пытаться задавать значение параметра NBUF. Позвольте сделать это системе. Слишком маленькое значение может привести к очень низкой эффективности операций с файловой системой, когда как слишком большое значение может истощить очереди страниц, так как слишком много страниц окажутся связанными.

По умолчанию ядра FreeBSD не оптимизированы. Вы можете задать флаги отладки и оптимизации при помощи директивы makeoptions в файле конфигурации ядра. Заметьте, что вы не должны использовать параметр -g, если не сможете использовать получающиеся при этом большие ядра (обычно превышающие размером 7МБ).

makeoptions      DEBUG="-g"
makeoptions      COPTFLAGS="-O -pipe"

Утилита sysctl дает возможность изменить параметры ядра во время его работы. Как правило, вам не приходится работать ни с какими sysctl-переменными, особенно с теми, что относятся к VM.

Тонкая оптимизация VM и системы во время работы сравнительно проста и понятна. Сначала включите использование Soft Updates на ваших файловых системах UFS/FFS везде, где это возможно. В файле /usr/src/contrib/sys/softupdates/README.softupdates находятся инструкции (и ограничения) по настройке этой функциональности.

Затем выделите достаточное количество пространства в области подкачки. Вы должны иметь на каждом физическом диске до четырех настроенных разделов подкачки, даже на ''рабочих'' дисках. Пространства в области подкачки должно быть не менее чем в два раза больше объема оперативной памяти, и даже больше, если памяти у вас не очень много. Вы должны также определять размер раздела подкачки, исходя из максимального объема оперативной памяти, который может быть на вашей машине, чтобы потом не выполнять разбиение диска повторно. Если вы хотите иметь возможность работы с дампом аварийного останова, то ваш первый раздел подкачки должен иметь объем, по крайней мере равный объему оперативной памяти, а в каталоге /var/crash должно быть достаточно свободного места для размещения дампа.

Подкачка поверх NFS прекрасно работает на системах версий 4.x и более поздних, но вы должны иметь в виду, что нагрузка от подкачки страниц ляжет на сервер NFS.

7.1. Введение

Эта глава является кратким введением в процесс написания драйверов устройств для FreeBSD. В этом контексте термин устройство используется в основном для вещей, связанных с оборудованием, относящимся к системе, таких, как диски, печатающие устройства или графические дисплеи с клавиатурами. Драйвер устройства является программной компонентой операционной системы, управляющей некоторым устройством. Имеются также так называемые псевдо-устройства, в случае которых драйвер устройства эмулирует поведение устройства программно, без наличия какой-либо соответствующей аппаратуры. Драйверы устройств могут быть скомпилированы в систему статически или могут загружаться по требованию при помощи механизма динамического компоновщика ядра `kld'.

Большинство устройств в UNIX-подобной операционной системе доступны через файлы устройств (device-nodes), иногда также называемые специальными файлами. В иерархии файловой системы эти файлы обычно находятся в каталоге /dev. В версиях FreeBSD, более старых, чем 5.0-RELEASE, в которых поддержка devfs(5) не интегрирована в систему, каждый файл устройства должен создаваться статически и вне зависимости от наличия соответствующего драйвера устройства. Большинство файлов устройств в системе создаются при помощи команды MAKEDEV.

Драйверы устройств могут быть условно разделены на две категории; драйверы символьных и сетевых устройств.

7.2. Механизм динамического компоновщика ядра - KLD

Интерфейс kld позволяет системным администраторам динамически добавлять и убирать функциональность из работающей системы. Это позволяет разработчикам драйверов устройств загружать собственные изменения в работающее ядро без постоянных перезагрузок для тестирования изменений.

Для работы с интерфейсом kld используются следующие команды привилегированного режима:

• kldload - загружает новый модуль ядра

• kldunload - выгружает модуль ядра

• kldstat - выводит список загруженных в данный момент модулей

Скелет модуля ядра

/*
 * KLD Skeleton
 * Inspired by Andrew Reiter's Daemonnews article
 */

#include <sys/types.h>
#include <sys/module.h>
#include <sys/systm.h>  /* uprintf */
#include <sys/errno.h>
#include <sys/param.h>  /* defines used in kernel.h */
#include <sys/kernel.h> /* types used in module initialization */

/*
 * Load handler that deals with the loading and unloading of a KLD.
 */

static int
skel_loader(struct module *m, int what, void *arg)
{
  int err = 0;

  switch (what) {
  case MOD_LOAD:                /* kldload */
    uprintf("Skeleton KLD loaded.\n");
    break;
  case MOD_UNLOAD:
    uprintf("Skeleton KLD unloaded.\n");
    break;
  default:
    err = EINVAL;
    break;
  }
  return(err);
}

/* Declare this module to the rest of the kernel */

static moduledata_t skel_mod = {
  "skel",
  skel_loader,
  NULL
};

DECLARE_MODULE(skeleton, skel_mod, SI_SUB_KLD, SI_ORDER_ANY);

SRCS=skeleton.c
KMOD=skeleton

.include <bsd.kmod.mk>

# kldload -v ./skeleton.ko

7.3. Обращение к драйверу устройства

UNIX дает некоторый общий набор системных вызовов для использования в пользовательских приложениях. Когда пользователь обращается к файлу устройства, высокие уровни ядра перенаправляют эти обращения к соответствующему драйверу устройства. Скрипт /dev/MAKEDEV создает большинство файлов устройств в вашей системе, однако если вы ведете разработку своего собственного драйвера, то может появиться необходимость в создании собственных файлов устройств при помощи команды mknod.

7.4. Символьные устройства

Драйвер символьного устройства передает данные непосредственно в или из процесса пользователя. Это самый распространенный тип драйвера устройства и в дереве исходных текстов имеется достаточно простых примеров таких драйверов.

В этом простом примере псевдо-устройство запоминает какие угодно значения, которые вы в него записываете, и затем может выдавать их назад при чтении из этого устройства. Приведены две версии, одна для FreeBSD  4.X, а другая для FreeBSD  5.X.

/*
 * Simple `echo' pseudo-device KLD
 *
 * Murray Stokely
 */

#define MIN(a,b) (((a) < (b)) ? (a) : (b))

#include <sys/types.h>
#include <sys/module.h>
#include <sys/systm.h>  /* uprintf */
#include <sys/errno.h>
#include <sys/param.h>  /* defines used in kernel.h */
#include <sys/kernel.h> /* types used in module initialization */
#include <sys/conf.h>   /* cdevsw struct */
#include <sys/uio.h>    /* uio struct */
#include <sys/malloc.h>

#define BUFFERSIZE 256

/* Function prototypes */
d_open_t    echo_open;
d_close_t   echo_close;
d_read_t    echo_read;
d_write_t   echo_write;

/* Character device entry points */
static struct cdevsw echo_cdevsw = {
    echo_open,
    echo_close,
    echo_read,
    echo_write,
    noioctl,
    nopoll,
    nommap,
    nostrategy,
    "echo",
    33,             /* reserved for lkms - /usr/src/sys/conf/majors */
    nodump,
    nopsize,
    D_TTY,
    -1
};

struct s_echo {
    char msg[BUFFERSIZE];
    int len;
} t_echo;

/* vars */
static dev_t sdev;
static int len;
static int count;
static t_echo *echomsg;

MALLOC_DECLARE(M_ECHOBUF);
MALLOC_DEFINE(M_ECHOBUF, "echobuffer", "buffer for echo module");

/*
 * This function is called by the kld[un]load(2) system calls to
 * determine what actions to take when a module is loaded or unloaded.
 */

static int
echo_loader(struct module *m, int what, void *arg)
{
    int err = 0;

    switch (what) {
    case MOD_LOAD:                /* kldload */
        sdev = make_dev(&echo_cdevsw,
                    0,
                    UID_ROOT,
                    GID_WHEEL,
                    0600,
                    "echo");
        /* kmalloc memory for use by this driver */
            MALLOC(echomsg, t_echo *, sizeof(t_echo), M_ECHOBUF, M_WAITOK);
        printf("Echo device loaded.\n");
        break;
    case MOD_UNLOAD:
        destroy_dev(sdev);
        FREE(echomsg,M_ECHOBUF);
        printf("Echo device unloaded.\n");
        break;
    default:
            err = EINVAL;
            break;
    }
    return(err);
}

int
echo_open(dev_t dev, int oflags, int devtype, struct proc *p)
{
    int err = 0;

    uprintf("Opened device \"echo\" successfully.\n");
    return(err);
}

int
echo_close(dev_t dev, int fflag, int devtype, struct proc *p)
{
    uprintf("Closing device \"echo.\"\n");
    return(0);
}

/*
 * The read function just takes the buf that was saved via
 * echo_write() and returns it to userland for accessing.
 * uio(9)
 */

int
echo_read(dev_t dev, struct uio *uio, int ioflag)
{
    int err = 0;
    int amt;

  /* How big is this read operation?  Either as big as the user wants,
     or as big as the remaining data */
  amt = MIN(uio->uio_resid, (echomsg->len - uio->uio_offset > 0) ? echomsg->len - uio->uio_offset : 0);
  if ((err = uiomove(echomsg->msg + uio->uio_offset,amt,uio)) != 0) {
    uprintf("uiomove failed!\n");
  }

  return err;
}

/*
 * echo_write takes in a character string and saves it
 * to buf for later accessing.
 */

int
echo_write(dev_t dev, struct uio *uio, int ioflag)
{
  int err = 0;

  /* Copy the string in from user memory to kernel memory */
  err = copyin(uio->uio_iov->iov_base, echomsg->msg, MIN(uio->uio_iov->iov_len,BUFFERSIZE));

  /* Now we need to null terminate */
  *(echomsg->msg + MIN(uio->uio_iov->iov_len,BUFFERSIZE)) = 0;
  /* Record the length */
  echomsg->len = MIN(uio->uio_iov->iov_len,BUFFERSIZE);

  if (err != 0) {
    uprintf("Write failed: bad address!\n");
  }

  count++;
  return(err);
}

DEV_MODULE(echo,echo_loader,NULL);

/*
 * Simple `echo' pseudo-device KLD
 *
 * Murray Stokely
 *
 * Converted to 5.X by Sren (Xride) Straarup
 */

#include <sys/types.h>
#include <sys/module.h>
#include <sys/systm.h>  /* uprintf */
#include <sys/errno.h>
#include <sys/param.h>  /* defines used in kernel.h */
#include <sys/kernel.h> /* types used in module initialization */
#include <sys/conf.h>   /* cdevsw struct */
#include <sys/uio.h>    /* uio struct */
#include <sys/malloc.h>

#define BUFFERSIZE 256


/* Function prototypes */
static d_open_t      echo_open;
static d_close_t     echo_close;
static d_read_t      echo_read;
static d_write_t     echo_write;

/* Character device entry points */
static struct cdevsw echo_cdevsw = {
       .d_version = D_VERSION,
       .d_open = echo_open,
       .d_close = echo_close,
       .d_read = echo_read,
       .d_write = echo_write,
       .d_name = "echo"
};

typedef struct s_echo {
       char msg[BUFFERSIZE];
       int len;
} t_echo;

/* vars */
static struct cdev *echo_dev;
static int count;
static t_echo *echomsg;

MALLOC_DECLARE(M_ECHOBUF);
MALLOC_DEFINE(M_ECHOBUF, "echobuffer", "buffer for echo module");

/*
 * This function is called by the kld[un]load(2) system calls to
 * determine what actions to take when a module is loaded or unloaded.
 */

static int
echo_loader(struct module *m, int what, void *arg)
{
       int err = 0;

       switch (what) {
       case MOD_LOAD:                /* kldload */
               echo_dev = make_dev(&echo_cdevsw,
                   0,
                   UID_ROOT,
                   GID_WHEEL,
                   0600,
                   "echo");
               /* kmalloc memory for use by this driver */
               echomsg = malloc(sizeof(t_echo), M_ECHOBUF, M_WAITOK);
               printf("Echo device loaded.\n");
               break;
       case MOD_UNLOAD:
               destroy_dev(echo_dev);
               free(echomsg, M_ECHOBUF);
               printf("Echo device unloaded.\n");
               break;
       default:
               err = EINVAL;
               break;
       }
       return(err);
}

static int
echo_open(struct cdev *dev, int oflags, int devtype, struct thread *p)
{
       int err = 0;

       uprintf("Opened device \"echo\" successfully.\n");
       return(err);
}

static int
echo_close(struct cdev *dev, int fflag, int devtype, struct thread *p)
{
       uprintf("Closing device \"echo.\"\n");
       return(0);
}

/*
 * The read function just takes the buf that was saved via
 * echo_write() and returns it to userland for accessing.
 * uio(9)
 */

static int
echo_read(struct cdev *dev, struct uio *uio, int ioflag)
{
    int err = 0;
    int amt;

    /*
         * How big is this read operation?  Either as big as the user wants,
         * or as big as the remaining data
         */
    amt = MIN(uio->uio_resid, (echomsg->len - uio->uio_offset > 0) ?
           echomsg->len - uio->uio_offset : 0);
        if ((err = uiomove(echomsg->msg + uio->uio_offset,amt,uio)) != 0) {
        uprintf("uiomove failed!\n");
    }
    return(err);
}

/*
 * echo_write takes in a character string and saves it
 * to buf for later accessing.
 */

static int
echo_write(struct cdev *dev, struct uio *uio, int ioflag)
{
       int err = 0;

       /* Copy the string in from user memory to kernel memory */
       err = copyin(uio->uio_iov->iov_base, echomsg->msg,
           MIN(uio->uio_iov->iov_len,BUFFERSIZE - 1));

       /* Now we need to null terminate, then record the length */
       *(echomsg->msg + MIN(uio->uio_iov->iov_len,BUFFERSIZE - 1)) = 0;
       echomsg->len = MIN(uio->uio_iov->iov_len,BUFFERSIZE);

       if (err != 0) {
        uprintf("Write failed: bad address!\n");
       }
       count++;
       return(err);
}

DEV_MODULE(echo,echo_loader,NULL);

Для установки этого драйвера во FreeBSD 4.X сначала вам нужно создать файл устройства в вашей файловой системе по команде типа следующей:

# mknod /dev/echo c 33 0

Когда этот драйвер загружен, вы можете выполнять следующие действия:

# echo -n "Test Data" > /dev/echo
# cat /dev/echo
Test Data

Устройства, обслуживающие реальное оборудование, описываются в следующей главе.

Дополнительные источники информации

• Учебник по программированию механизма динамического компоновщика ядра (KLD) - Daemonnews Октябрь 2000

• Как писать драйверы ядра в парадигме NEWBUS - Daemonnews Июль 2000

7.5. Блочные устройства (которых больше нет)

Другие UNIX-системы могут поддерживать со вторым типом дисковых устройств, так называемых устройств с блочной организацией. Блочные устройства являются дисковыми устройствами, для которых ядро организует кэширование. Такое кэширование делает блочные устройства практически бесполезными, или по крайней мере ненадёжными. Кэширование изменяет последовательность операций записи, лишая приложение возможности узнать реальное содержимое диска в любой момент времени. Это делает предсказуемое и надежное восстановление данных на диске (файловые системы, базы данных и прочее) после сбоя невозможным. Так как запись может быть отложенной, то нет способа сообщить приложению, при выполнении какой именно операции записи ядро встретилось с ошибкой, что таким образом осложняет проблему целостности данных. По этой причине серьёзные приложения не полагаются на блочные устройства, и, на самом деле практически во всех приложениях, которые работают с диском напрямую, имеется большая проблема выбора устройств с последовательным доступом (или ''raw''), которые должны использоваться. Из-за реализации отображения каждого диска (раздела) в два устройства с разными смыслами, которая усложняет соответствующий код ядра, во FreeBSD поддержка дисковых устройств с кэшированием была отброшена в процессе модернизации инфраструктуры I/O-операций с дисками.

7.6. Сетевые драйверы

В случае драйверов сетевых устройств файлы устройств для доступа к ним не используются. Их выбор основан на другом механизме, работающем в ядре, и не использующем вызов open(); об использование сетевых устройств в общем случае рассказано в описании системного вызова socket(2).

За дополнительной информацией смотрите: ifnet(9), исходный код петлевого устройства ( loopback ) , сетевые драйверы Билла Пола (Bill Paul).

9.1. Обнаружение и подключение

Здесь находится информация о том, как код шины PCI проходит по не подключенным устройствам и распознает возможность загруженного драйвера kld выполнить подключение к какому-либо из них.

/*
 * Simple KLD to play with the PCI functions.
 *
 * Murray Stokely
 */

#define MIN(a,b) (((a) < (b)) ? (a) : (b))

#include <sys/param.h>  /* defines used in kernel.h */
#include <sys/module.h>
#include <sys/systm.h>
#include <sys/errno.h>
#include <sys/kernel.h> /* types used in module initialization */
#include <sys/conf.h>   /* cdevsw struct */
#include <sys/uio.h>    /* uio struct */
#include <sys/malloc.h>
#include <sys/bus.h>      /* structs, prototypes for pci bus stuff */

#include <machine/bus.h>
#include <sys/rman.h>
#include <machine/resource.h>

#include <dev/pci/pcivar.h> /* For get_pci macros! */
#include <dev/pci/pcireg.h>

/* Function prototypes */
d_open_t    mypci_open;
d_close_t   mypci_close;
d_read_t    mypci_read;
d_write_t   mypci_write;

/* Character device entry points */

static struct cdevsw mypci_cdevsw = {
        .d_open =       mypci_open,
        .d_close =      mypci_close,
        .d_read =       mypci_read,
        .d_write =      mypci_write,
        .d_name =       "mypci",
};

/* vars */
static dev_t sdev;

/* We're more interested in probe/attach than with
   open/close/read/write at this point */

int
mypci_open(dev_t dev, int oflags, int devtype, d_thread_t *td)
{
    int err = 0;

    printf("Opened device \"mypci\" successfully.\n");
    return(err);
}

int
mypci_close(dev_t dev, int fflag, int devtype, struct d_thread_t *td)
{
    int err = 0;

    printf("Closing device \"mypci.\"\n");
    return(err);
}

int
mypci_read(dev_t dev, struct uio *uio, int ioflag)
{
    int err = 0;

    printf("mypci read!\n");
    return err;
}

int
mypci_write(dev_t dev, struct uio *uio, int ioflag)
{
    int err = 0;

    printf("mypci write!\n");
    return(err);
}

/* PCI Support Functions */

/*
 * Return identification string if this is device is ours.
 */
static int
mypci_probe(device_t dev)
{
    device_printf(dev, "MyPCI Probe\nVendor ID : 0x%x\nDevice ID : 0x%x\n",
        pci_get_vendor(dev), pci_get_device(dev));

    if (pci_get_vendor(dev) == 0x11c1) {
                printf("We've got the Winmodem, probe successful!\n");
                return (0);
        }

    return (ENXIO)
}

/* Attach function is only called if the probe is successful */

static int
mypci_attach(device_t dev)
{

        printf("MyPCI Attach for : deviceID : 0x%x\n",pci_get_vendor(dev));
        sdev = make_dev(&mypci_cdevsw, 0, UID_ROOT,
            GID_WHEEL, 0600, "mypci");
        printf("Mypci device loaded.\n");
        return (ENXIO);
}

/* Detach device. */

static int
mypci_detach(device_t dev)
{

    printf("Mypci detach!\n");
    return (0);
}

/* Called during system shutdown after sync. */

static int
mypci_shutdown(device_t dev)
{

    printf("Mypci shutdown!\n");
    return (0);
}

/*
 * Device suspend routine.
 */
static int
mypci_suspend(device_t dev)
{

    printf("Mypci suspend!\n");
    return (0);
}

/*
 * Device resume routine.
 */

static int
mypci_resume(device_t dev)
{

    printf("Mypci resume!\n");
    return (0);
}

static device_method_t mypci_methods[] = {
        /* Device interface */
        DEVMETHOD(device_probe,         mypci_probe),
        DEVMETHOD(device_attach,        mypci_attach),
        DEVMETHOD(device_detach,        mypci_detach),
        DEVMETHOD(device_shutdown,      mypci_shutdown),
        DEVMETHOD(device_suspend,       mypci_suspend),
        DEVMETHOD(device_resume,        mypci_resume),

        { 0, 0 }
};

static driver_t mypci_driver = {
        "mypci",
        mypci_methods,
        0,
        /*      sizeof(struct mypci_softc), */
};

static devclass_t mypci_devclass;

DRIVER_MODULE(mypci, pci, mypci_driver, mypci_devclass, 0, 0);

Дополнительная информация

• PCI Special Interest Group

• PCI System Architecture, Fourth Edition by Tom Shanley, et al.

9.2. Ресурсы шины

FreeBSD предоставляет объектно-ориентированный механизм для запроса ресурсов от родительской шины. Почти все устройства будут находиться в качестве ребёнка не важно какой шины (PCI, ISA, USB, SCSI и т.д) и нуждаться в приобретении ресурсов от родительской шины таких, как сегменты памяти, линии прерываний, DMA каналы.

    sc->bar0id = PCI_BAR(0);
    sc->bar0res = bus_alloc_resource(dev, SYS_RES_MEMORY, &(sc->bar0id),
                                 0, ~0, 1, RF_ACTIVE);
    if (sc->bar0res == NULL) {
        printf("Memory allocation of PCI base register 0 failed!\n");
        error = ENXIO;
        goto fail1;
    }

    sc->bar1id = PCI_BAR(1);
    sc->bar1res = bus_alloc_resource(dev, SYS_RES_MEMORY, &(sc->bar1id),
                                 0, ~0, 1, RF_ACTIVE);
    if (sc->bar1res == NULL) {
        printf("Memory allocation of PCI base register 1 failed!\n");
        error =  ENXIO;
        goto fail2;
    }
    sc->bar0_bt = rman_get_bustag(sc->bar0res);
    sc->bar0_bh = rman_get_bushandle(sc->bar0res);
    sc->bar1_bt = rman_get_bustag(sc->bar1res);
    sc->bar1_bh = rman_get_bushandle(sc->bar1res);

uint16_t
board_read(struct ni_softc *sc, uint16_t address) {
    return bus_space_read_2(sc->bar1_bt, sc->bar1_bh, address);
}

void
board_write(struct ni_softc *sc, uint16_t address, uint16_t value) {
    bus_space_write_2(sc->bar1_bt, sc->bar1_bh, address, value);
}

/* Get the IRQ resource */

    sc->irqid = 0x0;
    sc->irqres = bus_alloc_resource(dev, SYS_RES_IRQ, &(sc->irqid),
                                 0, ~0, 1, RF_SHAREABLE | RF_ACTIVE);
    if (sc->irqres == NULL) {
       printf("IRQ allocation failed!\n");
       error = ENXIO;
       goto fail3;
    }

    /* Now we should set up the interrupt handler */

    error = bus_setup_intr(dev, sc->irqres, INTR_TYPE_MISC,
                          my_handler, sc, &(sc->handler));
    if (error) {
       printf("Couldn't set up irq\n");
       goto fail4;
    }

    sc->irq_bt = rman_get_bustag(sc->irqres);
    sc->irq_bh = rman_get_bushandle(sc->irqres);

#include <vm/vm.h>
#include <vm/pmap.h>

#define vtophys(virtual_address) (...)

#if defined(__alpha__)
#define vtobus(va)      alpha_XXX_dmamap((vm_offset_t)va)
#else
#define vtobus(va)      vtophys(va)
#endif

11.1. Введение

Универсальная Последовательная Шина (Universal Serial Bus - USB) является новым способом подключения устройств к персональным компьютерам. Среди возможностей архитектуры шины имеется двунаправленный обмен данными и это было разработано в качестве ответа на то, что устройства становятся все более сложными и требуют большего взаимодействия с хостом. Поддержка USB включена во все современные наборы микросхем для PC и поэтому имеется во всех недавно выпущенных PC. Выпуск компанией Apple компьютера iMac только с USB стал большим знаком для производителей оборудования на создание USB-версий своих устройств. Спецификации будущие PC задают, что все устаревшие разъемы на PC должны быть заменены на один или несколько разъемов USB, что дает всеобщие возможности технологии plug and play. Поддержка оборудования USB имелась в начальном объеме в NetBSD и была разработана Леннартом Ангустссоном (Lennart Augustsson) для проекта NetBSD. Код был перенесен во FreeBSD и в настоящее время мы поддерживаем общий код. Для реализации подсистемы USB важны несколько возможностей USB.

Lennart Augustsson сделал большую часть работы в реализации поддержки USB для проекта NetBSD. Приносим много благодарностей за эту исключительную работу. большое спасибо также Арди (Ardy) и Дирку (Dirk) за их комментарии и выверку текста этого документа.

• Устройства подключаются непосредственно к портам компьютера или к устройствам, которые называются разветвителями, что формирует структуру устройств, похожую на дерево.

• Устройства могут подключаться и отключаться во время работы.

• Устройства могут самостоятельно переходить в режим ожидания или получать сигналы на продолжение работы от ведущей системы

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

• Различное качество обслуживания, требуемое различными типами устройств, вместе с максимальным их количеством в 126 устройств, которые можно подключить к одной и той же шине, требует тщательного планирования передачи данных по общей шине для получения полной отдачи от общей пропускной способности в 12Мбит/c. (более 400Мбит/c для USB 2.0)

• Устройства сложны и содержат легкодоступную информацию о самих себе

Разработка драйверов для подсистемы USB и устройств, к ней подключаемых, поддерживается разрабатываемыми спецификациями и спецификациями, которые будут разработаны. Эти спецификации общедоступны с домашних страниц USB. Apple сильно продвигает драйверы, основанные на стандартах, помещая в свободный доступ драйверы классов общего назначения для своей операционной системы MacOS и не рекомендует использование отдельных драйверов для каждого нового устройства. В этой главе делается попытка собрать информацию, достаточную для общего понимания текущей реализации набора драйверов USB для FreeBSD/NetBSD. Но все же рекомендуется дополнительно прочитать и соответствующие спецификации, упоминаемые ниже.

11.2. Хост-контроллеры

Хост-контроллер (HC) управляет передачей пакетов по шине. Использовались кадры в 1 миллисекунду. В начале каждого кадра хост-контроллер генерирует пакет начала кадра (SOF - Start of Frame).

Пакет SOF используется для синхронизации начала кадра и отслеживания количества кадров. Пакеты передаются с каждым кадром, как от хоста к устройству (исходящие), так и от устройства к хосту (входящие). Передачи всегда инициируются хостом (запрошенные передачи). В силу этого может быть только один хост на шине USB. Каждая передача пакета имеет период статуса, в котором сторона, принимающая данные, может возвратить ACK (подтверждение приема), NAK (повтор), STALL (условная ошибка) или ничего (потерянный период данных, недоступное устройство или отсоединение). Раздел 8.5 Спецификации USB детально описывает пакеты. На шине USB могут произойти четыре различных типа передач: управляющая, основная, прерывание и изохронная. Типы передач и их характеристики описаны ниже (подраздел `Каналы').

Передачи больших объемов данных между устройством на шине USB и драйвером устройства делятся на множество пакетов хост-контроллером или драйвером HC.

Запросы устройства (управляющие передачи) к конечных точкам, используемым по умолчанию, являются специальными. Они состоят из двух или трех фаз: SETUP, DATA (oпциональная) и STATUS. пакет посылается устройству. Если есть фаза данных, то направление пакетов (или пакета) данных дается в настроечном пакете. Направление в фазе статуса противоположно направлению во время фазы данных. или IN если не было фазы данных. Оборудование хост-контроллера также дает регистры с текущим статусом корневых портов и изменений, которые случились с момента последнего сброса регистра изменения статуса. Доступ к этим регистрам дается через виртуализированных разветвитель, как и предполагается по спецификации USB [ 2]. Виртуальный разветвитель должен работать вместе с классом устройств-разветвителей, который описывается в 11 главе той спецификации. Он должен давать канал, используемый по умолчанию, через который запросы устройств могут ему посылаться. Он возвращает набор дескрипторов, стандартных и специфичных для класса разветвителя. Он должен также давать канал прерываний, который сообщает об изменениях, произошедших на его портах. На данный момент для хост-контроллеров существуют две спецификации: Universal Host Controller Interface (UHCI; Intel) и Open Host Controller Interface (OHCI; Compaq, Microsoft, National Semiconductor). Спецификация UHCI разработана для уменьшения аппаратной сложности, требуя от драйвера хост-контроллера поддержки полного распределения передач для каждого кадра. Контроллеры типа OHCI гораздо более независимы, и дают более абстрактный интерфейс, выполняя много работы самостоятельно.

11.3. Информация об устройстве USB

11.4. Распознавание и подключение устройств

После оповещения от разветвителя о том, что было подключено новое устройство, уровень услуг включает порт, предоставляя устройству напряжение в 100 mA. В этот момент устройство находится в своем состоянии по умолчанию и слушает на адресе устройства 0. Уровень услуг будут продолжать запрашивать различные дескрипторы через канал по умолчанию. После этого он пошлет запрос установки адреса для перемещения устройства от адреса устройства, используемого по умолчанию (адрес 0). Несколько драйверов устройств могут поддерживать устройство. К примеру, драйвер модема может поддерживать ISDN TA через интерфейс, совместимый с AT. Драйвер для этой конкретной модели адаптера ISDN может, однако, дать улучшенную поддержку для этого этого устройства. Для обеспечения такой гибкости процедура распознания возвращает приоритеты, показывающие их уровень поддержки. Поддержка конкретной версии продукта дает драйверу общего вида наименьший приоритет. Может также быть, что несколько драйверов могут подключаться к одному устройству, если есть несколько интерфейсов в одной конфигурации. Каждому драйверу достаточно поддерживать только подмножество интерфейсов.

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

11.5. Информация о протоколах драйверов USB

Протокол, используемый в каналах, отличающихся от канала, используемого по умолчанию, в спецификации USB не определен. Информация об этом может быть найдена в различных источниках. Самым надежным является раздел разработчиков на домашних страницах USB [ 1]. На этих страницах можно найти все возрастающее количество спецификаций классов устройств. Эти спецификации задают то, как должно выглядеть соответствующее стандарту устройство с точки зрения драйвера, базовую функциональность, которую оно должно предоставлять и протокол, который используется в коммуникационных каналах. Спецификация USB [ 2] включает описание класса концентратора USB. Спецификация класса для Устройств взаимодействия с человеком (HID - Human Interface Devices) был создан для работы с клавиатурами, планшетами, устройствами чтения бар-кода, кнопок, ручек, переключателей и так далее. Третьим примером является спецификация класса для устройств хранения информации. Полный список классов устройств можно найти в разделе разработчиков на домашних страницах USB [ 1].

Однако для многих устройств информация о протоколе еще не была опубликована. Информация об используемом протоколе может быть получена от компании, создавшей устройство. Некоторые компании будут требовать от вас подписания Соглашения о Неразглашении (NDA - Non-Disclosure Agreement) до того, как даст вам спецификации. Это в большинстве случаев исключает создание драйвера с открытым кодом.

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

Пример: Устройства взаимодействия с человеком. На спецификации для этих устройств, таких, как клавиатуры, мыши, планшеты, кнопки, пульты и прочее, имеются ссылки в спецификациях других классов устройств, и они используются во многих устройствах.

К примеру, аудио-колонки дают конечные точки для цифровых и аналоговых преобразователей и, возможно, дополнительный канал для микрофона. Они также дают конечную точку HID в отдельном интерфейсе для кнопок и ручек на передней панели устройства. То же самое имеет место для класса управления монитором. Понятно, как строить поддержку для этих интерфейсов через имеющиеся пользовательские библиотеки и библиотеки ядра вместе с драйвером класса HID или драйвера общего вида. Другим устройством, которое может выступать примером для интерфейсов внутри одной конфигурации, управляемыми различными драйверами устройств, является дешевая клавиатура со встроенным устаревшим портом мыши. Во избежание повышения стоимости за счет включения оборудования для концентратора USB в устройство, производители объединяют данные мыши, получаемые с порта PS/2 на задней стенке клавиатуры и нажатия клавиш от клавиатуры, в два отдельных интерфейса одной и той же конфигурации. Драйверы мыши и клавиатуры каждый подключается к соответствующему интерфейсу и организуют каналы к двум независимым конечным точкам.

Пример: Загрузка прошивок. Многие уже разработанные устройства опираются на процессор общего назначения с дополнительным ядром USB. Так как разработка драйверов и прошивок для устройств USB все еще является новым делом, многие устройства после подключения требуют загрузки прошивок.

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

Примером такого типа устройств является плата ввода/вывода ActiveWire, построенная на наборе микросхем EZ-USB. Для этого набора имеется загрузчик прошивок общего вида. Прошивка, загруженная в адаптер ActiveWire, изменяет номер версии. Затем выполняется программный сброс микросхемы EZ-USB в части USB для отключения от шины USB и повторного подключения.

Пример: Устройства хранения данных. Поддержка устройств хранения данных главным образом строится на основе существующих протоколов. Накопитель Iomega USB Zipdrive основан на SCSI-версии их устройства. Команды SCSI и сообщения о состоянии объединяются в блоки и передаются по каналам передачи данных к устройству и от устройства, эмулируя контроллер SCSI по соединению USB. Команды ATAPI и UFI поддерживаются подобным же образом.

Спецификация на устройства хранения поддерживает 2 различных типа объединения блоков управления. Первоначальная попытка была основана на посылке команды и состояния через канал, используемый по умолчанию, и использовании основных передач для данных, перемещаемых между хостом и устройством. На основании опыта работы второй подход был разработан на основе объединения блоков команд и статуса и посылке их по основному каналу к и от конечной точки. Спецификация явно задает, что случается, когда и что нужно сделать в случае условия возникновения ошибки. Самой большой трудностью при написании драйверов для таких устройств является обеспечить соответствие протокола USB в существующую поддержку для устройств хранения. CAM дает способы для этого ясным образом. ATAPI менее прост, так как исторически интерфейс IDE никогда не имел много различных представлений.

Поддержка дискет USB от Y-E Data опять же менее понятно, так как был разработан новый набор команд.

12.1. Введение

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

pcm(4) занимает центральное место в подсистеме звука. Его основными элементами являются:

• Интерфейс системных вызовов (read, write, ioctls) к функциям оцифрованного звука и микшера. Командный набор ioctl совместим с интерфейсом OSS или Voxware, позволяя тем самым портирование мультимедиа приложений без дополнительной модификации.

• Общий код обработки звуковых данных (преобразования форматов, виртуальные каналы).

• Единый программный интерфейс к аппаратно-зависимым модулям звукового интерфейса.

• Дополнительная поддержка нескольких общих аппаратных интерфейсов (ac97) или разделяемого аппаратно-специфичного кода (например: функции ISA DMA).

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

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

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

Для старта с рабочего примера, вы можете найти шаблон драйвера, оснащенного комментариями на http://people.FreeBSD.org/~cg/template.c

12.2. Файлы

Весь исходный код, на сегодняшний момент (FreeBSD 4.4), содержится в каталоге /usr/src/sys/dev/sound/, за исключением публичных определений интерфейса ioctl, находящихся в /usr/src/sys/sys/soundcard.h

В подкаталоге pcm/ родительского каталога /usr/src/sys/dev/sound/ находится главный код, а в каталогах isa/ и pci/ содержатся драйвера для ISA и PCI карт.

12.3. Обнаружение, подключение, и т.д.

Обнаружение и подключение звуковых драйверов во многом схоже с драйвером любого другого устройства. За дополнительной информацией вы можете обратиться к главам ISA или PCI данного руководства.

Но всё же, звуковые драйвера немного отличаются:

• Они объявляют сами себя, как устройства класса pcm, с частной структурой устройства struct snddev_info :

            static driver_t xxx_driver = {
                "pcm",
                xxx_methods,
                sizeof(struct snddev_info)
            };
  
            DRIVER_MODULE(snd_xxxpci, pci, xxx_driver, pcm_devclass, 0, 0);
            MODULE_DEPEND(snd_xxxpci, snd_pcm, PCM_MINVER, PCM_PREFVER,PCM_MAXVER);
  

  Большинство звуковых драйверов нуждаются в сохранении личной информации, касающейся их устройства. Структура с личными данными обычно выделяется при вызове функции attach. Её адрес передаётся pcm посредством вызовов pcm_register() и mixer_init(). Позже pcm передаёт назад этот адрес, в качестве параметра в вызовах к интерфейсам звукового драйвера.

• Функция подключения звукового драйвера должна объявлять её микшерный или AC97 интерфейс pcm посредством вызова mixer_init(). Для микшерного интерфейса это взамен вернёт вызов xxxmixer_init().

• Функция подключения звукового драйвера передаёт общие настройки каналов pcm посредством вызова pcm_register(dev, sc, nplay, nrec), где sc - адрес структуры данных устройства, используемой в дальнейших вызовах от pcm, а nplay и nrec - количество каналов проигрывания и записи.

• Функция подключения звукового драйвера объявляет каждый из её каналов с помощью вызовов pcm_addchan(). Это установит занятость канала в pcm и вызовет взамен вызов xxxchannel_init().

• Функция отключения должна вызывать pcm_unregister() перед объявлением её ресурсов свободными.

Существует два метода работы с не PnP устройствами:

• Использование метода device_identify() (пример смотрите в: sound/isa/es1888.c). device_identify() пытается обнаружить оборудование, использующее известные адреса, и если найдёт поддерживаемое устройство, то создаст новое pcm устройство, которое затем будет передано процессу обнаружения/подключения.

• Использование выборочной конфигурации ядра с соответствующими хинтами для pcm устройств (пример: sound/isa/mss.c).

pcm драйверы должны поддерживать device_suspend, device_resume и device_shutdown функции, для корректного функционирования управления питанием и процесса выгрузки модуля.

12.4. Интерфейсы

Интерфейс между pcm и звуковыми драйверами определён в терминах объектов ядра.

Есть 2 основных интерфейса, которые обычно обеспечивает звуковой драйвер: канальный и, либо микшерный либо AC97.

Интерфейс AC97 довольно мало использует доступ к ресурсам оборудования (чтение/запись регистров). Данный интерфейс реализован в драйверах для карт с кодеком AC97. В этом случае фактический микшерный интерфейс обеспечивается разделяемым кодом AC97 в pcm.

          static void *
          xxxchannel_init(kobj_t obj, void *data, 
             struct snd_dbuf *b, struct pcm_channel *c, int dir)
          {
              struct xxx_info *sc = data;
              struct xxx_chinfo *ch;
               ...
              return ch;
           }

          static int
          xxxchannel_setformat(kobj_t obj, void *data, u_int32_t format)
          {
              struct xxx_chinfo *ch = data;
               ...
              return 0;
           }

          static int
          xxxchannel_setspeed(kobj_t obj, void *data, u_int32_t speed)
          {
              struct xxx_chinfo *ch = data;
               ...
              return speed;
           }

          static int
          xxxchannel_setblocksize(kobj_t obj, void *data, u_int32_t blocksize)
          {
              struct xxx_chinfo *ch = data;
                ...
              return blocksize;
           }

          static int
          xxxchannel_trigger(kobj_t obj, void *data, int go)
          {
              struct xxx_chinfo *ch = data;
               ...
              return 0;
           }

          struct pcmchan_caps *
          xxxchannel_getcaps(kobj_t obj, void *data)
          {
              return &xxx_caps;
           }

          static int
          xxxmixer_init(struct snd_mixer *m)
          {
              struct xxx_info   *sc = mix_getdevinfo(m);
              u_int32_t v;

              [Initialize hardware]

              [Set appropriate bits in v for play mixers]
              mix_setdevs(m, v);
              [Set appropriate bits in v for record mixers]
              mix_setrecdevs(m, v)

              return 0;              
          }

          static int
          xxxmixer_set(struct snd_mixer *m, unsigned dev, 
                           unsigned left, unsigned right)
          {
              struct sc_info *sc = mix_getdevinfo(m);
              [set volume level]
              return left | (right << 8);
          }

          static int
          xxxmixer_setrecsrc(struct snd_mixer *m, u_int32_t src)
          {
              struct xxx_info *sc = mix_getdevinfo(m);

              [look for non zero bit(s) in src, set up hardware]

              [update src to reflect actual action]
              return src;
           }