Witam,

Takie pytanie: czy w Linux-e zawsze jest potrzebny podmontowany
'root filesysytem'

Mam system na ktorym wlasciwie dziala tylko jeden proces (nieliczac tych
systemowych), ktory w dodatku w ogole nie korzysta z dysku (poza tym, ze sie
stamtad wgrywa :).

Skomilowany jest jako program z biblotekami dynamicznymi, ale nic nie stoi
na przeskodzie zeby byl statycznie zlinkowany. Jesli jeszcze udaloby sie go
jakos zaladowac bez korzystania z tradycyjnych plikow (np. tak jak ram-dsyki
przes jadro, tylko przez podanie nr bloku na wskazanym urzadzaniu blokowym)
to wlasciwie nic wiecej nie potrzebuje.

W sumie mi to nie przeszkadza, ale zastanawiam sie czy Linux musi z definicji mies jakis
system plikow?

W artykule Zenek napisal(a):

> Takie pytanie: czy w Linux-e zawsze jest potrzebny podmontowany
> 'root filesysytem'
>
> Mam system na ktorym wlasciwie dziala tylko jeden proces (nieliczac tych
> systemowych), ktory w dodatku w ogole nie korzysta z dysku (poza tym, ze sie
> stamtad wgrywa :).
>
> Skomilowany jest jako program z biblotekami dynamicznymi, ale nic nie stoi
> na przeskodzie zeby byl statycznie zlinkowany. Jesli jeszcze udaloby sie go
> jakos zaladowac bez korzystania z tradycyjnych plikow (np. tak jak ram-dsyki
> przes jadro, tylko przez podanie nr bloku na wskazanym urzadzaniu blokowym)
> to wlasciwie nic wiecej nie potrzebuje.
>
> W sumie mi to nie przeszkadza, ale zastanawiam sie czy Linux musi z definicji mies jakis
> system plikow?

Gdyby musial to dystrybucje typu Knoppix czy jakies bootujace sie z PXE by
wlasnie zniknely.

Zakladam, ze mówisz o systemie plików na dysku twardym i dopuszczasz fs
w RAMie.

pozdr,
fEnIo

Am 10.03.2010 18:36, Zenek wrote:
> Witam,
>
> Takie pytanie: czy w Linux-e zawsze jest potrzebny podmontowany
> 'root filesysytem'
>
> Mam system na ktorym wlasciwie dziala tylko jeden proces (nieliczac tych
> systemowych), ktory w dodatku w ogole nie korzysta z dysku (poza tym, ze sie
> stamtad wgrywa :).
>
> Skomilowany jest jako program z biblotekami dynamicznymi, ale nic nie stoi
> na przeskodzie zeby byl statycznie zlinkowany. Jesli jeszcze udaloby sie go
> jakos zaladowac bez korzystania z tradycyjnych plikow (np. tak jak ram-dsyki
> przes jadro, tylko przez podanie nr bloku na wskazanym urzadzaniu blokowym)
> to wlasciwie nic wiecej nie potrzebuje.
>
> W sumie mi to nie przeszkadza, ale zastanawiam sie czy Linux musi z definicji mies jakis
> system plikow?

Z definicji musi - chyba, ze chcesz uruchomic samo jadro bez userspace.
W przeciwnym wypadku, trzeba skads uruchomic np. /sbin/init - i juz masz
/ (root filesystem).

A jak chcesz zrobic "minimalnie" - mozesz stworzyc jadro z wbudowanym
initrd, w ktorym bedziesz mial jeden jedyny statycznie zbudowany program
(/program_statyczny) - wszystko w jednym pliku (i rowniez posiada "root
filesystem").

epsilon$ while read LINE; do echo \>"$LINE"; done < "Tomasz Chmielewski"
>Z definicji musi - chyba, ze chcesz uruchomic samo jadro bez userspace.
>W przeciwnym wypadku, trzeba skads uruchomic np. /sbin/init - i juz masz
>/ (root filesystem).

Nie do końca. Musisz uruchomić init w sensie procesu. Nie jest
powiedziane, że musi on być czytany z systemu plików.

>A jak chcesz zrobic "minimalnie" - mozesz stworzyc jadro z wbudowanym
>initrd, w ktorym bedziesz mial jeden jedyny statycznie zbudowany program
>(/program_statyczny) - wszystko w jednym pliku (i rowniez posiada "root
>filesystem").

Zbliżamy się do zawiłych dyskusji filozoficznych ;-)

Am 10.03.2010 20:44, Mariusz Kruk wrote:
> epsilon$ while read LINE; do echo \>"$LINE"; done< "Tomasz Chmielewski"
>> Z definicji musi - chyba, ze chcesz uruchomic samo jadro bez userspace.
>> W przeciwnym wypadku, trzeba skads uruchomic np. /sbin/init - i juz masz
>> / (root filesystem).
>
> Nie do końca. Musisz uruchomić init w sensie procesu. Nie jest
> powiedziane, że musi on być czytany z systemu plików.

Tak czy inaczej, bedzie to "punkt montowania".

Ale to juz zawile filozoficzne dyskusje ;)

