1. Защо е необходимо

Поради това, че много софтуерни производители разпространяват своите продукти в бинарен вид, компилирани само за Linux, на FreeBSD се налага да компенсира някакси този проблем. Накратко прави се опит да се поддържа бинарна съвместимост с Linux приложенията. Това позволява на FreeBSD потребителите да използват почти 90% от Linux приложенията , например Linux версийте на Star Office Netscape , Adobe Acrobat, RealPlayer 5 и 7, VMWare, Oracle , WordPerfect, Doom , Quake и други . Има обаче някои специфични за Linux реализации които не се поддържат (все още) от FreeBSD и съответно няма да могат да бъдат стартирани под него . Например, ако Linux binary-то разчита прекалено много на Linux /proc файловата система (която е различна от /proc на FreeBSD) или пък ползва някакви i386-специфични системни повиквания като поддръжка на виртуален 8086 режим.

2.1 Инсталация

2.1.1 Инсталиране на Linux ABI

Бинарната съвместимост с Linux не е включена по подразбиране, най-лесния начин това да стане е като се зареди linux KLD object ("Kernel LoaDable object''), просто като се напише linux в командния ред, или пък ако искате да се зарежда всеки път автоматично тогава добавете linux_enable= "YES" в /etc/rc.conf .

Последното предизвиква изпълнението на следния код в скрипта /etc/rc.i386:

    # Стартиране на бинарна съвместимост с Linux при "поизкване".
    #
    case ${linux_enable} in
    [Yy][Ee][Ss])
        echo -n ' linux';   linux > /dev/null 2>&1
        ;;
    esac

Командата kldstat(8) може да се използва за да се провери дали KLD е зареден :

    % kldstat
    Id Refs Address    Size       Name
     1    2 0xc0100000 16bdb8   kernel
     7    1 0xc24db000 d000       linux.ko

Ако по някаква причина не искате или не можете да заредите KLD, тогава можете компилирате поддръжката на бинарна съвместимост с Linux директно в ядрото, добавяйки options LINUX в конфигурационния файл на ядрото. След което прекомпилирайте и инсталирайте новото ядро .

    # cd /usr/ports/emulators/linux_base
    # make install distclean

    % ldd linuxdoom
    libXt.so.3 (DLL Jump 3.1) => /usr/X11/lib/libXt.so.3.1.0
    libX11.so.3 (DLL Jump 3.1) => /usr/X11/lib/libX11.so.3.1.0
    libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29

    /compat/linux/usr/X11/lib/libXt.so.3.1.0
    /compat/linux/usr/X11/lib/libXt.so.3 -> libXt.so.3.1.0
    /compat/linux/usr/X11/lib/libX11.so.3.1.0
    /compat/linux/usr/X11/lib/libX11.so.3 -> libX11.so.3.1.0
    /compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29

    % ./my-linux-elf-binary
    ELF binary type not known
    Abort

    % brandelf -t Linux my-linux-elf-binary

2.2 Проблеми

2.2.1 DNS проблеми

Ако при използването на Linux binaries под FreeBSD се получава следното съобщение:

    resolv+: "bind" is an invalid keyword resolv+:
    "hosts" is an invalid keyword

Проверете дали имате конфигуриран файла /compat/linux/etc/host.conf :

    order hosts, bind
    multi on

Когато обаче няма /compat/linux/etc/host.conf , Linux приложенията намират /etc/host.conf на FreeBSD и се "оплакват" от несъвместимия FreeBSD синтаксис. Проверете също и /compat/linux/etc/nsswitch.conf , защото Linux приложенията ползващи версия 2 на glibc за реда на резолвинга ше търсят него. Най-общо казано при подобни проблеми със съвместимостта си представяме ,че /compat/linux/ е GNU/Linux система и се процедира аналогино все едно, че работим в момента на такава (е само няма linux kernel :).

3. Реализация

Накратко да проследим как стартират и се изпълнявани приложенията в системата.

