rh 7.0, gcc a problemy

[Pavel Kankovsky]

On Thu, 4 Jan 2001, Ing. Pavel PaJaSoft Janousek wrote:

> 	Pruzkum? Pokud je to v danem programovacim jazyce povolena konstrukce
> (s implementacne nezavislym vysledkem (nejlepe definovanym)), je to opet
> problem kompilatoru.

Jak uz nekdo rekl, ten pruzkum je nutny uz jenom z toho duvodu, aby se
zjistilo, jestli je spravne chovani ocekavane programem, nebo skutecne
chovani kompilatoru, pripadne zadne z nich. Aby to bylo jeste zajimavejsi,
tak mam takovy dojem, ze zrovna pravidla o tom, jak se smi optimalizovat
v situacich, kdy hrozi aliasing, prodelala ve standardech ne zcela
trivialni a intuitivni vyvoj, cili je tezke nekomu nasazovat psi hlavu
(nejlepe jsou na tom jazyky, kde zadny aliasing nehrozi: treba Prolog...
mimochodem prekladace vysokourovnovych jazyku jsou leckdy schopny
vygenerovat zdaleka nejlepsi kod, protoze jim programator nemuze moc
kecat do toho, jak to maji delat).

> Pokud je to implementacne zavisly vysledek, nema v multiplatformnim
> (nerknu-li multikompilatorovym) kodu co delat. Pokud skutecne autor
> kodu potrebuje takovou konstrukci, je jeho povinnosti sahnout po
> prostredcich nizsi urovne (napr. ASM)...

A co kdyz je to kus jadra v adresari arch? To tam ma byt vsechno
v asembleru?

> jenze tyto Intelovske kompilatory nejsou bezne rozsirene a
> bezne je vyvojari nepouzivaji (dodnes nevim proc..:-()

Rad zacnu kompilator od Intelu pouzivat, kdyz bude za rozumnou cenu, bude
umet vsechny veci, co potrebuju, a bude umet generovat kod jeste aspon pro
Sparc. :)

