Несмотря на то, что в обеих системах для хранения исполняемых программ используется формат ELF, все же он слегка различается. Соответственно для запуска Linux-приложения система должна корректно определить тип исполняемого файла по его магической комбинации, обычно это первые 8 байт заголовка. Затем, пользуясь абстрактным классом загрузчика «execution class loader», в котором содержится таблица всех доступных на данный момент загрузчиков, система определяет, кому нужно отдать его на выполнение. В случае если этот файл оказывается шелл-скриптом, вызывается стандартная командная оболочка или та ее разновидность, название которой записано в первой строке выполняемого скрипта. В случае если нам в лапы попался файл в формате ELF, вызывается специализированный загрузчик этого типа файлов. На данном этапе загрузчик еще не знает, какой операционной системе принадлежит полученный файл. К примеру, он может быть создан для Linux, Solaris, FreeBSD или какой-либо другой системы, также имеющей привычку хранить свои исполняемые файлы в формате ELF. Соответственно, чтобы узнать, чья это вещь, загрузчик смотрит в специальную секцию ELF-файла и ищет известную ему метку (brand), однозначно описывающую родную для приложения систему. Если это ему не удается, то процесс загрузки прерывается, а на экране появляется вот такое сообщение:

$ ./имя программы

ELF binary type not know

Abort

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

# brandelf -t  Linux имя программы

Ну а мы продолжим рассмотрение процесса загрузки. После того как произошло определение принадлежности файла, в случае если мы работаем с Linux-приложением, происходит следующее: загрузчик изменяет указатели в специальной структуре proc, содержащей внутри себя адреса системных функций так, чтобы вместо родных функций ядра FreeBSD управление получали специальные функции, реализующие соответствующее поведение ядра Linux. Таким образом получается, что никакой эмуляцией тут и не пахнет. Просто в момент вызова Linux-приложением тех или иных функций система жонглирует указателями, ловко обманывая программу. Процесс Linux-приложения помечается специальным флагом, позволяющим системе отличать его от обычных FreeBSD-процессов, а модуль ядра linux.ko, опираясь на вышеуказанную метку, особым образом обрабатывает сигналы с тем прицелом, чтобы у процесса полностью создалось ощущение жизни внутри родной системы. Еще одним из полезных фокусов является то, что при попытке Linux-программы выполнить другую программу, поиск файла будет сначала вестись в директориях /usr/compat/linux, а в случае если ничего подходящего не нашлось, продолжится уже в корневой файловой системе. Яркой иллюстрацией таких уловок является поведение команды uname, родной для FreeBSD и Linux.