Подсистемы ядра

Выбор граничных методов пересечения зависит в основном со стороны ядра, в которое Вы добавляете код. В частности граничный метод пересечения, предпочтенный для Набора I/O, отличается от предпочтенного для BSD, отличающегося от предпочтенного для Маха.

Если Вы пишете драйвер устройства или другой связанный код, Вы, вероятно, имеете дело с Набором I/O. В этом случае необходимо вместо этого считать надлежащие разделы в Основных принципах IOKit, Получив доступ к Аппаратным средствам Из Приложений и Руководства по проектированию Драйвера устройства IOKit.

Если Вы пишете код, находящийся в подсистеме BSD (например, файловая система), необходимо обычно использовать BSD APIs такой как syscall или sysctl если Вы не требуете высокой пропускной способности или исключительно низкой задержки.

Если Вы пишете код, находящийся где-либо еще, необходимо будет, вероятно, использовать Маха, обменивающегося сообщениями.

Пропускная способность и задержка

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

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

Если Вы требуете низкой задержки, но пропускная способность не является проблемой, sysctl и syscall не хороший выбор. Мах RPC, однако, может быть приемлемым решением. Другая возможность состоит в том, чтобы фактически соединить страницу проводом памяти (см., что Память Отображается и Блочное Копирование для подробных данных), запустите асинхронного Маха RPC simpleroutine (чтобы обработать данные) и использовать или блокировки или высокие/низкие водяные знаки (буферное обилие) для определения когда, считать и записать данные. Это может работать на коммуникацию высокой пропускной способности также.

При требовании и высокой пропускной способности и низкой задержки необходимо также смотреть на пользовательскую модель интерфейса клиента/устройства, используемую в Наборе I/O, так как та модель имеет подобные требования.

Используя четко определенные порты

Прежде чем можно будет использовать Маха IPC для коммуникации задачи, передающая задача должна быть в состоянии получить, отправляют права на порту задачи задачи получения. Исторически, существует несколько способов сделать это, не, все из которых поддерживаются OS X. Например, в OS X, в отличие от большинства других деривативов Маха, нет никакой службы сервер-серверного или сервера имен. Вместо этого задача начальной загрузки и mach_init включают в категорию эту функциональность.

Когда задача создается, она дана, отправляют права на порт начальной загрузки для отправки сообщений к задаче начальной загрузки. Обычно задача использовала бы этот порт для отправки сообщения, дающего задачу начальной загрузки, отправляют права на другом порту так, чтобы задача начальной загрузки могла тогда возвратить данные задаче вызова. Различные подпрограммы существуют в bootstrap.h тот краткий обзор этот процесс. Действительно, большинство пользователей Маха, IPC или Мах, обменивающийся сообщениями фактически, используют вызовы удаленной процедуры (RPC) Маха, реализованные поверх Маха IPC.

Так как прямое использование IPC редко желательно (потому что не просто сделать правильно), и потому что базовая реализация IPC исторически изменилась регулярно, подробные данные не покрыты здесь. Можно найти больше информации об использовании Маха IPC непосредственно в Махе 3 Руководства Писателя Сервера от Silicomp (раньше Open Group, раньше Научно-исследовательский институт Фонда открытого программного обеспечения), который может быть получен из раздела разработчика веб-сайта Apple. В то время как большая часть информации, содержавшейся в той книге, не полностью актуальна относительно OS X, это должен все еще быть относительно хороший ресурс при использовании Маха IPC.

Вызовы удаленной процедуры (RPC)

Мах RPC является наиболее популярным способом использования Маха IPC. Это часто используется для коммуникации пользовательского ядра, но может также использоваться для задачи определить задачу или даже коммуникация от компьютера к компьютеру. Программисты часто используют Маха RPC для установки определенных параметров ядра, таких как политика планирования данного потока.

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

В каталоге osfmk/mach (относительно Вашего контроля xnu модуля от CVS), существует много файлов, заканчивающихся в .defs; эти файлы содержат определения RPC. Когда ядро (или модуль ядра) компилируется, Mach Interface Generator (MIG) использует эти определения для создания кода IPC для поддержки функций, экспортируемых через RPC. Обычно, если Вы хотите добавить новый вызов удаленной процедуры, необходимо сделать так путем добавления определения одному из этих существующих файлов. (См. Создание и Отладку Ядер для получения дополнительной информации о получении источников ядра.)

То, что следует, является примером определения для подпрограммы, одного из большего количества общего использования RPC.