Zenek wrote:

> W sumie mi to nie przeszkadza, ale zastanawiam sie czy Linux musi z
> definicji mies jakis system plikow?
>

w lilo dalo sie przyspieszyc w ten sposób, chociaz i tak montowal system
plików:

linux init=/sciezka_do_programu/program

Pozdrawiam

epsilon$ while read LINE; do echo \>"$LINE"; done < "Tomasz Chmielewski"
>>> Z definicji musi - chyba, ze chcesz uruchomic samo jadro bez userspace.
>>> W przeciwnym wypadku, trzeba skads uruchomic np. /sbin/init - i juz masz
>>> / (root filesystem).
>> Nie do końca. Musisz uruchomić init w sensie procesu. Nie jest
>> powiedziane, że musi on być czytany z systemu plików.
>Tak czy inaczej, bedzie to "punkt montowania".

No właśnie niekoniecznie. Można po prostu mieć stały obraz programu
"init" umieszczony bezpośrednio w kodzie jądra/bootloadera/whatevera (nie
jestem pewien jak to dokładnie wygląda w tej chwili).

>Ale to juz zawile filozoficzne dyskusje ;)

Owszem :-)

Dnia 11.03.2010 Mariusz Kruk <Mariusz.Kruk> napisał/a:
> epsilon$ while read LINE; do echo \>"$LINE"; done < "Tomasz Chmielewski"
>>Tak czy inaczej, bedzie to "punkt montowania".
>
> No właśnie niekoniecznie. Można po prostu mieć stały obraz programu
> "init" umieszczony bezpośrednio w kodzie jądra/bootloadera/whatevera (nie
> jestem pewien jak to dokładnie wygląda w tej chwili).
>
>>Ale to juz zawile filozoficzne dyskusje ;)

Właśnie o to pytam: system plików (niezależnie czy dyskowy, RAM-owy,
sieciowe) to coś co zawsze musi być w jądrze?

Statyczny init - to byłoby to. Tylko zdaje się, że w jądrze jest to
wywoywane przez zwykłe 'exec', które wymaga ścieżki do pliku....

Am 11.03.2010 10:35, Mariusz Kruk wrote:
> epsilon$ while read LINE; do echo \>"$LINE"; done< "Tomasz Chmielewski"
>>>> Z definicji musi - chyba, ze chcesz uruchomic samo jadro bez userspace.
>>>> W przeciwnym wypadku, trzeba skads uruchomic np. /sbin/init - i juz masz
>>>> / (root filesystem).
>>> Nie do końca. Musisz uruchomić init w sensie procesu. Nie jest
>>> powiedziane, że musi on być czytany z systemu plików.
>> Tak czy inaczej, bedzie to "punkt montowania".
>
> No właśnie niekoniecznie. Można po prostu mieć stały obraz programu
> "init" umieszczony bezpośrednio w kodzie jądra/bootloadera/whatevera (nie
> jestem pewien jak to dokładnie wygląda w tej chwili).

Wszystko jedno.
Statyczny init umieszczony w jadrze bedzie i tak uruchomiony z punktu
montowania "/" (jakkolwiek wirtualnie czy filozoficznie to brzmi).

Mozna sie zreszta przekonac samemu: zrobic intramfs zawierajacy jakis
shell (dla ulatwienia zwykly bash z zaleznymi (ldd) bibliotekami, dla
utrudnienia jedna statyczna binarka jakiegos minimalnego shella).
I uruchomic ten "shell" jako init.

