Пример: обработчик двоичных файлов Java

Как было показано ранее, функция do_execve пошагово просматривает связанный список структур struct linux_binfmt, представляющий обработчики двоичных файлов, вызывая функцию указываемую членом load_binary для каждого элемента struct, пока один из форматов не подойдет (или, естественно, пока не закончится список поддерживаемых форматов). Но откуда берутся эти структуры, и как реализованы функции load_binary? Чтобы ответить на эти вопросы, обратимся к файлу fs/binfmt_java.c.

Посредством использования функции java_format (строка 9236) и связанных с ней функций этот модуль обрабатывает двоичные файлы Java, которые не являются апплетами, разработанными для выполнения в среде Web-браузера. Апплеты обрабатываются с помощью функции applet_format (строка 9254) и связанных с ней функций. Остальная часть этого раздела будет посвящена файлам, не являющимся апплетами; поддержка апплетов осуществляется совершенно так же.

Функции в файле fs/binfmt_java.c можно было бы улучшить, переписав их для объединения значительной части кода, общего для функций обработки апплетов и не-апплетов. Однако, поскольку вскоре предвидится замена этого обработчика обработчиком двоичных файлов misc, это было бы напрасной тратой времени.

do_load_java

9108: Эта функция выполняет всю реальную работу по загрузке файла .class Java.

9117: Начинается с проверки наличия специальной последовательности шестнадцатиричных цифр 0xcafebabe, поскольку в соответствии со стандартом Java все допустимые файлы класса должны начинаться с этой последовательности байтов. Профилактические проверки продолжаются вплоть до строки 9124, подтверждая отсутствие рекурсивных вызовов.

9148: К этому моменту все профилактические проверки уже выполнены. Теперь функция do_load_java принимает базовое имя фала, помещает его и имя интерпретатора байт-кода Java в область программы и предпринимает попытку выполнить интерпретатор байт-кода Java.

9165: Интерпретатор выполняется, используя процедуру, которая во многом аналогична используемой в функции do_execve. В частности, он ищет обработчик двоичных файлов для интерпретатора, используя функцию search_binary_handler, совершено так же, как была найдена сама функция do_load_java. (На практике, вероятно, им будет обработчик двоичных файлов ELF, хотя это и не обязательно.) Помните, что другой обработчик не будет выделять новую структуру struct task_struct — это уже было сделано при выполнении подпрограммы fork. Другой обработчик всего лишь изменяет структуру struct task_struct существующего процесса. Если желаете выяснить все подробности этого процесса, начните с функции do_load_elf_binary (строка 8072) — наиболее интересная часть кода начинается со строки 8273.

load_java

9226: Для внешнего мира загрузка файла .class Java выполняется функцией load_java. Она увеличивает, а в последствии уменьшает значение счетчика, используемого ее модулем ядра (эта функция компилируется в качестве модуля ядра), но в действительности она делегирует всю реальную работу функции do_load_java (строка 9108).

java_format

9236: Сравнив инициализацию функции java_format с определением структуры struct linux_binfmt (строка 13803), можно видеть, что этот модуль не обеспечивает поддержку библиотек совместного использования или дампов ядра, а поддерживает только загрузку исполняемых файлов; и эта поддержка обеспечивается посредством функции load_java.

init_java_binfmt

9262: Точкой входа этого модуля является функция init_java_binfmt, которая выталкивает адреса двух статических структур struct linux_binfmt, java_format и applet_format, в список системы. Функция init_java_binfmt вызывается из строки 9355, если поддержка двоичных файлов Java скомпилирована в ядро, или задачей kmod, если эта поддержка скомпилирована в качестве модуля ядра.