kompilacja jadra

[Tomasz Kłoczko]

On Thu, 18 Jul 2002, Wojciech "Sas" Cieciwa wrote:

> On Thu, 18 Jul 2002, Tomasz Kłoczko wrote:
> [...]
> > To co jest w kernelu 2.4 to tona bcondów które do niczego nie służą. Robi 
> > się przez to bałagan i tak duży poziom zagmatwanai że nei dziwie sie że 
> > mało komu chcę sie w tio zaglądać :)
> 
> Tomek, BŁĄD.
> Te bcondy są po to, zeby można było _testować_ np. nowy scheduler, czy 
> reemptible ...

Wybacz ale przyjrzyj się jednak temu co robi dzimi i pzredewszystkim jak 
to robi. Otóż on testuje w osobnym branchu takie rzeczy :>

To co ma być i jest stabilne powinno na czysto wchodzić w główny
strummień zmian :>
Nie chcę się domyślać po cą te bcondy i nie chciałbym żeby komukolwiek 
wplątywały sie takie zreczy miedzy gałki oczne. Widząc spec od kernele
chciałbym widzieć jedna przejrzutą formę *produkcyjną* a nie dziesieć 
kwiatków eksperymentalnych nałożonych jeden na drugi. Poprostu .. :>

> > Podział plików .config i dziwne na nich "operacje" jest kolejnym chorym
> > podejściem :>
> 
> A tu się nie zgadzam...
> ile jest configow w 2.2 ??
> 2x i386, 2xppc, 2xsparc, 2xsparc64, 2xalpha i pewnie jeszcze kilka innych ..
> i teraz zmienia sie np. netfilter.

To się zmienia po jednej linijce w każdym. Skad wiesz że na wszystkich
architktórach dany ficzer chodzi poprawnie ? i że mozęsz go 
włączać/wyłącząć we wspólnym pliku ? A jak bendą wyjątki to co ?

> W 2.4 zmiana jest w JEDNYM !! pliku a nie w 10-ciu.
> Prostsze ?

Wybacz z lekka jednak bzdury roplatasz (jednak).
Takież same pliki kernel-<arch>*.config są i w 2.4. Co z tego że mniejsze ?
Na czym tu oszczędzasz ?
Na przejrzystości ? Oprócz tych samycj plików per arch i smp/up masz 
jeszcze dodatkowe pliki których nie ma w klasycznym rozwiązaniu.

Jeszcze raz: możesz w cvs robić tyle branchy ile potrzebujesz i tak 
wątpie żeby w momencie dopracowywania kernela warto było pracować nad 
więcej niż jenym dodatkiem wymagającym testowania bo niepotrzebnie 
pojawiać się bendą tylko oddatkowe błędy "interferencyjne", z których
lokalizacją źródła będziesz miał zawsze więcej zachodu. No i po co ?

Jak wprowadzać będzies to pojedynczymi małymi ktrokami to żadne bcondy nie 
bendą potrzebne.

> Wydaje mi sie, ze tak.

Dobrze to ująłeś i tu się z Tobą zgodzę :)

Siedzisz w zasadzie tylko nad kernelem i idzi Ci to mówiac mało skąłdnie i 
wątpie że dzieje się tak dlatego że jesteś tłumok i do większych rzeczy 
nie jestewś zdolny. Porostu mw tym co robisz musi byc bąłd *w metodzie* i 
niczym więcej. Gdyby to co robisz miało przynajmiej jedna wersje 
maksymalnei prostą to zapewne łatweij innym zagladałoby sie też do tego. 
Popatrz na każdą linikję speca włąsnie nie ze swojego punktu widznia tylko 
np gadzinki który zajrzy dotego tylko wtedy kiedy bedzie musiał. Oczekiwać 
bezie primo: podobnej struktóry speca jakasna z inncyh przykładów, 
sesundo: maksymalnej prostoty i przejrzystości. Teraz zastanów sie nad tym 
czy ten jesen spec w tym co robisz spełnia oba kryteria. Jęzlei choć jeen 
element potencjalnei np. zaciemnia to co jest wykonywane np. w build to 
taki element powinien być wywalony.

Osobiście mam jeden prosty pomysł na to jak maksymalnie uproąścić pracę 
nad poprawkami do kernela. Otóż wszystkie spece tzreba wynieść z kernele. 
Tzreba zacżąć pracwać nad osobym patcjema ala ac czy aa czy dj jakie widzi 
się na kernel-list. O ile to co bezie tam wkąłdane bedzie znoscne dla 
ludzi z kernel-list to i dla nas także będzie. Tylko niekao efektem 
ubocznym powinno być to że taki patch w bez juz możliwie żadnych innych 
diodatków trafia do naszego kernela.

Żeby to zrobić i wcielić wcale nie tzreba dużego wysiłku. Tzreba raczje 
tylko możliwie dużej regularnosci (np. jeden bity dzień tygodniowo) po to 
zeby innych ludzi którzy bendą to testować nie koniecznie w PLD nie
stracili zapału do sięgania co kawąłek po to.
O ile będzie to stabilne to zyskaja na tym i ludzi z zewnatrz i my takze 
zyskamy jako producencui dobrych zasobów. Zeska na tym takzę PLD jako coś 
co nad czymś takim niejako roztacza parasol.

klocze
-- 
-----------------------------------------------------------
*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*