Jezeli shell potrafi obsluzyc komendy typu "mount" czy "cat":

mount -t procfs proc /proc
cat /proc/mounts


root filesystem jest wiec zawsze, gdy dziala userspace.

Am 11.03.2010 11:01, Zenek wrote:
> Dnia 11.03.2010 Mariusz Kruk<Mariusz.Kruk> napisał/a:
>> epsilon$ while read LINE; do echo \>"$LINE"; done< "Tomasz Chmielewski"
>>> Tak czy inaczej, bedzie to "punkt montowania".
>>
>> No właśnie niekoniecznie. Można po prostu mieć stały obraz programu
>> "init" umieszczony bezpośrednio w kodzie jądra/bootloadera/whatevera (nie
>> jestem pewien jak to dokładnie wygląda w tej chwili).
>>
>>> Ale to juz zawile filozoficzne dyskusje ;)
>
> Właśnie o to pytam: system plików (niezależnie czy dyskowy, RAM-owy,
> sieciowe) to coś co zawsze musi być w jądrze?

W sumie nie.
Ale wtedy jadro zaliczy "kernel panic - no init found".
Chyba ze napiszesz jakis modul, ktory bedzie robil jakies ciekawe rzeczy
bez potrzeby userspace (i dodatkowo zblokuje chec jadra do wgrania
/sbin/init). Z reguly gra niewarta swieczki.


> Statyczny init - to byłoby to. Tylko zdaje się, że w jądrze jest to
> wywoywane przez zwykłe 'exec', które wymaga ścieżki do pliku....

"Systemem plikow", ktory szukasz, jest pewnie initramfs.

epsilon$ while read LINE; do echo \>"$LINE"; done < "Tomasz Chmielewski"
>>>>> Z definicji musi - chyba, ze chcesz uruchomic samo jadro bez userspace.
>>>>> W przeciwnym wypadku, trzeba skads uruchomic np. /sbin/init - i juz masz
>>>>> / (root filesystem).
>>>> Nie do końca. Musisz uruchomić init w sensie procesu. Nie jest
>>>> powiedziane, że musi on być czytany z systemu plików.
>>> Tak czy inaczej, bedzie to "punkt montowania".
>> No właśnie niekoniecznie. Można po prostu mieć stały obraz programu
>> "init" umieszczony bezpośrednio w kodzie jądra/bootloadera/whatevera (nie
>> jestem pewien jak to dokładnie wygląda w tej chwili).
>Wszystko jedno.
>Statyczny init umieszczony w jadrze bedzie i tak uruchomiony z punktu
>montowania "/" (jakkolwiek wirtualnie czy filozoficznie to brzmi).

No właśnie niekoniecznie. Czym innym jest zamontowanie rootfs
i załadowanie z niego obrazu, a czym innym "ręczne" wczytanie obrazu do
pamięci i wystartowanie go, nieprawdaż? Tyle, że - mam wrażenie - kernel
zawsze montuje coś jako rootfs (przy initramfs robi potem pivot_root()).
Trzeba by było za bardzo mieszać żeby tego nie robił i raczej nie byłoby
to warte świeczki.

>Mozna sie zreszta przekonac samemu: zrobic intramfs zawierajacy jakis
>shell (dla ulatwienia zwykly bash z zaleznymi (ldd) bibliotekami, dla
>utrudnienia jedna statyczna binarka jakiegos minimalnego shella).
>I uruchomic ten "shell" jako init.
>
>Jezeli shell potrafi obsluzyc komendy typu "mount" czy "cat":
>
>mount -t procfs proc /proc
>cat /proc/mounts
>>root filesystem jest wiec zawsze, gdy dziala userspace.

Nie. Tu już masz rootfs w postaci initramfs.

Am 11.03.2010 13:24, Mariusz Kruk wrote:

(...)

>> root filesystem jest wiec zawsze, gdy dziala userspace.
>
> Nie. Tu już masz rootfs w postaci initramfs.

Jakos trzeba zaladowac userspace.

Zawsze jakis system plikow musi byc, a wiec i "root filesystem".

epsilon$ while read LINE; do echo \>"$LINE"; done < "Tomasz Chmielewski"
>>> root filesystem jest wiec zawsze, gdy dziala userspace.
>> Nie. Tu już masz rootfs w postaci initramfs.
>Jakos trzeba zaladowac userspace.