Във FreeBSD има абстракция наречена "execution class loader'', реализирана в системното повикване execve(2) . Това означава, че FreeBSD ядрото прави разлика между няколко loaders (за приложения), това са обектните (или бинарни) файлови формати които се разпознават от системата и един специален "#!" loader. Ако някой процес "извика" execve(), ядрото на FreeBSD ще се опита да определи обектния му файлов формат по магическия номер (запис в началото на файла, обикновено първите 4 или 8 байта) за да провери дали това е разбираем за системата изпълним двoичен файл. Обектните файлови формати които FreeBSD може да зарежда (т.е. разполага със съответните loaders) и изпълнява са: a.out , elf, shell, gzip .

Идеята за gzip loader е изпълнимите файлове да бъдат компресирани (с алгоритъма на gzip), и когато бъде стартиран такъв файл ядрото на FreeBSD ще го декомпресира преди да го зареди в паметта и изпълни (нямам представа дали наистина това работи). Специалният loader "#!" е точно shell loader- а. Той позволява тези файлове които не са обектни все пак да бъдат изпълнявани. Идеята е, че по този начин може да се каже на ядрото кой обектен файл да зареди и изпълни стартирайки необектен файл имащ "#!" поредица в началото си. Примерно за shell скриптовете това е "#!/bin/sh". Всъщност всичко зависи от посочения път защото ядрото в случая ще изпълни /bin/sh и ще добави истинското име на изпълнимия файл в командния ред на "интепретатора" ( в случая /bin/sh ). Практически може да се укаже всичко, дори би трябвало да може да се изпълняват MIPS асемблерски файлове в SPIM симулатора просто като се добави "#!spim на първия ред на вашия асемблерски файл. Форматът a.out все по-рядко се среща. Файлове в този формат могат да бъдат изпълнявани на FreeBSD система, но формата е почти отхвърлен, така, че го забравяме:). Наследи го elf (статията няма за цел да обяснява разликата между двата формата, за детайлно описание на a.out и elf форматите вижте съответните man страници). Така, да започнем интересната част, а това е когато ядрото на FreeBSD установи, че си има работа с някой elf (горски духове, самодиви и други *диви :). Сценариите са два ( с разклонения поради това,че имаме няколко типа elf ):

1. elf файла е свързан динамично - в този случай името на runtime-loader-a (или dynamic linker-a) е закодирано в самия файл. Loader-ите са: за FreeBSD е "/usr/libexec/ld-elf.so.1", за Linux - /lib/ld-linux.so.2 Така, че ядрото на FreeBSD се ориентира по този запис за да определи типа elf и да приложи съответния elf loader (съответното ABI).
2. elf файла е свързан статично - в този случай ядрото на FreeBSD разчита на информацията за типа elf записана в специален сектор от файла (man brandelf(1) ). Ако файла не е маркиран, няма как да се определи типа му и съответно какво ABI ползва, за това ще трябва да го маркираме ръчно с brandelf(1)

   		# brandelf -t Linux file

