Są to argumenty nie dotyczące żadnych konkretnych sterowników czy urządzeń peryferyjnych. Odnoszą się natomiast do wewnętrznych parametrów jądra, takich jak: obsługa pamięci, obsługa RAM-dysku, obsługa głównego systemu plików itd.
Następujące argumenty mają wpływ na to jak jądro będzie obsługiwać główny system plików:
Poprzez ten argument możemy przekazać do jądra które urządzenie ma
być użyte jako główny system plików. Domyślnym ustawieniem jest
tutaj urządzenie, na którym był główny system plików, podczas
tworzenia (kompilacji) jądra. Na przykład jeśli dane jądro
było utworzone na systemie, w którym główny system plików był na
urządzeniu /dev/hda1 wtedy domyślnym ustawieniem będzie
"/dev/hda1". Aby to zmienić i ustawić drugą stację dyskietek jako
główny system plików trzeba użyć argumentu root= w
następujący sposób:
root=/dev/fd1
Główny system plików może być zamontowany na następujących urządzeniach:
(1) /dev/hdaN do /dev/hddN, gdzie N jest numerem partycji na dysku
pierwszym, drugim, trzecim lub czwartym kompatybilnym z ST-506.
(2) /dev/sdaN do /dev/sdeN, gdzie N jest numerem partycji na dysku
pierwszym, drugim, trzecim, czwartym lub piątym kompatybilnym z SCSI.
(3) /dev/xdaN do /dev/xdbN, gdzie N jest numerem partycji na dysku
pierwszym lub drugim kompatybilnym z XT.
(4) /dev/fdN, gdzie N jest numerem stacji dyskietek (N=0 - A:, N=1 - B:)
(5) /dev/nfs, co raczej nie jest urządzeniem a argumentem, który mówi,
żeby zamontować główny system plików poprzez sieć.
Inna znacznie bardziej kłopotliwa i skomplikowana metoda
przekazania, na którym urządzeniu ma być główny system plików jest
podanie liczby głównej i pobocznej (np. /dev/sda3 to liczba główna - 8,
liczba poboczna - 3 a więc mógłbyś napisać root=0x803.
To jest jeden z kilku argumentów startowych, który ma zapisaną
domyślną wartość w jądrze, i który przez to może być zmieniany za
pomocą rdev.
Kiedy jądro ładuje system, potrzebuje głównego systemu plików, aby
odczytać z niego podstawowe informacje. To jest główny system
plików montowany podczas ładowania. Chociaż, jeśli system ten
jest zamontowany z możliwoscią zapisu, nie możesz dokładnie
sprawdzić jego integralności (poprawności) jeśli akurat trwa
zapis pliku. Argument ro przekazuje do jądra
informację, aby zamontować główny system plików jako
tylko-do-odczytu, tak więc jakikolwiek program sprawdzający
poprawność systemu plików może założyć, że nie ma żadnych częściowo
zapisanych plików podczas sprawdzania. Żaden program ani proces
nie może zapisać niczego do pliku dopóki system plików nie
zostanie przemontowany w tryb odczytu-zapisu (read-write).
To jest jeden z kilku argumentów startowych, który ma zapisaną
domyślną wartość w jądrze, i który przez to może być zmieniany za
pomocą rdev.
To jest dokładną odwrotnością poprzedniego argumentu, czyli
przekazuje do jądra, aby zamontować główny system plików z
możliwoscią zapisu. Tak czy inaczej ostatecznie chcemy mieć
możliwość zapisu na głównym systemie plików. Ale pamiętaj, aby nie
uruchamiać żadnych programów testujących (typu fsck)
system plików kiedy jest on zamontowany z możliwością zapisu.
Ta sama wartość zapisana w jądrze wspomniana wyżej jest używana do
tego argumentu, dostępna przez rdev.
Następujące argumenty są związane z tym jak jądro obsługuje RAM-dysk, który jest zwykle używany do bootstrappingu podczas instalacji lub na maszynach ze sterownikami w postaci modułów, które muszą być zainstalowane aby mieć dostęp do głównego systemu plików.
Aby pozwolić obrazowi jądra na przebywanie na dyskietce wraz ze
skompresowanym obrazem RAM-dysku dodany został argument
`ramdisk_start=<offset>'. Jądro nie może być zawarte w
skompresowanym obrazie głównego systemu plików na RAM-dysku,
ponieważ musi ono być zapisane poczynając od bloku 0, tak aby BIOS
mógł załadować bootsektor i wtedy jądro może zacząć się
ładować.
Uwaga: Jeśli używasz rozpakowanego obrazu RAM-dysku, wtedy jądro może być częścią obrazu głównego systemu plików, który jest ładowany do RAM-dysku i system może wystartować z tej dyskietki, albo obraz głównego systemu plików i jądro mogą być dwiema oddzielnymi dyskietkami, tak jak w przypadku skompresowanego obrazu.
Jeśli używasz dwóch dyskietek (bootdysk z jądrem i rootdysk z
obraze RAM-dysku) wtedy RAM-dysk zaczyna się od bloku 0 i jako
offset w naszym przykładzie trzeba wpisać 0. Ponieważ
jest to domyślna wartość nie musisz w tym przypadku używać tego
argumentu.
Ten argument informuje jądro czy ma ono ładować RAM-dysk czy nie.
Pisząc load_ramdisk=1 informujesz jądro, aby załadować
zawartość dyskietki do RAM-dysku. Domyślną wartością jest 0, czyli
jądro nie ma ładować zawartości dyskietki do RAM-dysku.
Dokładny opis argumentów startowych dotyczących RAM-dysku
znajdziesz w linux/Documentation/ramdiskt.txt. Jest tam
także opisane w jaki sposób można zapisać w jądrze wartość tego
parametru poleceniem rdev.
Ten argument informuje jądro czy wypisywać prośbę o włożenie
dyskietki z zawartością RAM-dysku czy nie. W konfiguracji z jedną
dyskietką zawartość RAM-dysku jest na tej samej dyskietce co jądro,
które się właśnie przestało ładować, a więc prośba nie jest
potrzebna. W tym wypadku można użyć prompt_ramdisk=0.
W konfiguracji z dwiema dyskietkami potrzebujesz czasu na zamianę
dyskietek a więc należy użyć prompt_ramdisk=1. Ponieważ
to jest wartość domyślna nie trzeba tego pisać.
(Uwaga historyczna: Co sprytniejsi używali opcji LILO vga=ask,
aby na chwilę przerwać start systemu i zamienić dyskietki.)
Dokładny opis argumentów startowych dotyczących RAM-dysku
znajdziesz w linux/Documentation/ramdiskt.txt. Jest tam
także opisane w jaki sposób można zapisać w jądrze wartość tego
parametru poleceniem rdev.
Ponieważ prawdą jest, że zawartość RAM-dysku rośnie dynamicznie wraz z coraz nowszymi wersjami systemu, jest górne ograniczenie jego rozmiaru, tak aby nie zabrał całej pamięci RAM i nie zostawił nas na lodzie. Domyślną wartością jest 4096 (czyli 4MB), która powinna być wystarczająco duża dla większości potrzeb. Możesz zmienić tę wartość zależnie od potrzeb na mniejszą lub większą przy pomocy tego argumentu.
Dokładny opis argumentów startowych dotyczących RAM-dysku
znajdziesz w linux/Documentation/ramdiskt.txt. Jest tam
także opisane w jaki sposób można zapisać w jądrze wartość tego
parametru poleceniem rdev.
(UWAGA: Ten argument jest przestarzały i nie powinien być używany z jądrami w wersji wyższej niż 1.3.47. Argumenty, których należy używać zostały opisane powyżej.)
Argument ten określa rozmiar RAM-dysku w kB. Na przykład jeśli ktoś chciałby mieć główny system plików na dyskietce 1.44MB załadowanej do RAM-dysku użyłby następującego argumentu:
ramdisk=1440
To jest jeden z kilku argumentów startowych, który ma zapisaną
domyślną wartość w jądrze, i który przez to może być zmieniany
za pomocą rdev.
Jądra w wersji 2.x i wyższej mają możliwość wykonywania
/linuxrc z zawartości RAM-dysku. Możliwość ta jest zwykle
wykorzystywana, aby umożliwić ładowanie modułów potrzebnych do
zamontowania rzeczywistego głównego systemu plików (np. załaduj
sterownik SCSI zapisany w RAM-dysku, a potem zamontuj rzeczywisty
główny system plików znajdujący się na dysku SCSI.)
Właściwy argument "noinitrd" określa co dzieje się z danymi initrd
po tym jak jądro się załadowało. Jeśli podamy ten argument dane te
staną się dostępne poprzez urządzenie specjalne /dev/initrd,
które może być czytane zanim pamięć RAM zostanie przywrócona systemowi,
zamiast być zapisanymi do RAM-dysku. Odnośnie szczegółów dotyczących
używania startowego RAM-dysku, przeczytaj
linux/Documentation/initrd.txt. Najnowsza wersja LILO
oraz loadlin.exe powinna mieć także dodatkowe informacje
na ten temat.
Następujące argumenty określają jak Linux wykrywa i obsługuje pamięć fizyczną i wirtualną w twoim systemie.
Ten argument ma dwa przeznaczenia: Pierwotnym założeniem było
określenie ilości zainstalowanej pamięci (lub wartość mniejsza
jeśli chciałeś użyć mniej pamięci niż masz w rzeczywistości).
Drugim (prawie wcale nie używanym) przeznaczeniem jest podanie
mem=nopentium co informuje jądro, aby nie używało stron
pamięci o rozmiarze 4MB.
Oryginalne odwołanie do BIOS-u w specyfikacji PC, które zwraca ilość zainstalowanej pamięci zostało tak zaprojektowane, że było w stanie zwrócić co najwyżej 64MB. (Tak! Następny przykład na brak patrzenia w przyszłość, zupełnie tak samo jak w przypadku ilości cylindrów dysku ograniczonej do 1024... eh). Linux używa tego odwołania BIOS-u podczas startu, aby określić ilość zainstalowanej pamięci. Jeśli masz więcej niż 64MB RAM-u, możesz użyć tego argumentu, aby poinformować jądro, ile rzeczywiście masz pamięci RAM. Oto cytat Linusa na temat jak używać tego argumentu:
"Jądro zaakceptuje jakikolwiek argument "mem=xx" jaki mu podasz, a
jeśli stwierdzi, że je okłamałeś, wywali się z wielkim hukiem wcześniej
czy później. Argument ten określa najwyższy dostępny adres pamięci
RAM, więc mem=0x1000000 znaczy, że masz 16MB RAM-u na
przykład. Dla maszyny z 96MB RAM-u byłoby to: mem=0x6000000.
UWAGA UWAGA UWAGA: niektóre maszyny mogą używać najwyższych adresów do cache'owania BIOS-u czy czegoś podobnego, więc mógłbyś nie mieć pełnych 96MB RAM-u dostępnego. I na odwrót: niektóre procesory odwzorowują pamięć fizyczną, która jest zakryta przez BIOS tuż za najwyższym dostępnym adresem, tak więc ten najwyższy adres mógłby być np: 96MB + 384kB. Jeśli poinformujesz Linux-a, że ma więcej pamięci niż w rzeczywistości, będą się dziać złe rzeczy: może nie od razu, ale kiedyś na pewno."
Zauważ, że wartość tego argumentu nie musi być podana szesnastkowo
a przyrostki "k" i "M" (wielkość liter nie ważna) mogą być
użyte do określenia odpowiednio kilobajtów i Megabajtów. ("k"
spowoduje przesunięcie 10 bitowe podanej wartości, a "M" - 20
bitowe) Powyższe ostrzeżenie jest wciąż ważne, ponieważ maszyna z
96MB pamięci może działać z argumentem mem=97920k ale
może nie działać z mem=98304k lub mem=96M.
Argument ten pozwala użytkownikowi podać kilka parametrów pamięci wirtualnej, które są związane z pamięcią swap. Można tu podać następujące parametry:
MAX_PAGE_AGE
PAGE_ADVANCE
PAGE_DECLINE
PAGE_INITIAL_AGE
AGE_CLUSTER_FRACT
AGE_CLUSTER_MIN
PAGEOUT_WEIGHT
BUFFEROUT_WEIGHT
Zainteresowani hackerzy proszeni są o przeczytanie linux/mm/swap.c
a także /proc/sys/vm.
Podobnie do argumentu "swap=" ten pozwala użytkownikowi podać kilka parametrów związanych z obsługą pamięci buforowej. Akceptuje następujące parametry:
MAX_BUFF_AGE
BUFF_ADVANCE
BUFF_DECLINE
BUFF_INITIAL_AGE
BUFFEROUT_WEIGHT
BUFFERMEM_GRACE
Zainteresowani hackerzy proszeni są o przeczytanie linux/mm/swap.c
a także /proc/sys/vm.
Linux obsługuje bezdyskowe stacje robocze, które mają zamontowany
główny system plików jako NFS (Network File System). Argumenty te
używane są, aby przekazać systemowi z jakiego komputera ma sobie
zamontować główny system plików. Zauważ także, że wymagany jest w
tym przypadku argument root=/dev/nfs. Szczegóły na temat
używania głównego systemu plików zamontowanego jako NFS znajdują
się w pliku linux/Documentation/nfsroot.txt. Powinieneś
go przeczytać, gdyż ten paragraf jest tylko streszczeniem tamtego
pliku.
Argument ten informuje jądro jakiej maszyny użyć, jakiego katalogu na niej i jakich opcji NFS podczas montowania głównego systemu plików. Argument ten ma następującą postać:
nfsroot=[<serwer-ip>:]<gł.sys.pl.>[,<opcje-nfs>]
Jeśli argument nfsroot nie jest podany wtedy użyte
zostanie "/tftpboot/%s". Kolejne opcje tego argumentu
oznaczają:
<serwer-ip> - Określa adres IP serwera NFS. Jeśli to pole nie jest podane, użyta zostanie wartość zmiennej nfsaddrs (patrz poniżej). Jedną z możliwości użycia tego parametru jest na przykład pozwolenie na użycie różnych serwerów dla RARP i NFS. Zwykle możesz zostawić ten parametr pusty.
<gł.sys.pl.> - Nazwa katalogu na serwerze, który ma być zamontowany jako główny system plików. Jeśli użyty jest znak "%s", zostanie on zamieniony na znakową reprezentację numeru IP klienta.
<opcje-nfs> - Standardowe opcje NFS. Wszystkie opcje są oddzielone od siebie przecinkami. Jeśli pole "opcje-nfs" nie jest podane, zostaną użyte następujące wartości domyślne:
port = podany przez demona "portmap" z serwera
rsize = 1024
wsize = 1024
timeo = 7
retrans = 3
acregmin = 3
acregmax = 60
acdirmin = 30
acdirmax = 60
flags = hard, nointr, noposix, cto, ac
Ten argument ustawia różne adresy interfejsu sieciowego, które są wymagane do komunikacji przez sieć. Jeśli argument ten nie jest podany, wtedy jądro próbuje użyć protokołów RARP bądź BOOTP, aby znaleźć te parametry. Argument ten ma następująca postać:
nfsaddrs=<mój-ip>:<serw-ip>:<r-ip>:<netmask>:<nazwa>:<urz>:<auto>
<mój-ip> - Adres IP klienta. Jeśli jest on pusty, zostanie wykryty przy pomocy RARP albo BOOTP. Jaki protokół jest używany, zależy od tego co zostało udostępnione podczas kompilacji jądra i od parametru <auto>. Jeśli parametr ten nie jest pusty, ani RARP ani BOOTP nie zostanie użyty.
<serw-ip> - Adres IP serwera NFS. Jeśli RARP został użyty do wykrycia adresu klienta i parametr ten nie jest pusty akceptowane będą odpowiedzi tylko z wyspecyfikowanego serwera. Aby użyć różnych serwerów RARP i NFS, podaj swój serwer RARP tutaj (lub zostaw pusty), a serwer NFS podaj w argumencie nfsroot (patrz wyżej). Jeśli parametr ten jest pusty, użyty jest adres serwera, który odpowiedział na pytanie RARP lub BOOTP.
<r-ip> - Adres IP rutera jeśli serwer jest w innej podsieci. Jeśli opcja ta jest pusta żaden ruter nie jest używany i przyjmowane jest, że serwer znajduje się w sieci lokalnej, o ile nie odebrano wartości poprzez BOOTP.
<netmask> - Maska sieci dla lokalnego interfejsu sieciowego. Jeśli opcja ta jest pusta, maska jest wyprowadzana z numeru IP klienta, o ile nie otrzymano wartości poprzez BOOTP.
<nazwa> - Nazwa klienta. Jeśli opcja ta jest pusta, adres IP klienta używany jest w notacji znakowej lub wartość otrzymana poprzez BOOTP.
<urz> - Nazwa urządzenia sieciowego, które ma zostać użyte. Jeśli opcja ta jest pusta, wszystkie urządzenia są używane do żądań RARP, a pierwsze znalezione dla BOOTP. Dla NFS używane jest to urządzenie, dla którego zostały otrzymane odpowiedzi RARP lub BOOTP. Jeśli masz tylko jedno urządzenie możesz spokojnie zostawić tę opcję pustą.
<auto> - Metoda, która ma być użyta do autokonfiguracji. Jeśli jest to "rarp" lub "bootp" używany jest podany protokół. Jeśli wartością jest "both" lub opcja ta jest pusta, oba protokoły są używane jeśli tylko są wkompilowane w jądrze. Używając "none" informujesz, aby nie używać autokonfiguracji. W tym przypadku musisz podać wszystkie potrzebne wartości poprzednich pól.
Parametr <auto> może pojawić się samotnie jako wartość argumentu "nfsaddrs" (bez tych wszystkich ":" znaków przedtem) wtedy używana jest autokonfiguracja. Aczkolwiek wartość "none" nie jest dostępna w tym przypadku.
Te różne argumenty startowe pozwalają użytkownikowi ustawić pewne wewnętrzne parametry jądra.
Jądro podaje ważne (i mniej ważne) informacje do użytkownika
poprzez funkcję printk(). Jeśli informacja jest
rozpoznawana jako ważna, funkcja printk() umieści kopię
na bieżącej konsoli jak również przekaże ją do demona klogd
tak aby wiadomość ta została zapisana na dysk. Powód, dla którego
informacje te są wysyłane na konsolę jak i zapisywane na dysk jest
taki, że w pewnych nieszczęśliwych warunkach (np: awaria dysku)
informacje te mogą nie dotrzeć na dysk i zostałyby stracone.
Próg, wg. którego informacja jest uważana za ważną lub nie
ustawiany jest przez zmienną console_loglevel. Wartością
domyślną jest zapisywanie wszystkiego ważniejszego (o mniejszym
poziomie, a tym samym większym priorytecie) niż DEBUG
(poziom 7) na konsolę. (poziomy te zdefiniowane są w pliku
nagłówkowym kernel.h). Podanie argumentu startowego
debug ustawi poziom logowania na konsolę na 10, tak, że
wszystkie informacje z jądra pojawią się na konsoli.
Poziom logowania na konsolę może zwykle być ustawiony także
podczas normalnej pracy systemu poprzez opcję programu
klogd. Sprawdź w systemie pomocy "man" jak to zrobić.
Jądro standardowo po załadowaniu się uruchamia program "init",
który następnie zajmuje się przygotowaniem systemu dla użytkownika
poprzez uruchomienie programów getty, skryptów "rc" itp. Jądro
najpierw szuka /sbin/init, następnie /etc/init a
na końcu spróbuje użyć /bin/sh (możliwie w /etc/rc).
Jeśli na przykład twój program init popsuł się i nie jest możliwy
restart systemu, możesz użyć argumentu init=/bin/sh,
który spowoduje uruchomienie shell-a natychmiast po załadowaniu
jądra, umożliwiając ci zamianę popsutego programu na dobry.
Niektóre koprocesory i387 mają błędy, które pojawiają się jeśli używamy 32-bitowego trybu chronionego. Na przykład niektóre wczesne procesory ULSI-387 mogą powodować poważne zawieszenia podczas używania operacji zmiennoprzecinkowych, widocznie z powodu błędu w instrukcjach FRSAV/FRRESTOR. Użycie argumentu startowego "no387" spowoduje ignorowanie koprocesora przez Linux-a nawet jeśli go masz. Oczywiście musisz mieć wkompilowaną emulację koprocesora w jądrze! Może to być także przydatne jeśli masz jedną z tych naprawdę starych maszyn 386, które mogą używać 80287 FPU, a Linux nie umie tego używać.
Rodzina procesorów i386 (a co za tym idzie i nowsze) mają instrukcję "hlt", która informuje procesor, że nic się nie stanie dopóki jakieś zewnętrzne urządzenie (klawiatura, modem, dysk, itp.) nie zażąda jakiejś akcji. To pozwala na użycie trybu "low-power", który powoduje, że procesor siedzi jak zombi i czeka aż coś zażąda jakiejś akcji (zwykle poprzez przerwanie), co powoduje mniejsze zużycie prądu. Niektóre z wczesnych procesorów i486DX-100 miały problem z tą instrukcją, przez co nie mogły niezawodnie powrócić do trybu działania po użyciu tej instrukcji. Używając argumentu "no-hlt" informujesz Linux-a, aby po prostu robił sobie nieskończoną pętlę jeśli nie ma nic mądrzejszego do roboty, a nie zatrzymywał procesora jeśli nic się nie dzieje. To pozwala ludziom z tymi popsutymi procesorami używać Linux-a, chociaż lepiej, żeby spróbowali wymienić ten procesor.
Użycie tego argumentu startowego powoduje wyłączenie możliwości scrolowania, która powoduje utrudnienie użycia terminali Braille'a.
W nieprawdopodobnym przypadku paniki jądra (tj. wewnętrznego błędu,
który został wykryty przez jądro, i który jądro decyduje się uważać
na tyle poważnie, aby głośno jęknąć i wszystko zatrzymać) domyślnym
zachowaniem się jądra jest po prostu siedzieć i czekać aż ktoś
przyjdzie i zauważy informację o panice i zresetuje maszynę.
Aczkolwiek jeśli maszyna jest rzadko odwiedzana, sensowny jest
automatyczny reset. Na przykład używając "panic=30" podczas startu
informujemy jądro aby po 30 sekundach spróbowało zresetować
maszynę. Wartość 0 powoduje zachowanie domyślne.
Zauważ, że wartość ta może być także podana poprzez funkcję
sysctl wywołaną na interfejsie /proc/sys/kernel/panic.
Ci, którzy chcą ingerować w wewnętrzne działanie jądra, mogą podać
argument, który pozwala na określenie jak i gdzie jądro ma spędzać
cykle procesora, aby doprowadzić do maksymalnego wykorzystania
jego możliwości. Ten argument pozwala ustawić licznik przesunięć
podczas startu. Typowo ustawiony jest on na dwa. Możesz także
skompilować jądro z domyślnie ustawioną możliwością profilowania.
W każdym z tych przypadków potrzebujesz takiego narzędzia jak
readprofile.c, które umie używać /proc/profile.
Opcja ta kontroluje sposób w jaki Linux restartuje komputer
(typowo poprzez /sbin/init, który obsługuje kombinację
klawiszy Control-Alt-Delete). Domyślnym zachowaniem co do późnych
jąder jest tzw. "zimny" restart (tzn. pełen restart, wraz ze
sprawdzaniem pamięci przez BIOS itp.) zamiast "ciepłego" restartu
(tj. niepełen restart, bez testowania pamięci). Wartość domyślną
zmieniono na "zimny" ponieważ taki restart, w przeciwieństwie do
"ciepłego", wydaje się działać na tanim/popsutym sprzęcie. Aby
przywrócić dawne zachowanie (tj. "ciepły" restart) użyj
reboot=w albo właściwie jakiekolwiek słowo zaczynające się na
w zadziała.
Po co zawracać sobie głowę? Niektóre kontrolery dysków z własną pamięcią cache może wykrywać "ciepły" restart, i zapisywać wszystkie dane z pamięci cache na dysk. Podczas "zimnego" restartu, karta może zostać zrestartowana i wszystkie dane z cache'u zostaną stracone. Inni raportowali systemy, którym sprawdzanie pamięci zabierało dużo czasu czy dłuższy czas inicjalizacji BIOS-ów SCSI.
Argument ten jest używany do ochrony obszarów portów I/O przed przeszukiwaniem.
reserve=iobase,extent[,iobase,extent]...
W niektórych maszynach może być konieczne, aby powstrzymać sterowniki urządzeń przed automatyczną próbą wykrycią urządzenia w konkretnych obszarach. Może to być spowodowane źle zrobionymi urządzeniami, które powodują zawieszanie podczas startu (tak jak niektóre karty Ethernetowe), urządzeniami błędnie rozpoznanymi, urządzeniami, których stan został zmieniony podczas wcześniejszej próby wykrycia, albo po prostu tym, że nie chcesz aby jakieś urządzenie zostało wykryte.
Argument startowy reserve eliminuje te problemy przez
podanie obszaru adresów I/O, który nie ma być sprawdzany. Obszar
ten jest oznaczany w tablicy rejestracyjnej portów jądra tak jakby
jakieś urządzenie zostało już w tym obszarze wykryte (słowem
reserved). Zauważ, że ten proceder nie jest konieczny na
wszystkich maszynach. Tylko jeśli występuje problem lub sytuacja
wyjątkowa, wymagająca użycia tego argumentu.
Porty I/O w podanym obszarze są chronione przed próbą
automatycznego wykrywania, która używa funkcji check_region()
przed wykrywaniem na ślepo w pewnym regionie adresów I/O. Argument
ten wprowadzono, aby używać go kiedy jakiś sterownik wisi na
karcie NE2000 lub identyfikuje jakieś inne urządzenie jako swoje.
Poprawny sterownik nie powinien przeszukiwać zarezerwowanego
obszaru, o ile inny argument startowy nie poinformuje go wyraźnie,
że ma to zrobić. Wynika z tego, że argument reserve jest
najczęściej używany w konfiguracji z innymi argumentami
startowymi. Tak więc jeśli podasz jakiś obszar, aby chronić jakieś
urządzenie, musisz zwykle podać wyraźnie port tego urządzenia.
Większość sterowników ignoruje tablicę rejestracji portów jeśli
mają podany konkretny adres. Na przykład poniższa linia:
reserve=0x300,32 bla=0x300
0x300-0x31F.
Jako zwykły argument startowy argument reserve ma limit na ilość
parametrów (11), tak więc możesz podać tylko 5 obszarów
zarezerwowanych przez każdy argument reserve. Jeśli masz
powód, aby użyć więcej argumentów reserve możesz to zrobić.
Zauważ, że tak naprawdę to nie jest argument startowy. Jest to
opcja, która jest interpretowana przez LILO, a nie przez jądro,
tak jak wszystkie inne argumenty startowe. Jednak jej użycie stało się
tak popularne, że wymaga ona tutaj wzmianki. Można to także
ustawić przy pomocy rdev -v albo równoważnie vidmode w
pliku vmlinuz.
Argument ten pozwala na zmianę trybu wyświetlania poprzez BIOS
jeszcze przed załadowaniem jądra. Typowe tryby to 80x50, 132x44
itd. Najlepszym sposobem jest użycie tego argumentu w postaci
vga=ask. Wyświetli on wtedy listę dostępnych trybów i
będzie czekał na podanie jednego z nich. Później, jak już będziesz
znał numer trybu jaki chcesz używać możesz go wpisać zamiast słowa
"ask". Jeśli chcesz wiedzieć więcej zajrzyj do pliku
linux/Documentation/svga.txt, który przychodzi wraz ze
źródłami jądra.
Zauważ, że nowsze jądra (v2.1 i nowsze) mają kod ustawiania, który zmienia tryb video jako opcję, pokazaną jako Video mode selection support więc musisz włączyć tę opcję jeśli chcesz używać tej właściwości.