Propozycja - falszywy kernel

[Tomasz Kłoczko]

On Tue, 14 Jan 2003, Daniel Mróz wrote:

> 
> Czesc
> 
>    Mam propozycje. Czesto zdarza sie tak, ze uzytkownik PLD sam sobie
> kompiluje jadro, a dystrybucyjne wywala co by miejsca nie zajmowalo.
> Pozniej jednak sa szopki z aktualizacja pakietow, ktore wymagaja
> kernela (trzeba forsowac itp.)
>    Propozycja jest taka, aby stworzyc pakiet o nazwie np. kernel-fake,
> ktory bedzie mial `Provides: kernel' i jakastam wersje. Ludkowie z
> wlasnymi jajami beda mogli sobie go wtedy zainstalowac i zyc dlugo i
> szczesliwie za siedmioma serwerami.
>    Nie bic. To tylko propozycja. Na developingu sie nie wyznaje, wiec
> nie krzyczec i nie plonkowac ;)

Są dwie strony medalu powyższego. Pierwsza:
- unikamy zależności od kernela .. także zależność od helpera svga powinna 
  tu zniknąć, a zdaje sie że w tej chwili jest to jedyna nitka łączaca
  kernel z reszta pakirtów. Wobec czego robienie kernel-fake raczej
  nie jest/nie będzie potrzebne.

Druga:
- kernel powinien ulec podziałowi na grupu modułów dzięki czemu nie
  powinien zajmować on efektywnie aż tak dużo miejsca żeby chcieć (za 
  często) koniecznie z powodu ilości przezeń zajmowanego miejsca dotykać
  spraw z jego rekompilacją.

Takimi częściami na pewno mogłby być net-ethT100, net-ethT1000, net-atm,
net-fddi, net-sched, block-ide, block-scsi, block-i2o, usb, sound (na
dłuższą metę powinniśmy nastawiać się wyłacznei na alsę), fb, i2c, isdn,
pcmcia, char-joistick, char-agp (włącznie z modułami drm), fs-net, fs-misc
(kilka co rzadziej używanych fs-ów).

Podział na podpakiety niekoniecznie musiałby wyglądać tak jak powyżej bo
jest to tak na poczekaniu wygenerowana lista tego co można by potencjalnie
wydzielić. Tak czy inaczej podstawa podziału zasadzać by się miała na tym
że wydzielane są grupy modułów obsługujących jakieś funkcjonalności czy
typy urządzeń które są na danym sprzecie opcjonalne/nie koniecznie
potrzebne wszedzie (czytaj: skompletowanie maszynki która miałaby wszytko
to obsłużyć jednoczenie byłaby nawet chyba niewykonalane .. napewno na
x86 ze względu choćy na ograniczenia związane z małą ilością IRQ :)

Wmiarę wprowadzania kolejnych podpakietów zapewne będa przychdzić pomysły
na wydzielanie kolejnych porcji. W wyniku czego główny pakit z kernelem 
powinien ulec dość mocnemu odchudzeniu :)
Kolejne podpakiety możnaby wprowadzać stopniowo .. w miarę 
wyciągania na wierzch zauważalnych potrzeb ich wydzielnia.

Mówic inaczje należy raczje przyjrzeć sie właśnie temu dlaczego ludzie
tracą (jeszcze) czas na rekompilowanie kerneli i .. próbować
przeciwdziałać temu niecnemu procederowi ;->

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*