routine thread_policy_get(

                    thread      : thread_act_t;

                    flavor      : thread_policy_flavor_t;

            out     policy_info : thread_policy_t, CountInOut;

            inout   get_default : boolean_t);

Заметьте подобный C синтаксис определения. Каждый параметр в подпрограмме примерно отображается на параметр в функции C. Прототип C для этой функции следует.

kern_return_t thread_policy_get(

    thread_act_t            act,

    thread_policy_flavor_t  flavor,

    thread_policy_t         policy_info,

    mach_msg_type_number_t  *count,

    boolean_t               get_default);

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

Оттуда это становится более интересным. Четвертый параметр в прототипе C является представлением размера третьего. В файле определения это представлено добавленной опцией, CountInOut.

Опция MIG CountInOut указывает, что должно быть inout параметр вызывают count. inout параметр - тот, в котором исходное значение может быть считано функцией, вызванной, и ее значение заменяется по возврату из той функции. В отличие от отдельного inout параметр, однако, значение первоначально прошло через этот параметр, непосредственно не установлен функцией вызова. Вместо этого это связывается к policy_info параметр так, чтобы число целых чисел в policy_info прозрачно передается в через этот параметр.

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

В дополнение к routine, У Маха RPC также есть simpleroutine. A simpleroutine подпрограмма т.е. по определению, асинхронный. Это может иметь нет out или inout параметры и никакое возвращаемое значение. Вызывающая сторона не ожидает функции для возврата. Одно возможное применение для этого могло бы быть должно сказать устройству ввода-вывода отправлять данные, как только это готово. В том использовании, simpleroutine мог бы просто ожидать данных, затем отправить сообщение в задачу вызова указать доступность данных.

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

Большую часть времени, если необходимо использовать RPC, Вы будете делать его в существующей подсистеме. Подробные данные создания новой подсистемы выходят за рамки этого документа. Разработчики, бывшие должные добавить новую подсистему Маха, должны консультироваться с Махом 3 Руководства Писателя Сервера от The Open Group (TOG), которая может быть получена из различных расположений в Интернете.

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

type clock_flavor_t     = int;

type clock_attr_t       = array[*:1] of int;

type mach_timespec_t    = struct[2] of int;

Данные типа array передается как адрес пространства пользователя того, что, как предполагается, является непрерывным массивом базового типа, в то время как структура передается путем копирования всех отдельных значений массива базового типа. Иначе, они обрабатываются так же. «Структура» не походит на структуру C, поскольку элементы структуры MIG должны все иметь тот же базовый тип.

Синтаксис объявления подобен Паскалю, где *:1 и 2 представляйте размеры для массива или структуры, соответственно. *:1 конструкция указывает массив переменного размера, где размер может быть до 1, включительно, но не больше.

Вызов RPC от пользовательских приложений

RPC, как упомянуто ранее, фактически очевиден для клиента. Вызов процедуры похож на любой другой вызов функции C, и никакая дополнительная связь библиотеки не необходима. Необходимо только ввести надлежащие заголовки с a #include директива. Компилятор автоматически распознает вызов как вызов удаленной процедуры и обрабатывает базовые аспекты MIG для Вас.

Общая информация о добавлении a sysctl

При добавлении sysctl необходимо сделать все следующие сначала:

• добавьте, что следующее включает:

  #include <mach/mach_types.h>

  #include <sys/systm.h>

  #include <sys/types.h>

  #include <sys/sysctl.h>

• добавить -no-cpp-precomp к Вашим параметрам компилятора в Разработчике Проекта (или к CFLAGS в Вашем make-файле при создании вручную).

Добавление a sysctl Вызов процедуры

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

Предпочтительный способ добавить a sysctl взгляды что-то как следующее:

SYSCTL_PROC(_hw, OID_AUTO, l2cr, CTLTYPE_INT|CTLFLAG_RW,

    &L2CR, 0, &sysctl_l2cr, "I", "L2 Cache Register");

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

CTLTYPE_INT указывает, что изменяемое значение является целым числом. Другие юридические значения CTLTYPE_NODE, CTLTYPE_STRING, CTLTYPE_QUAD, и CTLTYPE_OPAQUE (также известный как CTLTYPE_STRUCT). CTLTYPE_NODE единственный, который не несколько очевиден. Это относится к узлу в sysctl иерархия, которая не непосредственно применима, но вместо этого является родителем к другим записям. Два примера узлов hw и kern.