Понастоящем във FreeBSD има реализация на няколко типа ABI ( Application Binary Interface ): FreeBSD ABI(естествено:), Linux ABI и SRV4 ABI (Linux ABI се поддържа от FreeBSD 2.2 и нагоре, а от FreeBSD 4.1 е включена подръжка и на SRV4 ABI), за справка man brandelf(1) . Значи съществува възможността същите тези компилирани на дадена система приложения да се изпълняват и на други системи разполагащи с необходимото ABI. Но да проследим реализацията на Linux ABI във FreeBSD. Тя се базира на код към ядрото на FreeBSD наречен "Linux kernel module"и неговата задача е да реализира Linux syscall interface за Linux приложенията използвайки FreeBSD syscalls (системни повиквания или internals). Например ако някое Linux приложение генерира системното повикване fork(), то ще бъде прихванато и обработено от "Linux kernel module"и ще му се осигури Linux-съвместим fork() чрез FreeBSD syscalls. Та значи изпълнимите elf файлове са "белязани", и това се използва при създаването на процеса с цел системните повиквания които той ще генерира да бъдат насочени към "правилния обработчик". На практика това означава, че Linux binary ще създаде процес който ще използва "Linux kernel module" за обработката на системните повиквания, a FreeBSD binary ще създаде процес който ползва директно FreeBSD системни повиквания. Освен това "Linux kernel module"при стартирането на Linux binaries прави и една магия с пътя преиндексирайки го с /compat/linux, поради това, че proc файловите системи на Linux и FreeBSD са различни, а в случая това приложение се нуждае от Linux-съвместима такава. Монтирането на Linux-compatible proc в /compat/linux удовлетворява това изискване (man linprocfs ). Първо, се прави опит да се открие файла в директорията /compat/linux/original_path , ако няма успех тогава се търси в /original_path . Например ако бъде генерирано системното повикване open() от някое Linux binary, това означава, че файла ще се търси първо в йерархията /compat/linux/original_path и после в /original_path . Така се подсигурява, че могат да работят успешно binaries които изискват други binaries и също така означава, че Linux binaries могат да зареждат и изпълняват FreeBSD binaries, ако няма налични под същото име Linux binaries. Можем да поставим uname(1) в /compat/linux за да се предотврати "оплакването" на някои Linux binaries, че системата "не изглежда да е" Linux. По подобен начин се процедира и с реализацията на SRV4 ABI във FreeBSD. Технически погледнато е възможно реализирането на което и да е ABI. В случая с FreeBSD (а пък и който и да е друг UNIX вариант) е най-лесно да се имплементира поддръжка на ABI на ниво ядро на сродните UNIX OS ( Linux и FreeBSD са доста близки по отношение на функциите осигурявани от ядрото). Вероятно е възможна реализацията на ниво ядро и на Win32 или MacOS ABI ( MacOS X се брои за UNIX ), обаче хич няма да е лесно поради дълбоките различия. Но пък за подкарването на Win32 приложения можете да използвате WINE. Той работи под Linux и под FreeBSD , а освен това се разпространява и във вид на сорс код и просто може да бъде компилиран на дадената система. WINE обаче работи в т.н. user-space (не бихте искали WINE да бъде реализиран като модул към ядрото, нали ;^). WmWare се разпространява само в бинарен формат за Linux, обаче може да стартира и под FreeBSD благодарение на поддръжката на Linux ABI. WmWare също работи в user-space. С него може да се подкарват (инсталират) цяла Операционна система , а не само нейните приложения както е при WINE.

Кое е истинското ABI на FreeBSD? Ами така да се каже няма значение ... Като цяло, единствената разлика е, че FreeBSD ABI е compiled-in в ядрото (няма как иначе:), а поддръжката на Linux ABI може да бъде compiled-in или достъпнa през модул на FreeBSD ядрото (всичко работи се в kernel-space)

Дали това наистина е емулация ? Получава се малко игра на думи, но технически правилния отговор е "реализация на ABI" и то на ниво ядро (т.е. интерфейса между приложението и ОС).

Тогава защо понякога се нарича "Linux емулация''...? Защото исторически погледнато това е било реализирано по време когато не е имало дума различна от тази за да се опише какво наистина става. Казвайки,че FreeBSD изпълнява Linux binaries няма да е истина , ако не е компилиран съответния код в ядрото или не е зареден като модул, и за това е имало нужда от дума която да описва какво ще бъде зареждано - и от тук идва "Linux емулация" .

Други ресурси:

System V Application Binary Interface
SCO Developer Specifications
ABI specification for UNIX SVR4 on the Intel architecture
OpenGL® Application Binary Interface for Linux
Intel(R) Itanium(tm) Processor-specific Application Binary Interface (ABI)
Linux+FreeBSD mini HOWTO - The Penguin and the FBSD daemon play ice-hockey on one machine