rh 7.0, gcc a problemy

Čtvrtek Leden 4 11:53:39 CET 2001

Milan Kerslager wrote:

	Poznamka na uvod, Milane kdyz reagujete, prosim nereagujte vzdy tak, ze
mluvite s clovekem, ktery je looser nebo zacatecnik, diskuse se pak
zbytecne prodluzuje...

> >       Pruzkum? Pokud je to v danem programovacim jazyce povolena konstrukce
> > (s implementacne nezavislym vysledkem (nejlepe definovanym)), je to opet
> > problem kompilatoru. Pokud je to implementacne zavisly vysledek, nema v
> 
> Pruzkum proto, aby se vedelo, kde je problem. Neznam nikoho, kdo od boku
> streli bez premysleni a hledani v dokumentaci, co je vlastne spravne.

	??? GCC je zname tim, ze bohuzel mnohokrat naprosto korektni konstrukce
prelozi v nesmysly (pruzkum staci nad vygenerovanym kodem), problem je
bud v generovani intermedialniho kodu (coz nebyva caste) nebo ciloveho
kodu z interm. coz je casty problem zejmena pri optimalizacich... -
osobne radeji ozelim trochu taktu (cca jednotky) nez nefunkcni kod...

> >       Zajimalo by mne, proc se jadro tak svazalo zrovna s GCC, neni prece
> > tajemstvim, ze firemni kompilatory Intelu (nejen pro I-64, ale napr.
> > Pentium a vyssi) jsou o dost optimalnejsi nez jakekoli i komercni
> > prekladace... jenze tyto Intelovske kompilatory nejsou bezne rozsirene a
> > bezne je vyvojari nepouzivaji (dodnes nevim proc..:-() a radsi pouziji
> > zprasene volby a patche napr. do VC++ aby meli 'udajne' optimalizovany
> > kod pro UniCPU Celeron apod.
> 
> No nevim. A jsou zadarmo? Josu dostupne? A bezi ten kompilator kdekoliv? A
> cti vubec poradne normu?

	U VC++ muzu jmenovat to same... kompilatory C necti v soucasne dobe
ANSI C vubec, resp. umoznuji defaultne i konstrukce, ktere se mely
objevit v norme nasledujici, ktera vsak stale neni a kazdy si doplnuje
co chce (od poznamkovani //, pres ruzne vylepseni atd.).

	Moje poznamka vznikla z toho, ze opravdu nechapu, proc by se
kompilatory mely prizpusobovat programum (coz v tomto pripade je kernel)
a naopak proc by se programy (opet kernel) mely prizpusobovat
kompilatorum. To je vec, ktera je mi cizi a kterou naprosto nechapu,
neni to nahodou tak, ze jak kompilator, tak program by se mel (ne mel
__MUSI__) prizpusobit definici daneho jazyka... Co kernel potrebuje
takoveho, co neni v definic ANSI C 1989 nebo ISO C 1990? 

> 
> >       Je hezke, ze Intel spolupracuje s vyvojari Linuxu na jadre pro I-64,
> > ale proc? Protoze se ho snazi prosadit na trhu (resp. zacina
> > marketingova rez), kdyby jadro bylo skutecne psano tak, jak by melo
> > vypadat (a jak IMHO jeste rada 1.2. vypadala), takova podpora ze strany
> > Intelu by nebyla nutna a kernel by po upravach a doplneni sekce
> 
> No, jenze bysme meli jadro, ktere toho zrovna moc neumi....

	Ne, neni problem v jadre, problem je v navrhu, Linus se snazi aby navrh
nebyl predesignovany, fine myslenka, ale prepisovat vsechny drivery v
jedne oblasti quli nejakemu rozsireni je blbost... - nerikam ze je
optimalni to, co MS pouziva v MS Windows, ale treba takove vlastnosti
jako dalsi moznosti BITMAP apod. jsou reseny tak, ze vubec nezalezi na
tom, jakou verzi BITMAPHEADER pouzijes, proste se vyrovna se vsema
verzema... - neznam (a nezajima mne) presny zpusob volani sluzeb, ja
koncim na ioctl ci sysctl, nicmene neni teda vhodne navrhnout komunikaci
tak, aby se pri pazde zmene interface nemusely predelat vsechny ovladace
pracujici s ni?

> >       Takze z toho celeho vychazi, ze problem je zejmena v GCC (pry nejlepsi
> > soucasny kompilator - to je ftip, ze?) a v kernelu, ktery se k nemu
> > uplnul a ted se mu to velmi vymstiva...
> 
> Uprava pro jine kompilatory je mozna, ale to je taky nekdo musi pouzivat a
> pak se to musi testovat. Pokud bude kompilator delat chyby, tak to je na
> odstreleni....

	Ne je to ciste chyba kompilatoru a nema se pouzivat... copak to vzdy
existovalo GCC ze se vseci po... a kdyz to nefunguje v GCC tak je chyba
v aplikaci?

> No nevim. Vsechno jde napsat lepe nebo s ohledem na novinky. Co IPv6? Taky
> se to pak musi prepsat... ovladace nemusi vyhovovat novym potrebam (SMP,
> interrupt versus pooling rizeni, ....)

	No nevim, zda-li jste pouzil dobre priklady, copak IPv6, SMP apod. jsou
vykriky poslednich 2 let? Proc se teda jedna cast (IMHO zivotne
dulezita) prepisuje uz po 4 (pokud dobre pocitam), neni to spise chyba
navrhu - mluvim o routovani, filtrovani apod.?

> >       Byl jsem a jsem velky fanda Linuxu, ale to co zacina zejmena Red Hat,
> > Kernel a Linus predvadet v poslednich 2 letech je skoro k nevire. IBM se
> > vycital prosustrovany rok v OS/2 oproti Windows95. Jaky mel Linux naskok
> > oproti WinNT (odmyslime-li GUI, myslim po serverove strance) jeste v
> > roce 1997 a jaky ma nyni? Neprosustrovava nyni Linux jako OS daleko
> > vice?
> 
> Eee? Aplikace a jadro jsou naprosto nezavisle svety. O co konkretne tedy
> jde?

	Milane, vazne ze mne nedelejte blbce, to vim take, jde konkretne o to,
co je schopen poskytnout Linux jako OS za sitove sluzby apod. konkretne
Maskarada, VPN, filtrace paketu apod. mel Linux drive nez MS Windows a
do dnes je nekde lepsi, bohuzel pro nasazeni podnikoveho serveru, kde je
rozhodujici stabilita systemu (servisni firma caluje za nedostupnost
apod.) je Linux v porovnani s MS Windows srovnatelny braska, pravda,
kazdy je jinak rozezrany a skalovatelny... - clustering si na Linuxu
uplacame sami, na MS Windows zaplatime drahy SW... Nicmene uz to jde u
obou, drive v urcitych oblastech platilo, v Linuxu frcime, v MS Windows
si musime pockat az to nekdo naprogramuje a my si to pak budeme moci
koupit (za dahy peniz, protoze to byl jediny SW sveho druhu pro tuto
platformu, takze cena odpovidala)... - to je ten prosustrovany cas.

	Jinak jadro v Linuxu a aplikace neni az tak uplne rozdil, protoze jinak
mi asi tezko vysvetlite, proc v oficialnich jadrech jsou konstrukce,
ktere pomohou napr. tomu a tomu uzivatelskemu programu (serveru) v necem
o trosku byt rychlejsi, kdyz si nekdo chce usetrit par sekund, at si
udela upravy, ale v oficialnim jadre to nema co delat (myslim to co
posvecuje Linus, ne RedHat, Suse apod.), na druhou stranu v kernelu
chybi spousta veci jenom proto, ze se Linux blbe vyspal nebo ze se mu
proste nelibilo zavorkovani apod... - tomu se rika systematicky navrh?,
Kernel jako monolit ci jako monolit+moduly neni sam o sobe, interne vola
spoustu procesu (pravda, asi bezi v kernel-space, nikoli user-space),
coz jsou uz na kernelu pomerne nezavisle aplikace a komunikuje se
definovanych rozhrannim.

	Open source tu bylo davno pred Linuxem, proc teda projekty, ktere tu
byli drive dal spokojene ziji a maji naopak casto bourlivy vyvoj,
naopak, aplikace ktere zacaly ciste na Linuxu nebo s nim byly uzce
svazany jsou velikymi bumbrlicky ci doslova hniji? Je to v lidech,
kterym systematicka prace je cizi a pracuji pouze stylem ze co mne
zrovna napadlo a funguje je dobre a pojdme dal nebo v cem? Red Hat i MS
spoustu veci quli marketingu (do cehoz pocitam i zajem investoru a cenu
akcii aby bylo jasno) zprasi, co vsak k teto prasacke praci motivuje
lidi, kteri to delaji pro zabavu... - ono totiz neni od veci o problemu
premyslet a diskutovat i nekolik mesicu nez vznikne neco pouzitelneho
nez busit kod a furt ho prepisovat... - zajimave, ze v dnesni dobe se
uplatnuje zejmena 2. pristup a nikoho to netrapi - vsak se podivejme
kolik opravdu dobrych projektu timto zpusobem vzniklo (pouze vyjimky,
aby potvrdily pravidlo), nicmene hodnotne vysledky 1. pristupu vyuzivame
vsichno do dnes a nikdo nemuze rici kritiky ani co by se za nehet
veslo...

	A prave protoze ne kazdy muze byt dobry analytik, kazdy kdo programuje
a umi C neni dobry programator. Nic nezije izolovane a doby, kdy jsme se
museli vsichni necemu prizpusobovat (co se tyka SW) se pomalu mijeji,
proc teda Linux tuto dobu zacina silne vracet?

-----------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)                 FoNet, spol. s r. o.
Vyvoj software, Intranet / Internet          Anenska 11, 602 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
-----------------------------------------------------------------------