CTLFLAG_RW указывает, что значение может быть считано и записано. Другие юридические значения CTLFLAG_RD, CTLFLAG_WR, CTLFLAG_ANYBODY, и CTLFLAG_SECURE. CTLFLAG_ANYBODY средние значения, что значение должно быть модифицируемым кем-либо. (Значение по умолчанию для переменных, чтобы быть изменяемым только корнем.) CTLFLAG_SECURE средние значения, в которых переменная может быть заменена только при выполнении securelevel <= 0 (эффективно, в однопользовательском режиме).

L2CR расположение, где sysctl будет хранить свои данные. Так как адрес установлен во время компиляции, однако, это должно быть глобальной переменной или статической локальной переменной. В этом случае, L2CR глобальная переменная типа unsigned int.

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

sysctl_l2cr функция-обработчик для этого sysctl. Прототип для этих функций имеет форму

static int sysctl_l2cr SYSCTL_HANDLER_ARGS;

Если sysctl перезаписываемо, функция может или использовать sysctl_handle_int получить значение передало в от пространства пользователя, и сохраните его в расположении по умолчанию или используйте SYSCTL_IN макрос для хранения его в альтернативный буфер. Эта функция должна также использовать SYSCTL_OUT макрос для возврата значения пространству пользователя.

“I” указывает, что параметр должен относиться к переменной типа integer (или константа, указатель или другая часть данных эквивалентной ширины), в противоположность “L” для a long, “A” для a string, “N” для a node (a sysctl это - родитель a sysctl категория или подкатегория), или “S” для a struct. “L2 Cache Register” человекочитаемое описание Вашего sysctl.

Для управления, чтобы быть доступным из приложения, это должно быть зарегистрировано. Чтобы сделать это, Вы делаете следующее:

sysctl_register_oid(&sysctl__hw_l2cr);

Необходимо обычно делать это в init подпрограмме для загружаемого модуля. Если Ваш код не является частью загружаемого модуля, необходимо добавить Ваш sysctl к списку встроенного OIDs в файле kern/sysctl_init.c.

Если Вы учитесь SYSCTL_PROC макрос конструктора, Вы заметите это sysctl__hw_l2cr имя переменной, создаваемой тем макросом. Это означает что SYSCTL_PROC строка должна быть прежде sysctl_register_oid в файле, и должен быть в том же (или более широк) объем. Это имя находится в форме sysctl_ сопровождаемый именем он - родительский узел, сопровождаемый другим подчеркиванием ( _ ) сопровождаемый именем Вашего sysctl.

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

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

static int myhandler SYSCTL_HANDLER_ARGS

{

    int error, retval;

    error = sysctl_handle_int(oidp, oidp->oid_arg1, oidp->oid_arg2,  req);

    if (!error && req->newptr) {

        /* We have a new value stored in the standard location.*/

        /* Do with it as you see fit here. */

        printf("sysctl_test: stored %d\n", SCTEST);

    } else if (req->newptr) {

        /* Something was wrong with the write request */

        /* Do something here if you feel like it.... */

    } else {

        /* Read request. Always return 763, just for grins. */

        printf("sysctl_test: read %d\n", SCTEST);

        retval=763;

        error=SYSCTL_OUT(req, &retval, sizeof retval);

    }

    /* In any case, return success or return the reason for failure  */

    return error;

}

Это демонстрирует использование SYSCTL_OUT отсылать произвольное значение в пространство пользователя от sysctl обработчик. «Фантом» req параметром является часть прототипа функции когда SYSCTL_HANDLER_ARGS макрос расширен, как oidp переменная, используемая в другом месте. Остающимися параметрами является указатель (введите равнодушный), и длина данных для копирования (в байтах).

Этот пример кода также представляет новую функцию, sysctl_handle_int, то, которое берет параметры, передало sysctl, и пишет целое число в обычную область хранения (L2CR в более раннем примере, SCTEST в этом). Если Вы хотите видеть новое значение, не храня его (чтобы сделать проверку работоспособности, например), необходимо вместо этого использовать SYSCTL_IN макрос, параметры которого совпадают с SYSCTL_OUT.

Регистрация нового верхнего уровня sysctl

В дополнение к добавлению нового sysctl опции, можно также добавить новую категорию или подкатегорию. Макрос SYSCTL_DECL может использоваться для объявления узла, который может иметь дочерние элементы. Это требует, чтобы изменение одного дополнительного файла создало дочерний список. Например, если Ваш основной файл C делает это:

