Vyvoj jadra vs. drivery [Was:Re: BugZilla jako zachrana vyvoje?]

Ing. Pavel PaJaSoft Janousek janousek na fonet.cz
Středa Listopad 7 11:48:11 CET 2001


Milan Kerslager wrote:
> situace (krome toho, ze maintaineri jednotlivych casti jadra by prskali
> jeste vic, nez dnes [jako ze musi udrzovat 1 ovladac pro 3 ruzna jadra]).

	Chapu, ze se vyskytnou pripady, kdy nelze spolupracovat jinak. Co mi
vsak silne unika je, proc je to obecny trend vyvoje ovladacu? Pokud
musim udrzovat 1 ovladac pro 3 ruzna jadra, pak:
a) se zmenilo API, interface, funkcnost apod.
b) muj ovladac vyuziva neco z jadra

	Pripad a) silne nastal napr. u sitovych karet (nejenom u nich), kdy se
mezi 2.0 a 2.2 silne zmenil cely PCI subsystem. Prakticky to vsak
znamenalo (v 99% pripadu), ze funkcnost a moznosti diveru zustaly
zachovany, pouze bylo nutno upravit 'roubovaci' funkce na system (zhruba
v rozsahu, v jake v soucasne dobe poskytuje NVidia 'source' svych gr.
driveru, take nema desitky verzi, ale jeden obecny roubovaci a vykonne
jadro, ktere muze byt porad stejne). Chce mi snad nekdo rici, ze Donald
Becker 'pres noc' napsal znovu vsechny drivery sitovych karet, pod ktere
je podepsany ve verzi 2.2.0?

	Pripad b) je o neco slozitejsi, ale stale resitelny - zhruba tak, jak
je napr. WWW server apache kompilovan - dle platformy na ktere bezi si
nektere potrebne komponenty (napr. regexp) tahne s sebou a bud vyuzije
ty ze systemu (pravdepodobne optimalizovane na danou architekturu a tedy
ty nejoptimalnejsi) nebo si skompiluje svoje vlastni - obecne reseni,
ktere pouzije. Stejne je to IMHO i u jadra, bud jadro dotycnou funkcnost
podporuje (vyuzijeme ji) nebo nepodporuje a napiseme si vlastni - coz
ostatne u novych features je temer pravidlo, ze jadro to mit nebude a
musime se spolehnout na sebe. 

	Porad mi z toho vychazi, ze mam jeden ovladac (SW komponentu), ktery ma
urcitou deklarovanou funkcnost (ke ktere se v limite t (t -> nekonecno)
blizime) a pak tento driver prihlasuji do jadra - registruji systemova
volani, soubory v /dev, parametry v /proc apod. I kdyz zkombinuji pripad
a) a b), tak mi z toho vychazi, ze mam realne bud dva extremy (1 ovladac
nebo variace n - viz dale, nikoli 1 ovladac a 2/3 jadra - s poctem
jadernych rad tu relaci nevidim) - nic se nezmenilo, fine naroubuju na
novy API (pripad a), zmenilo se vsechno, fine naroubuju na nove veci
(pripad a), nezmenilo se vubec nic, ale pouzivam komponenty, ktere maji
jen urcite verze kernelu (pripad b), jenze tento pripad ma bud 1 nebo
obecne variace n, kde n je pocet komponent na kterych zavisi moje
komponenta.

	Mozna ze nase obecne rozbroje prameni i z nepochopeni pohledu na vyvoj
softwarovych komponent. Pokud jsem mimo misu, mohl by mi nekdo muj
pohled (a znalosti) opravit, aby k 'valkam' opet nedoslo? V tuto chvili
tu relaci (a po zkusenostech s jadry 1.1. - 2.4) driver vs. pocet rad
jadra opravdu nejsem schopen nalezt - presto mam dojem, ze se tu s timto
operuje jako s faktem/pojmem, ktery je obecne (se povazuje) platny.

> Datumy jsou brany z ftp://ftp.linux.cz/pub/linux/kernel/

	Osobne se mi zdaji nektere trosku divne, ale chyba muze byt na me
strane - konkretne napr. 2.4.0 mam za to, ze vyslo na konci 2000 a ne
5.1.2001, ale jsou to detaily, na kterych nechci bazirovat, nerad bych
vsak, aby se toho nekdo dogmaticky chytl...

> S radou 2.4.0 to bude asi malicko jinak, ale nemuzu najit misto, kde jsem
> o tom cetl...

	Myslim, ze v l-k;-), zahlid jsem take neco podobneho, hlavni snad bude,
ze obvykla 'Linusova' prace uz nebude jen Linusova, ale to si povime az
skutecne 2.5.0 spatri svetlo sveta a budou dalsi release.

-----------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)                 FoNet, spol. s r. o.
Vyvoj software, Intranet / Internet          Sokolova 67, 619 00 Brno
E-mail: mailto:Janousek na FoNet.Cz             Tel.: +420  5  4324 4749
SMS:    mailto:P.Janousek na SMS.Paegas.Cz      Fax.: +420  5  4324 4751
WWW:    http://WWW.FoNet.Cz/               E-mail: mailto:Info na FoNet.Cz
-----------------------------------------------------------------------


Další informace o konferenci Linux