> 	Je hezke, ze Intel spolupracuje s vyvojari Linuxu na jadre pro
> I-64, ale proc?...takova podpora ze strany Intelu by nebyla nutna a
> kernel by po upravach a doplneni sekce /usr/src/linux/arch/i-64/*
> bezel i na teto platforme (vim, ze jsem to trochu zjednodusil, ale
> zase ne moc, do komunikace OS <-> cokoli zelezneho trochu hodne
> vidim).

Zajimave. A kdo nam poradi, co do toho adresare arch/i-64 napsat? :)

> 	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...

Definujte nejlepsi. (BTW: kdyz jsem sveho casu srovnaval GCC s cygwinu
s nejakou verzi VC a Borlandskym "rozvijecem maker", tak GCC generovalo
v mem konkretnim pripade nejrychlejsi (a zaroven korektni) kod.)

> Jaky mel Linux naskok oproti WinNT (odmyslime-li GUI, myslim po
> serverove strance) jeste v roce 1997 a jaky ma nyni?

Co se da delat, kdyz grafomani v Redmondu dokazou napsat a do sveho
systemu nacpat 10 milionu radek za rok? :)


On Thu, 4 Jan 2001, Ing. Pavel PaJaSoft Janousek wrote:

> 	??? GCC je zname tim, ze bohuzel mnohokrat naprosto korektni
> konstrukce prelozi v nesmysly (pruzkum staci nad vygenerovanym kodem),

Kontrolni otazka: kolik jste poslal bugreportu?

> 	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.

Protoze kdyz se nedomluvi, tak nic nebude fungovat. Standardy jsou pouze
jista forma, jak jisteho konsensu dosahnout.

> Co kernel potrebuje takoveho, co neni v definic ANSI C 1989 nebo ISO C
> 1990?

Co treba __inline__? __asm__? __attribute__((packed))?

> 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...

Tenhle argument, ale ma jednu chybu: drtiva vetsina programu pouziva
bitmapy apod. jako "opaque objects". Vytvari je -- nebo odnekud nacte
-- pomoci API, kresli do nich (z nich) pomoci API, ven je zas zapise
pomoci API. Cili programy se s novymi moznostmi vyrovnavaji tak, ze vubec
neberou na vedomi, ze tam nejake nove moznosti jsou. Nebo jsem neco spatne
pochopil?

> ...- 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?

Za prve jsou to rozhrani interni (tj. uvnitr jadra). Za druhe casto (ale
ne vzdycky) se zmeni i zpusob, jakym ma ovladac pracovat (napr. co a kdy
si ma zamykat). Na druhou stranu je pravda, ze se nic nesmi prehanet: kdyz
je rozhrani ve stavu permanentni inovace, tak se cely kod nepodari nikdy
stabilizovat.

> 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.?

Treba proto, ze (skoro) kazda nova verze je *fundamentalne lepsi*, nez ta 
predchozi. A ono by sice bylo fajn, kdyby puvodni navrh dokazal zvladnout
rozsireni o nove veci, ale kazda rozsiritelnost ma svuj strop.

> > Eee? Aplikace a jadro jsou naprosto nezavisle svety. O co konkretne tedy
> > jde?
> 	Milane, vazne ze mne nedelejte blbce, to vim take...

Ze by? A ja blbec spoustim jadro na tom samem pocitaci, co aplikace!? :)
(Tim chci naznacit, ze jadro zde neni pro svou vnitrni krasu, ale proto,
aby poskytovalo nejake sluzby, casto prave zminovanym aplikacim. A tudiz
je mluvit o "naprosto nezavislych svetech" absurdni.)

> 	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?

A co treba ten fakt, ze mezi pre-Linuxovymi projekty uz probehnul
prirozeny vyber a ty nezivotaschopne uz davno pochcipaly, zatimco u
projektu novych zminovany proces jeste probiha?


On Thu, 4 Jan 2001, Milan Kerslager wrote:

> Verte mi - udelate mesicni praci a pak se ukaze, ze to nekdo udelal jinak
> a lepe. To dokaze nastvat.

V takovem pripade to aspon muzete od toho druheho ukr...prevzit. Ale co
teprve kdyz neco udelate a zjistite, ze to sam musite udelat jinak a
lepe. :)

> O tom, jak se rozhoduje v RH nikdo nic nevi a kazdy tvrdi, ze blbe.

To uz tak byva.

> No, NT maji deklarovany mikrokernel a asi tomu nikdo neveri.

V Inside NT je popsana spousta zajimavych veci (BTW: obcas to vypada spis
jako Inside VMS), ktere mozna byly pravda v MS Windows NT 1.0, ale dnes
nepochybne patri do rise pohadek.

> Hurd je taky mikrokernel a nic moc.

Na tom ma IMHO aspon polovicni "zasluhu" Mach.

> Vite jak treba v mikrokernelu resit jednotnou cache, buffery & spol?

Kupodivu to je z vetsi casti jen otazka spravnych abstrakci.

> Myslet si, ze udrzite donekonecna uniformni rozhrani a ze se nebude nikdy
> menit je nesmysl. Prijde nova technologie, napad ci pozadavek a rozhrani
> je v haji (nebo nas bude svazovat).

Jiste. Ale casto je rozumne umoznit i komunikaci pres stare rozhrani: byt
s omezenimi a pripadne i mene efektivne. (Uvazujme napriklad ty drivery...
kolik mate zarizeni, kde opravdu zalezi na vykonu, a u kolika zarizeni na 
extra rezii treba 10 nebo 20 procent ve skutecnosti vubec nezalezi?)

> Monolit zde dokaze uplatnit pokrok a zachovat rychlost a vyhody
> nejlepsich reseni, umozni elegantne vybruslit z tesne provazanosti.

Monolit z tesne provazanosti vybrusli tak, ze ji prohlasi za vlastnost.
It's not a bug, it's a feature.

> Modularnost zajisti udrzeni primerene velikosti monolitickeho
> zakladu.... atd...

Ano: vyporadat se s vicemene tesnou provazanosti neni problem tech, co
udrzuji "monoliticky zaklad", ale tech, co udrzuji "moduly". Nevim o tom,
ze by Linux nekdy byl modularni v tom smyslu, ze by rozhrani pro moduly
bylo stejne "oficialni" jako treba syscally (coby rozhrani s userlandem).
Externi moduly mely (a AFAIK stale maji) spis status chytre udelanych
patchu do jadra.


On Thu, 4 Jan 2001, Ing. Pavel PaJaSoft Janousek wrote:

> v okamziku kdy bude daleko vice veci Linux only to bude znamenat
> prevahu Linuxu a pak?

Jestlize nekdo vyrobi neco Linux-only (mineno na hw, ale mozna se to da
aplikovat i sireji), pak si zaslouzi stejne opovrzeni, jako kdyz vyrobi
neco Windows-only, bez ohledu na to, jestli Linux mam rad nebo ne.

> ... a ze problemy, ktere zpusobuji jsou zpusobeny pouze a jenom
> lidskou omezenosti nebo lenosti v danem okamziku udelat neco lepsiho
> aniz by si dotycny spocital, ze on vynalozi cas na zlepseni rekneme
> 100x vetsi, ale uzivatelu je nesrovnatelne vice...

Tak at si to ti zatraceni uzivatele udelaji lepe sami, kdyz o to stoji. :)
(Tedy za predpokladu, ze od nich nejsem za vyvoj primo placen.)

> Ten ftip o programatorech, stavitelich a cervotoci je 100% pravdivy...
> (bohuzel)

Tak ten jsem neslysel. :P

> 	Neustale prepisovani odladeneho a naprosto funkcniho kodu
> myslite vazne (COBOL & banky Vam neco rika?)? Kdyby vsichni takto
> uvazovali, pak by svet software vypadal asi uplne jinak...'-)

"Naprosto funkcni kod" v praxi neexistuje. Existuje pouze kod, s jehoz
rezidualnimi nedostatky (at jsou to chyby nebo nedostatecna funkcnost)
jsme se smirili.

> 	Porad je to o tom samem... o navrhu, osobne neverim moc tomu, ze kdyz
> Linus na truc svemu vedoucimu na VS zacal psat Linux, ze se silne
> zabyvam systematickym navrhem celeho Linuxu.

Vzhledem k tomu, ze ho asi ani v nejblaznivejsim snu nenapadlo, kde to
skonci, tak se tim asi tezko zabyval. Ostatne cela idea prototypu spociva
v tom, ze nekdy je proste nejlepsi provest pruzkum bojem.


On Thu, 4 Jan 2001, Martin Mačok wrote:

> Mikrokernel ma take vetsi tendence nevyuzivat vsechny moznosti
> hardware, ale tenduje spise k 'lowest common denominator' resenim.

A co L4?! :)

> I monoliticke jadro muze byt navrzeno tak, ze bude prehledne a pekne
> oddelena cast zavisla na architekture a nezavisla vyssi vrstva, a muze
> mit modularni charakter.

Pak to ale uz neni *monoliticke* jadro. Kdyz nekdo neco oznacuje za
monoliticke, tak tim vetsinou chce zduraznit absenci jakekoli relevantni
vnitrni struktury.

> Ono to muze byt take tim, ze Linus si uz jentak nedovoli neco
> prohlasit za stabilni a radeji stravi vetsi cas ladenim a testovanim.

Linus moc velky fanda ladeni neni. To je take duvod, proc zurive odmita
davat do (standardniho) jadra kernel debugger, aby lidi nezacali opravovat
jadro stylem, ktery lze charakterizovat zpusobem, jakym jisty cesky
velikan definoval pred mnoha lety debugger (priblizne), totiz jako
"nastroj, kterym lze ze spatneho zdrojaku vyrobit fungujici program ve
strojovem kodu." Je to jiste dobry argument...akorat ma ta mince i druhou
stranu, totiz ze v pripade sporadicky se vyskytujicich chyb muze byt neco
ve stylu kdb (nebo aspon automaticky jaderny coredump) jedina moznost, jak
prijit na to, kde a proc se neco pokazilo (kdyz jadro hodi "jadernou
tlamu", jak rikaji nekteri kolegove, tak to podobne jako u jinych programu
casto vypada tak, ze jedna cast neco zvorala a uplne jina kvuli tomu
zhavarovala, procez je vypis registru celkem na nic).


On 4 Jan 2001, Stanislav Meduna wrote:

> Ono to niekedy nie je take jednoznacne, zvlast v pokrocilejsich
> C++ konstrukciach obcas nevie nikto, co je vlastne v poriadku
> (obcas mam pocit, ze ani Stroustrup nie :-)).

Jak se v tom ma nekdo vyznat, kdyz se to jeste mezi vznikem jazyka a
jeho standardizaci (je vlastne uz ten ISO standard schvaleny?) nekolikrat
zmenilo. :)

> Zo zahadnych dovodov sa mi v niektorych balikoch niektore
> subory nenainstalovali. Po odinstalovani a novom nainstalovani
> vsetko v poriadku. Reprodukovatelne to nie je, takze do
> bugzilly nemam co napisat. Nech zije nove rpm...

Anaconda AFAIK nepouziva program rpm, ale jakousi dynamickou knihovnu,
takze neni vylouceno, ze se muze chovat trochu odlisne. I v pripade, ze to
nelze reprodukovat, bych to nahlasil, treba se nekdo bude nudit, podiva se
na ten kod pozorneji a chybu "uvidi".

(Mimochodem: konecne jsem take zazil, ze mi Anaconda spadla. Ale
protoze instalace probihala z pomerne naladove CD mechaniky, ktera
obcas cte, obcas ne, tak se obavam, ze to nelze tak uplne oznacit za
chybu toho programu. :> )

> Kompatibilita starych binarok? To bolo slubov, ze binarky linkovane
> proti 2.1 budu chodit. Ani nahodou - napr. stara java runtime
> ma potesi promptnym coredumpom, takze kvoli internet bankingu
> budem znovu bootovat do windowsov. Kaffe to zial nezvladne.

Krome toho, ze u Javy je padani na drzku podle mych zkusenosti spis
standardni chovani (heh...a tohle se bude davat do lednicek a zehlicek?
Buh nas chran), tak nikdo nikomu nebrani pouzit LD_LIBRARY_PATH a spol. a
pouzivat stare knihovny. Nebo snad ano? :)


On Fri, 5 Jan 2001, Martin Mačok wrote:

> No, abychom to zase neprehaneli ... zas tak neefektivni ty
> mikrokernely nejsou a urcite by slo napsat mikrokernel efektivnejsi
> (v konkretnich ohledech) nez je soucasny linux. Jiny fakt zase je, ze
> vetsina technik zefektivneni mikrokernelu lze pouzit i na monoliticky
> kernel.

Treba porovnani rychlosti vetsiny zakladnich operaci na EROSu s Linuxem
vypada zajimave. (A porovnani rychlosti IPC QNXu a rour na Linuxu pry take
vypada zajimave: ty roury jsou udajne podstatne rychlejsi. :> )

> P.S. Ja nepodporuji snahy o prechod Linuxu na mikrokernelovou
> architekturu, nicmene zas tak strasny ten mikrokernel neni ;-)

Minimalne se vicemene jedine s touto architekturou da vyrobit fungujici
reference monitor (ktery musi byt uplny, izolovany a verifikovatelny, jak
se docteme v kazde chytre knize). :)


--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."