SYSCTL_DECL(_net_newcat);

SYSCTL_NODE(_net, OID_AUTO, newcat, CTLFLAG_RW, handler, "new  category");

тогда это - в основном та же вещь как объявление extern sysctl_oid_list sysctl__net_newcat_children в Вашей программе. Для ядра для компиляции, или модуль для соединения необходимо тогда добавить эту строку:

struct sysctl_oid_list sysctl__net_newcat_children;

Если Вы не пишете модуль, это должно войти в файл kern/kern_newsysctl.c. Иначе, это должно войти в один из файлов Вашего модуля. Как только Вы создали эту переменную, можно использовать _net_newcat как родитель при создании нового управления. Как с любым sysctl, узел (sysctl__net_newcat) должен быть зарегистрирован в sysctl_register_oid и может быть не зарегистрировано с sysctl_unregister_oid.

Добавление простого sysctl

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

• SYSCTL_INT(parent, nbr, name, access, ptr, val, descr)

• SYSCTL_LONG(parent, nbr, name, access, ptr, descr)

• SYSCTL_STRING(parent, nbr, name, access, arg, len, descr)

• SYSCTL_OPAQUE(parent, nbr, name, access, ptr, len, descr)

• SYSCTL_STRUCT(parent, nbr, name, access, arg, type, descr)

Первые четыре параметра для каждого макроса совпадают с для SYSCTL_PROC (описанный в предыдущем разделе), как последний параметр. len параметр (где применимо) дает длину строки или непрозрачного объекта в байтах.

arg параметры являются указателями точно так же, как ptr параметры. Однако параметры называют ptr явно описаны как указатели, потому что необходимо явно использовать “адрес” (&) оператор, если Вы уже не работаете с указателем. Параметры вызвали, аргумент или воздействует на базовые типы, которые являются неявно указателями или добавляют и оператор в надлежащем месте во время макрорасширения. В обоих случаях параметр должен относиться к целому числу, символу или другому объекту что sysctl будет использовать для хранения текущей стоимости.

type параметр является именем типа минус “struct”. Например, если у Вас есть объект типа struct scsipi, тогда Вы использовали бы scsipi как тот параметр. SYSCTL_STRUCT макрос функционально эквивалентен SYSCTL_OPAQUE, за исключением того, что это скрывает использование sizeof.

Наконец, val параметр для SYSCTL_INT значение по умолчанию. Если значение передало в ptr NULL, это значение возвращается когда sysctl используется. Можно использовать это, например, при добавлении a sysctl это является определенным для определенных аппаратных средств или определенных опций компиляции. Одним возможным примером этого могло бы быть специальное значение для feature.version это означает “не существующий”. Если бы та функция стала доступной (например, если бы модуль был загружен некоторым пользовательским действием), то это могло бы тогда обновить тот указатель. Если бы тот модуль был впоследствии разгружен, то он мог бы задержать указатель на NULL.

Вызов a sysctl От пространства пользователя

В отличие от RPC, sysctl требует явного вмешательства со стороны программиста. Для усложнения вещей далее существует два различных способа вызвать sysctl функции и никакая работают на каждое управление. Старого стиля sysctl вызов может только вызвать управление, если он перечислен в статической таблице OID в ядре. Новый стиль sysctlbyname вызов будет работать на любого добавленного пользователями sysctl, но не для перечисленных в статической таблице. Иногда, Вы даже найдете управление, регистрирующееся обоими способами, и таким образом доступное обоим вызовам. Для понимания различия необходимо сначала считать функции используемыми.

sysctlbyname(char *name, void *oldp, size_t *oldlenp,

        void *newp, u_int newlen)

int get_debug_bufsize()

{

char *name="debug.bpf_bufsize";

int bufsize, retval;

size_t len;

len=4;

retval=sysctlbyname(name, &bufsize, &len, NULL, 0);

/* Check retval here */

return bufsize;

}

sysctl(int *name, u_int namelen, void *oldp, size_t *oldlenp,

        void *newp, u_int newlen)

int get_bus_speed()

{

int mib[2], busspeed, retval;

unsigned int miblen;

size_t len;

mib[0]=CTL_HW;

mib[1]=HW_BUS_FREQ;

miblen=2;

len=4;

retval=sysctl(mib, miblen, &busspeed, &len, NULL, 0);

/* Check retval here */

return busspeed;

}