Owszem. Od biedy można sobie wyobrazić monolityczny kernel tworzenie
inita przez sam kernel/bootloader, czy cokolwiek tam jest. Wtedy nie
potrzebowalibyśmy initramfs do ładowania modułów, ani do wczytania
inita.

>Zawsze jakis system plikow musi byc, a wiec i "root filesystem".

Inaczej. Zawsze (no właśnie, usiłujemy ustalić czy faktycznie) musi być
root filesystem, a więc musi być jakiś system plików.

Mariusz Kruk <Mariusz.Kruk> writes:

> No wlasnie niekoniecznie. Czym innym jest zamontowanie rootfs
> i zaladowanie z niego obrazu, a czym innym "reczne" wczytanie obrazu do
> pamieci i wystartowanie go, nieprawdaz? Tyle, ze - mam wrazenie - kernel
> zawsze montuje cos jako rootfs (przy initramfs robi potem
> pivot_root()).

Nie musi robic pivot_root(), w wersji minimalnej moze po prostu zapisac
initramfs (to nie jest zaden prawdziwy system plikow, initramfs to jest
praktycznie disk cache z zablokowanymi stronami, by nie "wypadly").
Po zapisaniu initramfs (np. uzywajac wewnetrznego obrazu) kernel moze po
prostu uruchomic /init.

W praktyce sam uzywam takiego rozwiazania. Kernel wynikowy wyglada np.
tak:
11204192 2010-03-11 15:56 armeb-xxx (aka zImage ARM, moze to byc takze
bzImage x86 itp). W jego wewnetrznym initramfs siedzi wszystko co
potrzeba - binaria, biblioteki, moduly kernela itd. Nie jest potrzebny
zaden dodatkowy zewnetrzny plik ani nic podobnego.

$ cat /proc/mounts
rootfs / rootfs rw 0 0 <<<<< to jest wlasnie initramfs
proc /proc proc rw,relatime 0 0
sys /sys sysfs rw,relatime 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
usb /proc/bus/usb usbfs rw,relatime 0 0

$ head /init
#! /bin/busybox sh

#************************************************* *************
# Started before /sbin/init
#************************************************* *************
umask 022

busybox mount -t proc proc /proc
busybox mount -t sysfs sys /sys
busybox mount -t devpts devpts /dev/pts

> Trzeba by bylo za bardzo mieszac zeby tego nie robil i raczej nie byloby
> to warte swieczki.

Wywalenie userspace w ogole powinno byc dosc trywialne, powinno dac sie
zredukowac mocno kernel. Ale napisanie modulu, ktory zrobi dla nas
wszystko, to pewnie troche pracy - zalezy od zastosowania, ale moze sie
to nie oplacac.

epsilon$ while read LINE; do echo \>"$LINE"; done < "Krzysztof Halasa"
>> No właśnie niekoniecznie. Czym innym jest zamontowanie rootfs
>> i załadowanie z niego obrazu, a czym innym "ręczne" wczytanie obrazu do
>> pamięci i wystartowanie go, nieprawdaż? Tyle, że - mam wrażenie - kernel
>> zawsze montuje coś jako rootfs (przy initramfs robi potem
>> pivot_root()).
>Nie musi robic pivot_root(), w wersji minimalnej moze po prostu zapisac
>initramfs (to nie jest zaden prawdziwy system plikow, initramfs to jest
>praktycznie disk cache z zablokowanymi stronami, by nie "wypadly").
>Po zapisaniu initramfs (np. uzywajac wewnetrznego obrazu) kernel moze po
>prostu uruchomic /init.

Zgadza się. Użyłem skrótu myślowego pisząc o sytuacji "typowej
dystrybucji", która działa z dysku.

>> Trzeba by było za bardzo mieszać żeby tego nie robił i raczej nie byłoby
>> to warte świeczki.
>Wywalenie userspace w ogole powinno byc dosc trywialne, powinno dac sie
>zredukowac mocno kernel.

W sumie fakt, można zignorować w ogóle userspace, nie bawić się z
initem, tylko dać to, co chcemy robić jako wątek kernela.

>Ale napisanie modulu, ktory zrobi dla nas
>wszystko, to pewnie troche pracy - zalezy od zastosowania, ale moze sie
>to nie oplacac.

Ano właśnie.