Annak megértéséhez, hogy a FreeBSD miért az elf(5) formátumot használja, először is tisztában kell lennünk a UNIX(R) típusú rendszerekben használt végrehajtható állományok három "uralkodó" formátumával:
A legősibb és egyben a "klasszikus" UNIX(R)-os tárgykódformátum. Egy tömör és rövidke fejlécet használ, aminek az elején a formátum leírására szolgáló "bűvös szám" található (erről bővebben lásd a.out(5)). Három betöltött szegmenst tartalmaz: .text, .data és .bss, valamint egy szimbólumokat és karakterláncokat tároló táblát.
COFF
Az SVR3 tárgykódformátuma. A fejléc itt már tartalmaz egy table nevű szegmenst is, tehát a .text, .data és .bss szegmensekhez hasonlóan ebből is többet tud tárolni.
A COFF után következő formátum, amelyben több szegmens is megtalálható, valamint létezik 32 bites és 64 bites változatban is. Egyetlen hátránya van: az ELF tervezése során rendszerarchitektúránként csupán egyetlen ABI-t (bináris alkalmazói felületet) feltételeztek. Ez azonban meglehetősen helytelen, mivel még a kereskedelmi SYSV világában (ahol már legalább három ABI található: SVR4, Solaris és SCO) sem állja meg a helyét.
A FreeBSD ezt a problémát a megbélyegzés (branding) segítségével próbálja megoldani, aminek révén el tudunk látni egy ismert ELF állományt a futtatásához megfelelő ABI-ra vonatkozó információkkal. Erről részletesebben a brandelf(1) oldalán tájékozódhatunk.
A FreeBSD a "klasszikusok"
táborából indult, ezért kezdetben az
a.out(5) formátumot használta, mivel ez a
technológia a BSD kiadások számos
generációjában megmérettetett
és bevált, egészen a 3.X ág
elindulásáig. Habár már jóval
előtte lehetett fordítani és futtatni
natív ELF binárisokat (és
rendszermagokat) a FreeBSD rendszereken, a FreeBSD kezdetben
ódzkodott váltani az alapértelmezés
szerinti ELF formátumra. De vajon
miért? Nos, amikor a Linux-tábor megtette a maga
fájdalmas váltását az
ELF-re, az nem annyira azért volt, hogy
megszabaduljanak az a.out
végrehajtható formátumtól, hanem mert
a rugalmatlan, ugrótáblákon alapuló
oszottkönyvtár-kezelési mechanizmusaik nagyon
megnehezítették a gyártók és
fejlesztők számára az osztott
függvénykönyvtárak
létrehozását. Mivel az
ELF formátumhoz rendelkezésre
álló eszközök megoldást
kínáltak az osztott könyvtárak
gondjaira, és mivel általánosan
elfogadták "a jövőbe vezető
útként", a FreeBSD is felvállalta az
átállással kapcsolatos
költségeket és végrehajtotta azt. A
FreeBSD az osztott könyvtárakat leginkább a Sun
SunOSTM rendszeréhez hasonlóan kezeli, ami egy
nagyon könnyen használható
megoldás.
De miért van ilyen sok különböző formátum?
A ködös és sötét múltban
egyszerűbb hardverek voltak. Ezek az egyszerű hardverek
egyszerű, kicsi rendszereket támogattak. Az
a.out
tökéletesen megfelelő
volt egy ilyen egyszerű rendszer (egy PDP-11)
binárisainak tárolására. Ahogy az
emberek nekiláttak átültetni erről az
egyszerű rendszerről a UNIX(R)-ot más
rendszerekre, az a.out
formátumot
továbbra is megtartották, mivel a UNIX(R) kezdeti,
Motorola 68k-ra, VAXenre készített
átírataihoz is elegendő volt.
Ezután néhány éles
elméjű hardvermérnök kitalálta,
ha rá tudnák kényszeríteni a
programokat egy-két ügyetlen trükkre, akkor a
terveken meg tudnának spórolni néhány
logikai kaput és ezzel a processzor is gyorsabban tudna
futni. Miközben az a.out
formátumot ilyen hardverre (amit manapság
RISC-nek hívnak) is szerették
volna áthozni, kiderült, hogy ebben az esetben szinte
használhatatlan. Ezért az
a.out
formátum által
felkínáltnál nagyobb
teljesítmény elérése
érdekében nekiláttak számos más
formátumot is kidolgozni. Ekkor jöttek létre a
COFF, ECOFF és
más hasonló formátumok, amelyek
előbb-utóbb korlátokba ütköztek,
még mielőtt a történelem
megállapodott volna az ELF
formátumnál.
Ráadásul a programok méretei egyre
inkább kezdtek nőni, miközben a lemezek (valamint
a fizikai memória) továbbra is viszonylag kicsik
maradtak, ezért megszületett az osztott
könyvtár ötlete, és a virtuális
memóriát kezelő alrendszer is sokat finomodott.
Mivel ezek a különböző fejlesztések az
a.out
formátumra épültek,
annak használatósága a beletömött
módosítások számával
együtt romlott. Emellett az emberek még szerettek
volna betölteni különféle dolgokat
futási időben dinamikusan, vagy éppen a
memória és a lapozóállomány
megspórolásához kipucolni a programjaik egyes
részeit az inicializáló
kódrészletek lefutása után. A
programozási nyelvek is fejlődtek, és az
emberek a főprogram futása előtt is akartak
kódot futtatni. Az a.out
formátum rengeteg apró foltozáson esett
keresztül, amelyek egy ideig még tudták is
tartani magukat. Azonban egy idő után már az
a.out
formátum egyre növekvő
teljesítménycsökkenés nélkül
már nem volt képes állni a sarat.
Habár az ELF megszüntette a
fennálló problémák jelentős
részét, egyúttal megnehezítette egy
alapvetően működő rendszer
leváltását. Ezért az
ELF formátumnak meg kellett
várnia azt a pillanatot, amikorra az
a.out
használata már
kényelmetlenné vált.
Azonban ahogy múlt az idő, az eszközökből, amelyekből a FreeBSD a fordításához szükséges eszközöket származtatta (különösen az assembler és a betöltő),létrejött két párhuzamos fejlesztési fa. A FreeBSD-fa kiegészült az osztott könyvtárak támogatásával és hibákat javított, miközben a GNU-fa alkotói, akik eredetileg készítették ezeket a programokat, újraírták az eszközeiket és a keresztfordításhoz egyszerűbb támogatást készítettek, cserélhetővé tették a különböző formátumokat és így tovább. Sokan akartak FreeBSD-re keresztfordítani, azonban nem volt szerencséjük, mert a FreeBSD régebbi forrásait az as és ld már nem emésztette meg. Az új GNU eszköztár (a binutils) viszont ismeri már a keresztfordítást, az ELF formátumot, az osztott könyvtárakat, a C++ kiterjesztéseit stb. Időközben egyre több gyártó ELF formátumú binárisokat adott ki, és jó érzés volt ezeket FreeBSD-n is futtatni.
Az ELF sokkal kifejezőbb az
a.out
formátumnál, és
jóval több bővítési
lehetőséget enged az alaprendszerben. Az
ELF formátumhoz tartozó
eszközöket jobban karbantartják és
támogatja a keresztfordítást, ami viszont
sokaknak fontos. Az ELF talán
némileg lassabb, mint az a.out
,
azonban ez nehezen mérhető le. Számos
részletben eltérnek ugyan, például
hogyan képeznek le lapokat, hogyan kezelik az
inicializáló kódot stb., de ezek egyike sem
igazán fontos. Idővel az a.out
támogatása ki fog kerülni a
GENERIC
rendszermagból, és
végül majd teljesen eltávolításra
kerül, ahogy a régi a.out
formátumú programok szépen lassan
kifutnak.
Ha kérdése van a FreeBSD-vel kapcsolatban, a
következő címre írhat (angolul):
<questions@FreeBSD.org>.
Ha ezzel a dokumentummal kapcsolatban van kérdése, kérjük erre a címre írjon:
<gabor@FreeBSD.org>.