Dlaczego warto używać CPIO do initramfs?

11

Tworzę własne initramfs na podstawie wiki Gentoo . Zamiast znajomego tari gzipstrona mówi mi, żebym używał cpioi gzip. Wikipedia twierdzi, że cpiojest używany przez initramfs jądra 2.6, ale nie wyjaśnia dlaczego.

Czy to tylko konwencja, czy jest cpiolepsza dla initramfs? Czy nadal mogę używać tari gzip?

phunehehe
źródło
IIRC nie możesz używać tar jako initramfs (nie wysyłam go jako odpowiedzi, ponieważ nie jestem w 100% pewien). BTW używając Gentoo, znacznie łatwiej jest skonfigurować wbudowane initramfs niż ręcznie.
Maciej Piechotka,
@Maciej Chcę tylko wiedzieć, jak to zrobić :) Ponadto widzę dużą poprawę czasu rozruchu dzięki użyciu własnych initramfs
phunehehe
Nie zrozumiałeś mnie. Metoda, o której mówiłem, polega na podaniu jądrze podczas konfiguracji pliku specyfikacji, które pliki powinny zostać uwzględnione w initrd (w tym niestandardowe /inititp.), A jądro po prostu z niego korzysta. Nie chodzi mi o generowanie initramfs przez genkernel lub podobne metody.
Maciej Piechotka
@Maciej To wygląda zabawnie! Spróbuję to kiedyś.
phunehehe,
Dobrze. IMHO jest łatwiejszy do skonfigurowania i automatycznie aktualizuje się z jądrem (więc nie muszę pamiętać, aby kopiować nowe pliki do initrd).
Maciej Piechotka,

Odpowiedzi:

9

Nie jestem w 100% pewien, ale ponieważ początkowy ramdysk musi zostać rozpakowany przez jądro podczas rozruchu, cpio jest używane, ponieważ jest już zaimplementowane w kodzie jądra.

firusvg
źródło
6
Bądź w 100% pewien. linux / init / initramfs.c rozpakowuje cpio -H newcarchiwum.
ephemient
@ephemient To jest naprawdę coś. Jeśli w ciągu kilku dni nie będzie już odpowiedzi, zaakceptuję cpioto jako konwencję i musimy z niej skorzystać cpio.
phunehehe
Wszelkie pomysły, dlaczego newc jest wybrany format?
CMCDragonkai
1
Zgodnie z dokumentacją jądra, cpio zostało zaimplementowane tylko ze względu na initramdisk, aby mogły zaimplementować dowolny inny format.
lvella
10

Cytowanie Documentation/filesystems/ramfs-rootfs-initramfs.txt:

Dlaczego CPIO zamiast smoły?

Decyzja została podjęta w grudniu 2001 roku. Dyskusja rozpoczęła się tutaj:

http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1538.html

I pojawił się drugi wątek (szczególnie na tar vs cpio), zaczynając tutaj:

http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1587.html

Szybka i brudna wersja podsumowania (która nie zastępuje czytania powyższych wątków) to:

1) CPIO jest standardem. Ma dziesiątki lat (od czasów AT&T) i jest już szeroko stosowany w systemie Linux (w RPM, dyskach ze sterownikami urządzeń Red Hata). Oto artykuł na ten temat w Linux Journal z 1996 roku:

http://www.linuxjournal.com/article/1213

Nie jest tak popularny jak tar, ponieważ tradycyjne narzędzia wiersza polecenia cpio wymagają argumentów wiersza polecenia naprawdę. Ale to nic nie mówi o formacie archiwum, a istnieją alternatywne narzędzia, takie jak:

http://freecode.com/projects/afio

2) Format archiwum CPIO wybrany przez jądro jest prostszy i czystszy (a zatem łatwiejszy do utworzenia i analizy) niż jakikolwiek z (dosłownie dziesiątek) różnych formatów archiwów tar. Pełny format archiwum initramfs wyjaśniono w pliku-buforze-format.txt, utworzonym w usr / gen_init_cpio.c i wyodrębnionym w init / initramfs.c. Wszystkie trzy razem zawierają mniej niż 26 tys. Tekstu czytelnego dla człowieka.

3) Projekt GNU standaryzujący na tar jest mniej więcej tak samo ważny jak system Windows na zipie. Linux nie jest częścią żadnego z nich i może podejmować własne decyzje techniczne.

4) Ponieważ jest to wewnętrzny format jądra, może to być
coś zupełnie nowego. Jądro zapewnia własne narzędzia do tworzenia i wyodrębniania tego formatu. Zastosowanie istniejącego standardu było lepsze, ale nie konieczne.

5) Al Viro podjął decyzję (cytat: „smoła jest brzydka jak diabli i nie będzie wspierana po stronie jądra”):

http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1540.html

wyjaśnił swoje rozumowanie:

http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1550.html http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1638.html

i, co najważniejsze, zaprojektował i wdrożył kod initramfs.

lvella
źródło
3

Z tego, co pamiętam z moich dawnych czasów SysV, cpio mógł obsługiwać pliki dev, ale tar nie mógł; dzięki temu CPIO było preferowanym narzędziem do tworzenia kopii zapasowych, zanim pojawił się zrzut. Łatwiej było także obsługiwać częściowe zestawy plików i twarde łącza, dzięki czemu tworzenie przyrostowych kopii zapasowych było łatwiejsze. Myślę, że GNU tar nadrobił zaległości w funkcjach CPIO, więc teraz jest to tylko kwestia wygody użytkownika. Zarówno cpio, jak i tar powinny być domyślnie zainstalowane.

Arcege
źródło
1
cpiomoże być w stanie obsłużyć tararchiwa -format i odwrotnie w niektórych przypadkach, ale to nie ma znaczenia. Jądro może rozpakowywać tylko archiwa w newcformacie cpio-format, których nie tarznam.
ephemient
Format nieprawidłowo wywoływany przez GNU cpio newcjest oficjalnie nazwany asci oczywiście obsługiwany przez star.
schily
1
@schily: To całkiem ładnie pokazuje jedną z ukrytych przyczyn. „Cóż, to jest jakieś archiwum tar. Ale który z możliwych formatów tar i czy jest kompatybilny z tym ekstraktorem tar?” OTOH, historia wersji cpio jest znacznie mniej skomplikowana.
Piskvor opuścił budynek