18.1. | Honnan lehet többet megtudni a FreeBSD belső felépítéséről? |
Jelen pillanatban csak egyetlen mű foglalkozik az
operációs rendszerek
felépítésével a FreeBSD
szemszögéből, név szerint a Marshall
Kirk McKusick és George V. Neville-Neil által
írt „The Design and Implementation of the
FreeBSD Operating System” című könyv
(ISBN 0-201-70245-2), amely a FreeBSD
5. Emellett a UNIX® típusú rendszerek használatával kapcsolatos ismeret remekül alkalmazható a FreeBSD esetén is. A témához tartozó többi könyvet a kézikönyv Az operációs rendszerek belső működésével foglalkozó irodalomjegyzékben találhatjuk meg. | |
18.2. | Hogyan lehet bekapcsolódni a FreeBSD fejlesztésébe? |
Pontosabb tanácsokat akkor kapunk, ha elolvassuk a FreeBSD fejlesztéséről szóló cikket. Nagyon is számítunk mindenki segítségére! | |
18.3. | Mik azok a pillanatkiadások és kiadások? |
Jelenleg három aktív és félig aktív ág van a FreeBSD CVS repositoryjában. (A korábbi ágakat már csak nagyon ritkán módosítják, ezért is csak három aktív fejlesztési ágon fejlesztenek):
A Jelen pillanatban a -CURRENT a
9. | |
18.4. | Hogyan lehet saját kiadást készíteni? |
Olvassuk el a kiadások készítéséről szóló cikket. | |
18.5. | A |
Mert alapvetően ez lenne a cél: ahogy a neve
is sugallja, a rendszer újrafordítása,
vagyis a
Ha a | |
18.6. | Miért nem forgó („round robin”) névfeloldással lehet elérni a CVSup szervereket és így megosztani köztük a terhelést? |
Habár a CVSup
tükrözések óránként
frissítik magukat a központi
CVSup szerverről, maga a
frissítés azonban bármikor
megtörténhet. Ennek
következményeképpen egyes szervereken
frissebb kód található, miközben a
többin még az egy órával
ezelőtti állapot szerepel. Ha a | |
18.7. | A -CURRENT forrásait korlátozott interneteléréssel is lehet követni? |
Igen, ezt a CTM használatával anélkül is megtudjuk tenni, hogy le kellene töltenünk az egész forrásfát. | |
18.8. | Hogyan lehet 1392 KB-os darabokra felosztani az egyes terjesztéseket? |
Az újabb BSD alapú rendszerekben a
split(1) parancsnak már van egy
Íme erre egy példa a
ZIPNSPLIT= gzip --no-name -9 -c | split -b 1392k - | |
18.9. | Hova lehet küldeni a rendszermaghoz írt kiegészítéseket? |
Erre vonatkozóan vessünk egy pillantást a FreeBSD továbbfejlesztéséről szóló cikkre. Köszönjük, hogy gondolt ránk! | |
18.10. | A rendszer hogyan érzékeli és inicializálja a Plug and Play ISA kártyákat? |
Frank Durda IV
( Dióhéjban úgy tudnám ezt
elmagyarázni, hogy van néhány I/O port,
amelyet lekérdezve a PnP kártya képes
válaszolni, hogy elérhető-e.
Ezért a PnP eszközök keresése azzal
kezdődik, hogy a rendszer felteszi a
kérdést, van-e PnP kártya a
számítógépben. Erre
aztán a különböző
kártyák a típusuk
megjelölésével válaszolnak,
amelyet ugyanezen az I/O porton kell visszaolvasni,
így ha már legalább egy bitet
beállít valaki, akkor folytatható a
keresés. Ezután a keresést
végző kódrész letiltja az
Az azonosítók két 32 bit hosszúságú mezőből (ezért írtunk az előbb 264 lépést) és egy 8 bites ellenőrzőösszegből állnak. Az első 32 bit a gyártót azonosítja. Ugyan soha nem vallják be, de úgy tűnik, hogy még ugyanannak a gyártónak is lehetnek eltérő gyártóazonosítóval rendelkező kártyái. A gyártók számára fenntartott 32 bites mező ezért valamennyire túlzás. A második 32 bit lehet a kártya sorozatszáma vagy bárki más, amely alapján egyértelműen beazonosítható. A gyártó ugyanazzal a 32 bites értékkel nem gyárthat egy másik kártyát, csak abban az esetben, ha a másik 32 bit is eltér. Ennek köszönhetően egy gépen belül még az azonos típusú kártyák is el fognak térni 64 biten. Az iménti 32 bites csoportok nem lehetnek teljesen nullák, ezért lehetséges, hogy a bináris keresés során a válaszban legalább egy bit mindig aktív lesz. Miután a rendszer sikeresen beazonosította a rendelkezésre álló kártyákat, egyenként újra elindítja ezeket (ugyanazon az I/O porton keresztül), és megpróbálja kitalálni, hogy az adott eszközöknek milyen erőforrásokra van szüksége, milyen megszakítást akarnak használni stb. Az összes kártyától lekérdezi ezeket az információkat. Az így megszerzett információkat aztán még kiegészíti a merevlemezen vagy az MLB BIOS-ban található ECU állományok tartalmával. Az ECU és az MLB BIOS PnP támogatása általában viszont nem valódi, és az ilyen eszközök igazából nem is állítanak be semmit maguktól. A BIOS és az ECU átvizsgálása azonban segít a felderítést végző rutinnak értesíteni a tényleges PnP eszközöket, hogy ne foglaljanak el olyan erőforrásokat, amelyeket a rendszer nem tud áthelyezni. Ezután a PnP eszközöket a kód még egyszer végigjárja és átadja nekik a működésükhöz szükséges I/O, DMA, IRQ és memóracímek hozzárendeléseit. Az eszközök ekkor a megadott helyeken elérhetővé válnak és úgy is maradnak a rendszer következő indításáig, de igazából semmi sem rögzíti ezeket. Talán túlságosan is egyszerűsítettem a fentieket, de szerintem már ennyi is elegendő az alapok megértéséhez. A Microsoft® néhány elsődleges
nyomtatási állapotot jelző portot
átrakott PnP-re, azzal a címszóval,
hogy egyik kártya sem kódolta át ezeket
a címeket az ellenkező I/O ciklusok
számára. Találtam is egy eredeti IBM
nyomtatókártyát, amely valóban
át tudta írni az állapotjelző
portot a PnP kezdeti változataiban, de arra a
Microsoft® csak annyit mondott, hogy
„fogós”. Ezért a
nyomtatási állapotot jelző portot a
címek beállítására
használja, illetve még a
| |
18.11. | Hogyan lehet főeszközazonosítót rendelni egy általunk fejlesztett meghajtóhoz? |
2003 februárja óta a FreeBSD képes dinamikusan és önműködően futás közben lefoglalni főeszközazonosítókat a meghajtóknak (lásd devfs(5)), ezért erre tulajdonképpen már nincs szükség. | |
18.12. | A könyvtárakra vonatkozóan milyen más kiosztási házirendek léteznek még? |
A könyvtárak más fajta
kiosztására vonatkozóan annyit tudok
válaszolni, hogy a jelenleg is alkalmazott
sémát az 1983-ban megalkotott változata
óta változatlanul használjuk.
Eredetileg a gyors állományrendszerhez
készítettem, de soha nem ragaszkodtam
hozzá. Remekül megoldja a cilindercsoportok
betelésének problémáját,
azonban sokan megjegyezték már, hogy a
find(1) esetén gyengén működik.
A legtöbb állományrendszert
mélységi bejárással
hozzák létre, így a
könyvtárak szétszóródnak a
cilindercsoportok közt és ezzel a
későbbi mélységi keresések
számára a lehető legrosszabb helyzetet
alakítják ki. Ha valaki például
tudja előre a létrehozni kívánt
könyvtárak számát, akkor ezt
úgy lehet megoldani, ha a művelet során
Kirk McKusick, 1998 szeptembere | |
18.13. | Hogyan lehet kinyerni a legtöbb információt a rendszermag összeomlásából? |
Általában így néz ki a rendszermag összeomlása: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x40 fault code = supervisor read, page not present instruction pointer = 0x8:0xf014a7e5 stack pointer = 0x10:0xf4ed6f24 frame pointer = 0x10:0xf4ed6f28 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 80 (mount) interrupt mask = trap number = 12 panic: page fault Amikor egy ilyen üzenetet látunk, akkor nem
elegendő újra előcsalni a hibát
és beküldeni. Az
utasításszámláló
(„instruction pointer”) értéke
ugyan nagyon fontos, de sajnos konfigurációk
szerint eltérhet. Más szóval
úgy fogalmazhatnék, hogy ennek az
értéke a használatban levő
rendszermag értékétől
függően változhat. Ha a
Ezért a javaslatom a következő:
A legjobb viszont mégis az, amikor sikerül lementeni a hiba bekövetkezésekor a memória tartalmát, majd a kgdb(1) használatával előbányászni belőle egy hívási láncot. Ehhez többnyire a következő módszer javasolt:
Megjegyzés:A A make(1) programnak a folyamat
végeredményeként két rendszermagot
kell készítenie: a
A rendszer csak akkor fogja elmenteni
összeomláskor a memória tartalmát,
ha az Megjegyzés:A FreeBSD által létrehozott
memóriamentések mérete
általában a
számítógépünkben
levő fizikai memória
mennyiségével egyezik meg. Tehát
ha 512 MB RAM van a gépünkben, akkor
egy 512 MB méretű mentést fogunk
kapni. Ezért gondoskodjunk róla, hogy a
Ahogy sikerült hozzájutnunk a memóriamentéshez, azonnal is kérhetünk a kgdb(1) használatával egy hívási láncot belőle:
Előfordulhat, hogy ilyenkor több oldalnyi információ özönlik hirtelen a képernyőre, ezért javasolt ezeket lementeni a script(1) programmal. A nyomkövetési szimbólumokat is tartalmazó rendszermag esetén még akár azt a sort is megkapjuk a rendszermagon belül, ahol a hiba történt. A hívási láncot általában alulról felfelé kell olvasni, és ebből deríthető, hogy pontosan milyen események is vezettek az összeomláshoz. A kgdb(1) használatával még a különböző változók és struktúrák értékeit is meg tudjuk vizsgálni, így még többet megtudhatunk a rendszer állapotáról az összeomlás pillanatában. Tipp:Ha az iméntiek mentén nagyon fellelkesültünk volna és van egy másik számítógépünk is, akkor a kgdb(1) akár távoli nyomkövetésre is beállítható, aminek köszönhetően a kgdb(1) használatával az egyik rendszeren meg tudjuk állítani a másikon futó rendszermagot, ellenőrizhetjük a viselkedését, akárcsak bármelyik más felhasználói program esetében. Ha netalán engedélyeztük volna a
| |
18.14. | A |
Az ELF állományokhoz tartozó
segédprogramok alapértelmezés szerint nem
teszik láthatóvá a dinamikus linker
számára a végrehajtható
állományban definiált
szimbólumokat. Ennek eredményeképpen a
Ha szükségünk lenne ilyen
keresésekre a | |
18.15. | Hogyan növelhető vagy csökkenthető a rendszermag címtere i386™ architektúrán? |
Az i386™ platformon a rendszermag címtere alapértelmezés szerint 1 GB (PAE esetén 2 GB). Ha komolyabb hálózati forgalmat bonyolító szerverünk van (például egy nagyobb FTP vagy HTTP szerver) vagy rendszerükön használni akarjuk a ZFS állományrendszert, akkor könnyen kifuthatunk a címtérből. A címtér méretének megváltoztatásához vegyük fel a következő sort a rendszermag konfigurációs állományába, majd fordítsuk újra a rendszermagot: options KVA_PAGES= Az |
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>.