Názory k článku Porovnání systémů Linux a FreeBSD

Dekuji za clanek, uz se tesim na pokracovani.

planuje redakcia v buducnosti clanok s porovnanim freebsd a linux z hladiska softwaru, podpory hw, vyhod a nevyhod z hladiska nasadenia ako serveru a desktopu ?

a proc by tam nemohl okrajove jeste pribyt i win?

postupne sa root.cz zmeni na zive.cz/sk.

uz teraz sa k tomu zacina clankami o MDK blizit ... a hlavne ked sa pozrieme na to obecenstvo, ktore o tych clankoch diskutuje

Je trošku rozdíl mezi popisem vnějšího chování systému, porovnání barevnosti tlačítek příp. rychlosti překreslování grafiky jako na Živě a datailním srovnáním funkcí jader různých systémů. Tedy já se rozhodně přikláním k tomu, aby do článků podobného druhu byly zařazeny i Windows, pokud o nich autor chce psát. Rozhodně mne to zajímá. Krom toho bych si přál větší důraz na připravované jádro 2.6, zvláště pokud v něm budou výrazné změny oproti 2.4 v příslušné oblasti, alespoň v rozsahu jako je věnován FreeBSD 5.x

Článek se mi velmi líbil.

O Windows se toho moc napsat nedá, protože k nim nejsou zdrojáky.

Chce to jen začít prakticky experimentovat se zdrojáky na nějaké malé disketové distribuci

Mno, takhle nějak bych si představoval článek srovnávající Linux a FreeBSD, ne jako ty flamebaity, co vycházejí jinde... Jen tak dál.

velmi dobry clanek!

neni to tak davno, co jsem cetl na blackhole.sk taky srovnani linuxu a freebsd (autor neologism, viz http://www.blackhole.sk/readme.php?id=147) -- coz byla (je) naprosta ubohost.

jen tak dal.

Skvele, doufam ze na rootu zacne vychazet vic takovych clanku a serialu.

Mam jen jednu poznamku: Je asi jasne ze jako Linux berete zrejme nepatchovane jadro z kernel.org
z cimz souhlasim, ale mozna by bylo vhodne v dalsich serialech zminit, kdyz uz jste byl u tech NT, take jina komercni, ale Linuxova jadra.
Napr. jadro do SUSE uz myslim od verze 8.1, nebo 8.2 obsahuje implementovany preemptvni multitasking a myslim ze dokonce i na root.cz se objevila tiskova zprava o vydani real-timove distribuce od SUSE.
To je vsak jen jedno dalsi jadro...

Jo, beru standartni jadra. Pokud nekdo dodava napriklad 2.4 s podporou preemptivniho kernelu, je to hazard a muze to docela slusne padat. (problemem je tzv. cpu-local area --- kazde CPU ma vyhrazenu oblast pameti pouze pro ne, na nepreemptivnim kernelu mohou ovladace s touto oblasti pracovat bez zamku, na preemptivnim kernelu je v tomto kodu race. Je potreba audit celeho kernelu, ze se to vzdy pouziva se zamky, nestaci pouze jednoduchy patch na preempci).

Co se tyce real-timovani --- existuji real-time interrupty a real-time prepinani procesu. Linux neumi ani jedno --- staci napriklad prepnout konzoli nebo poslat nejaky escape-code na scrollovani casti obrazovky a po celou dobu kresleni konzole jsou zakazana preruseni.

Kdysi existoval projekt behu linuxu nad realtimovym mikrokernelem, myslim, ze se to jmenovalo mkLinux.

V nejakych sofwarovych novinach jsem cetl o RTLinuxu. RT mikrokernel, ktery provozuje Linux jako jeden z nekolika RT procesu. (Linux ma nejnizsi prioritu).

Hlavni vec, kterou RT mikrokernel resi je emulace zakazovani preruseni pro Linuxove jadro.

Pridavam se k pochvale za clanek. Fakt dobry.

RT Linux existuje. Pro zajemce uvadim par uzitecnych odkazu:

http://www.rtlinux-gpl.org/
http://www.ocera.org/
http://bernia.disca.upv.es/rtportal/

No ona SUSE rekl bych je uz nejakou dobu jakymsi nastupcem UNIXu, je to "napad" Linux a "dokonalost" UNIXu.
Precetl jsem si neco co jsem o vyse zminovanych real-time patchich, ktere byly zmineny a s neprilis lichotivym nazorem na ne musim souhlasit, je to jiste dobra snaha, ale jeste v plenkach...

Abych se vratil k SUSE: implementovala preepmtivni multitasking, bez ztraty stability a bezpecnosti kernelu, z narocneho provozniho nasazeni ve kterem je pouzivame to muzu potvrdit.
Priznam se ze uplne, i kdyz je Open-Source, tyhle mechanismy v SUSE jadre neznam...

Pkud vim, tak SUSE kernel neni preemptivni, ale jsou tam low-latency patche, ktere umoznuji dosazeni rychle odezvy i bez hazardu s preemptivnosti.

Jak jsem rikal "preemptivnost" SUSE kernelu jsem nijak blize nestudoval. Vzpomnel jsem ji jen na jejich tiskovou zpravu a pozdeji na CGL...

http://www.suse.de/us/company/press/press_releases/archive03/cgl.html

Velmi dobre napsany clanek, tesim se na pokracovani :-)

Připojuji se k ostatním a děkuji za článek. Už delší dobu jsem si chtěl něco podobného přečíst.

Petr Krčmář

Fakt perfektni clanek .... Diky

Dekuji za zajimavy clanek. Nejsem odbornikem na jadro, ale to jeste neznamena, ze se o nej nezajimam.
Ocenuji Vas vyklad, ktery je i pro laika srozumitelny, a zaroven neni psan jako dvoustrankove clanky typu "Co vsechno lze delat s pocitacovou mysi".
BTW: Mohl byste treba jen okrajove zminit vyhody/nevyhody casto diskutovaneho monolitickeho kernelu vs mikrokernelu (napr. situaci, kdy selze ovladac v jadre a slozi cely system (z vl. zkusenosti); ovladacu bude pribyvat, riziko se zvysuje).

taky se pripojim ke gratulacim za vyborny clanek.

ad Monoliticky kernel....
Obavam se, ze detaily a srovnavani Monilitickeho kernelu, mikrokernelu nebo treba i exokernelu a ja nevim co jeste ...kernelu, by vydalo na samostatny clanek ne-li serial. Ne ze by to nebylo zajimave, prave NAOPAK - kdyby se nasel nekdo kdo se v problematice orientuje a napsal o tom clanek bylo by to velmi zasluzne.

To mne pripomina, ze uzivatelsky manual k nasem projektu skutecne obsahoval navod, jak klikat mysi --- u obhajoby si na to dokonce nekdo stezoval :-)

Co se tyce diskuze monoliticky kernel vs. mikrokernel --- dnes je to uplne dead. Mikrokernely se nepouzivaji. Casto se o necem prohlasuje, ze je to mikrokernel, i kdyz neni (napr. prvni verze Windows NT, BeOS).

A co hurd? ;-)

O pardon zapomnel jsem na to slovicko "nepouzivaji" :-)))

MacOS X je cistym mikrokernelovym systemem prevzatym z Mach. Funguje velmi dobre, pisu na nem tenhle prispevek :-)

Je teda ale pravda, ze moznost pridavat moduly (zde se nazyvaji kernel extensions) do kernelu bez rekomplilace je supr, ale casto to nepouzivam.

Myslim, ze jsem nekde cetl, ze nad tim Machem bezi prakticky cely kernel jako jeden z procesu -- takze je v podstate monoliticky. Ani bych se tomu nedivil, kdyz pri vyvoji OS vysli z monotlitickeho BSD.

Mac OS X není mikrokernel. Dokonce v něm ani standartní unixový kernel "neběží" nad Machem jako proces. Mac OS X je normální BSD kernel, s kernelem obsluhujícím unixové syscally a se všemi drivery v kernelspace, který má přidané možnosti meziprocesové komunikace z Machu. Někomu nestačily pipy, unix domain sockety s sysV IPC, a tak si vymyslel, že tam chce ještě komunikační primitiva z Machu. Podle mě je to zbytečný featurismus.

Microkernel je pouzivan v QNX. Nejsem odboznik na QNX, ale rozhodne si nemyslim, ze by to bylo DEAD :).

QNX zije, na get.qnx.com je mozne si stahnout iso image tohohle systemu, nicmene je skoda ze jejich demodisky na diskete, ktere pripominaly z dnesni doby treba menuetOS, uz nejsou na hlavni site k dispozici, jen na par mirrorech...

Mimochodem pripojuji se k halasnemu potlesku za nesmirne podareny clanek, jen tak dal. Primluvil bych se za dalsi verze BSD, aspon trochu.

Take si myslim, ze mikrokernely nejsou mrtve. Treba True64 Unix je zalozen na Machu a kolega na to psal nejake ovladace pro telekomunikacni zarizeni. Kdyz jsem s nim o tom mluvil, jen chrochtal blahem a liboval si, jak je to perfektni architektura.

Hezky clanek, ale co se tyka mikrokernelu - co treba QNX, NonStop nebo AIX?

Jinak fajn, dik.

o windows nt se prohlasuje, ze se jedna o !_modifikovany_! microkernel, s cimz se plne ztotoznuji. NT jsou tak vnitrne navrzene. prostudujte si, co je potreba ...

(totez samozrejme plati o NT+)

Ech. Tak potom nechápu jak ten systém může shodit nejen špatně napsaný ovladač, ale dokonce i aplikace. To z toho mikrokernelu moc nezbylo, co?

Definice: Mikrokernel je systém, ve kterém ovladače (filesystému, blokového zařízení a sítě) běží v userspace. Ve Windows NT všechny tyto ovladače běží v kernelspace, proto to mikrokernel není. Totéž platí pro MacOS X, BeOS (tam si nejsem jist, kde běží síť. Filesystém je tam určitě v kernelu), takže to též mikrokernely nejsou.

myslim, ze nejde o ovladace, ale o subsystemy. tj v true microkernel os by v kernelspace mel bezet pouze scheduler + nejaky ipc mechanismus (mozna jeste memory managment) a zbytkove subsystemy os by mely bezet v separatnich procesech.

ok s tim souhlasim, ale ja mluvila o "modified microkernel" :-) mozna pro Vas bude neprijatelne, ze tento termin (zrejme) zavedl Microsoft, ale to je mi vcelku jedno.

NT takes a unique approach, known as modified microkernel, that falls between pure microkernel and monolithic design. In NT's modified microkernel design, operating system environments execute in user mode as discrete processes, including DOS, Win16, Win32, OS/2, and POSIX (DOS and Win16 are not shown in Figure 1). The basic operating system subsystems, including the Process Manager and the Virtual Memory Manager, execute in kernel mode, and they are compiled into one file image. These kernel-mode subsystems are not separate processes, and they can communicate with one another by using function calls for maximum performance.

urcite subsystemy bezi sice v kernel modu, ale maji urcity interface - vysoka modularita _je_ tam proste videt (i v kodu). coz u true monolithic kernels rozhodne neni pravda.

nicmene nechci slovickarit, timto koncim moje prispevky do tohoto threadu. musel byste predlozit velmi padne argumenty, protoze ja svuj nazor mam pomerne dobre podlozeny :-)

Skvele, skvele a este raz skvele!!!

PERFEKTNY clanok. vzdy ma zaujimalo, ako sa riesia tieto veci na unixoch, presne toto som hladal, len tak dalej :)

Zdravmi vespolek :)

Aby autor nemel same pochvalne nazory, tak si dovolim upozornit na jednu (celkem velkou :) nepresnost:

"Kvalitnější zařízení na latenci přerušení moc závislá nejsou: kvalitní zvukové karty mají velikou vyrovnávací paměť"

To je ve spouste pripadu (notabene na zvukove karte) naprosta blbost. Pokud delam se zvukem a zvednu si zpozdeni na vice nez (radove) desitky mS, tak je to NEPOUZITELNE na nic jineho, nez na hrani her pripadne na poslouchani hudby. A pokud vezmy vystup 'obycejne' zvykove karty, 4 kanaly, 24 bitu, 50khz, tak tok odpovida radove ~pul mega za vterinu. A takova karta dneska stoji 5tikilo.... Pokud vezmu nejakou lepsi kartu - 8 sync kanalu, 96KHz, vystup digitalni - optika, jsem jeste o kousek dal se sirkou pasma. Cim MENSI buffer, tim 'kvalitnejsi' zarizeni je - ty opravdu top jsou schopny sample accuracy. Coz je schopnost (zjednodusene) reagovat na vstup/vystupy s presnosti na JEDEN samplik :) O velkem buferu zde tedy moc rec byt nemuze.

Nejedna se jen o zvukove karty, ale defato temer kazde zarizeni, majici vystup 'mimo' pocitac. Buffer je zde spise na obtiz. Proto, cim lepsi obsluha preruseni, cim lepsi 'priority', tim vice je pocutac pozuitelny na neco jineho, nez jako psaci/herni stroj. Cim vetsi moznosti jsou, tim vetsi potreba je 'realtime'. Nekdy je rozdil mezi 'lspon trochu realtime' a 'normlanim' v pouzitelnost ci nepouzitelnosti...

Nicmene, jinak pekny clanek :)
R.

Doporučuji Vám přečíst si specifikaci OSS případně kód ALSA(y). Vyšší četnost přerušení jaksi neznamená "low latency". Mimochodem, jsou i pracovní stanice, které mají hardwarou synchonizaci "multimedií" a není zrovna snadné napsat pro ně "čistý" ovladač.

Vim, nejaky jsem uz napsal.. [narp. core linux ovladace pro Alesis ADAT, ale to uz je nejaky patek zpet] A zrovna ALSA(u) bych nedaval jako priklad neceho extra dobreho :\ Kod alsy znam celkem dobre, co z nej mam vysist ?

Krom toho jsem primarne reagoval na tvrzeni, ze 'bufer' na karte vse resi. Pokud je dodavani dat postaveno na jinem principu nez preruseni, pak pro zmenu stoji zbytecny CPU cas a pokud neni dedicated CPU (nebo vice), je to i 'plytvani'. Pokud ma ale karta svoje DSP (nebo je to matice DSP procesoru/karet), pak je to o necem uplne jinem.

R.

teď už chápu o co šlo. napíšu to tedy jinak: pokud je karta tak blbá, že nedokáže držek krok s okolím (třeba lehkou změnou samplerate), nebude ani častější přerušování ideálním řešením. někdy je zkrátka výhodnější, aby přerušení chodilo třeba po každých 4k a mezi tím se podívat, kde se zrovna brouzdá DMA pointer. takže buffer někde v převodníku toho moc neřeší nebo je rovnou na obtíž, na tom se shodneme. omlouvám se za svou nechápavost :-)

V tom se urcite shodnem :)

Nekdy je osemetne se v teto tematice (obecne) vyjadrit presne, aniz by clovek nenapsal 2 stranky :\

R.

Diky za pripominku ... takove high-end zarizeni jsem ani neuvazoval. Pro bezne BFU staci, aby karta prehravala MP3, a tady je opravdu velky buffer potreba :)

oops! :)
mna napriklad velmi zaujima problematika kernelov, nejake som dokonca vyplodil sam, ale viac menej koli nejakym vyskumnym projektom ako koli podpore low- alebo high-end zvukovych kariet, cize co sa tyka tohto threadu som BFU. ale clanku tlieskam (i ked linuze mam prestudovane, bsd menej. :))
drzim palce a tesim sa na dalsie casti.

tyhle funkce musí umřít. dříve je lépe. existují sice funkce (makra) wait_event, ale jejich použití je poněkud těžkopádné (vzhledem k tomu, že je třeba podmínku obvykle chránit spinlocky).

a ještě pochvala autorovi, po dlouhé době článek, který se dá číst :-)

Som rad, ze zacal zase jeden skvely serial na rootovi.
Uz, aby bol dalsi diel.
Osobne by som sa prihovoril, ak by to bolo mozne,
porovnat aj veci s NetBSD, pripadne ineho OS.
Vdaka.

Vybral jsem FreeBSD, protoze je nejkvalitnejsi. NetBSD je dost podobne FreeBSD, ale nektere veci, jako napriklad podpora SMP nebo virtualni pamet, je tam celkem pozadu. OpenBSD je pozadu jeste vic.

Zadny jiny kvalitni OS, ke kteremu jsou zdrojaky, neznam:
AtheOS(Syllable) --- ne prilis kvalitni kernel, autor se zrejme na rychlost moc nezameroval.
Darwin --- strasna splacanina --- v jednom adresari je FreeBSD, ve druhem Mach, a splacavali to dohromady tak dlouho, az to slo zkompilovat.

> Zadny jiny kvalitni OS, ke kteremu jsou zdrojaky,
> neznam:

K Solarisu nejsou zdrojaky, nebo je nekvalitni?

Zdrojáky k solarisu nejsou ... nebo aspoň donedávna nebyly --- pokud už jsou (bez nějakého omezujícího NDA typu "nesmíte nikomu říct, co jste tam viděli" nebo "nesmíte psát vlastní operační systém, ksyž se na to podíváte"), tak mi řekněte.

No, v kernelech se sice nevyznam, ale OpenBSD uz celkem dlouho pouzivam a nemyslim, ze jsou nejak pozadu. Mozna ve vykonu, nepodporuji vic procesoru apod., ale vykon neni vsechno. Jinak fajn clanek, jen houst a vetsi kapky.

Nechci rozpoutat dalsi flame ale neprijde mi, ze by NetBSD bylo tolik pozadu. Souhlasim, ze SMP ma linux asi lepe odlazene, co se tyka virtualni pameti se nechci prit ale pokud se jedna cisteho vykonu tak na tom NetBSD je velmi dobre (asi zavisi na konkretni aplikaci, mluvim o tom, co delam doma). Osobne jsem dost zvedavej na NetBSD 2.0 a obecne se od nej ceka hodne, vcetne vylepseni toho co mu vytykate. A na druhou stranu, NetBSD kernel je opravdu cistsi nez linuxový nebo FreeBSD. Linux a FreeBSD mezi sebou soutezi a proto se obcas (dle meho nazoru) do jejich jader nektere veci dostavaji moc brzy. NetBSD stoji stranou a udrzuje svuj kod relativne cisty. Jsem subscribed do NetBSD mailing listu a tam se obcas objevi nejake to flame NetBSD vs. Linux a prestoze casteji pouzivam Linux nez NetBSD (je snazsi ho sehnat, nemam moc silne pripojeni) tak docela casto musim dat zastancum NetBSD za pravdu. Napr. benchmark rychlosti disku (uz si to nepamatuji presne) dopadl na mojich trech strojich jednoznacne lepe pro NetBSD. Z lidi co znam co se toci kolem BSD hodne FreeBSD zavrhuje pro jeho relativne vetsi nenazranost nez NetBSD. OpenBSD je zase derivat NetBSD zamereny na bezpecnost, ktery ale dle meho nazoru nema velky uspech - nebo spise ostatni BSD nemaji dost bezpecnostnich problemu. Pocet exploitů je pro ruzna BSD priblizne stejny. Trochu chaoticke a offtopic, ale nemohl jsem se NetBSD nezastat. Jinak jako člověku který se o vnitřní strukturu OS vždy zajímal ale nikdy neměl možnost se s ní lépe seznámit mi článek hodně dal a doufám, že se dočkám pokračování. Díky.

Před pár lety jsem NetBSD zkusil (bylo to 1.4) a zhrozil jsem se --- systém měl předalokovanou fixní paměť na diskové buffery a ostatní paměť nemohl použít jako cache --- v praxi to fungovalo tak, že člověk měl 160M ram, z čehož 130M bylo volných a disk chroustal. Nebýt tohoto problému, možná bych dnes NetBSD používal. Jinak se mi pro svou stabilitu a čistotu líbilo.

Vím, že dnes už dynamickou cache udělali, ale přesto asi budou stále pozadu za FreeBSD.

Ctím tvoji asi o dost větší zkušenost, a věřím, že díky menší rozšířenosti může být NetBSD občas trochu pozadu. Některý tyhle problémy vyvěraj z toho, že NetBSD klade důraz na co největší portabilitu. Občas se na mailing listech objeví návrh, aby se při řešení určítého problému na toto rezignovalo (pokud si vzpomínám, tak se mluvilo hlavně o zvukových ovladačích - někdo navrhoval port ALSA), ale moc se tyto návrh neuajaly a je to dle mého názoru dobře - výsledek je třeba dosažen pomaleji, ale o to je čistší (špatný kód málokdy pracuje na více jak 40ti platformách). Doporučuji vyzkoušet NetBSD 1.6.1 či počkat na 2.0. Pro diskuzi o zákoutích kernelu by asi byl lepším partnerem Jarda Doleček, ale ten asi zdejší diskuzi nečte. Jinak ještě jednou děkuju za článek, rozhodně mi rozšířil obzory.

Ahoj,

jen bych doplnil, ze krome vlastnich semaforu s 'up' a 'down' (implementace pomoci wait_queues) existuje jeste sada funkci:

spin_lock,spin_lock_irqsave, spin_lock_irq a spin_lock_bh (+ odpovidajici unlock)

coz jsou obecne zamky a k tomu jeste read_lock a write_lock (se vsemi verzemi jako spin) coz jsou zamky pro cteni a zapis - podrobnosti viz include/linux/spinlock.h (a dale do asm/spinlock.h)

Jinak super clanek, uz se tesim na dalsi dily. Myslim, ze je vhodne pokud mozno co nejvice uvadet odkazy na dokumenty nebo primo zdrojaky pro ty, co se na to chteji podivat pozorneji a take uvadet presne verze jader na kterych je vse popisovano.

Bye

když už doplňujeme a upřesňujeme... :-)

spinlocky se typicky používají při race condition (jak se to překládá?) s přerušením a v takto chráněném bloku nelze volat funkci která může spát - tj. provést context switch. preemtivní scheduler nepřeruší kód mezi spinlock/unlock.

naproti tomu down/up lze použít i v případě, že zamknutý kód usnout může - například při volání copy_to_user.

Bych prekladal jako soubeh (udalosti).

Spinlocky budou popsany az v pristim clanku, ktery bude venovany SMP.

pokial ta zaujima nieco viac o napr. o freebsd tak na tejto stranke najdes celkom slusne dokumenty http://www.freebsd.org/docs.html. ak by som mal nieco vyzdvihnut tak je to dokument http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/index.html kde ako tak opisane aj jadro systemu.

DD;
nakolko tento clanok je iba urivok z diplomovej prace link:
http://artax.karlin.mff.cuni.cz/~mikulas/doc/
veeelmi odporucam precitat :)
Erik

Nekaz to :)
Ano, tento serial je z Mikulasovy diplomky, protoze mne se ta diplomka libila, tak ho Mikulas dostal za ukol udelat :)
Ale kdyz si ji vsichni prectou, nikdo nebude cist serial! ;)

Jo, ten clanek je z toho. Komu se nechce cekat na dalsi dily, muze si to tam precist :-) Zase na druhou stranu v techhle serialech to asi na par mistech updatovane, ta diplomka je psana z obdovi Linuxu-2.5.23 --- 2.5.47 a FreeBSD 5.0.

Cetl jsem autorovu diplomku a dodnes premyslim, v jakem jazyce je vlastne psana :-). V teto souvislosti me prijemne prekvapilo, ze clanek na roota se podstatne vic blizi cestine nez ta diplomka. Teda az na "tu inodu" - proc ne ten i-node nebo ten i-uzel? Kdyz uz je pro neco cesky termin a kupodivu se i pouziva a neni to nic sroubovaneho/nezvykleho (jako treba "slozka" atp.) tak proc nepouzit cesky termin?

Jinak samozrejme OK, po dlouhe dobe clanek na rootu ktery se da cist (a ne jen proletet prvni vety odstavcu, jestli tam nahodou neni vyhled na nejakou novou informaci).

-Yenya

Já jsem si autorovu diplomku také přečetl a myslím, že není možné ji oznámkovat jednou známkou. Musí na to být známky dvě: technická 1 s hvězdičkou, jazyková 6...

Jsem dotcena - ta diplomka prosla moji korekturou! :)
Gramaticky chyby tam nejsou, ale do terminologie a misty dost obskurniho slohu jsem Mikulasovi, pravda, nezasahovala :)

Chci jen zmínit dvě věci mně sympatické na *BSD: striktní oddělení základního systému (kernel, gcc, libc...) od ostatních aplikací (ports, packages) a přehlednost + jednotnost init skriptů (vše v rc.conf). V Linuxu nic takového není (Linux je jen jádro), každá distribuce to má jiné. Také s podporou IPv6 na tom bude BSD líp. Jedna věc je porovnávat kernel, jiná věc porovnávat systém jako celek. Nechci prudit, ale BSD je extraliga, zatímco Linux "jen" 1.liga.

Zrovna s tim IPv6 bych si nebyl tak jisty ;-) Taky muzete napsat kolik moderniho hardware napr. z oblasti multimedii *BSD podporuji? :-)

Jako kdyby multimédia bylo to nejdůležitější na OS. V BSD je to později, zato kvalitněji (NetBSD: "We provide solutions, not hacks..."). Ad IPv6: Čím by sis nebyl tak jistý? Linux zde hodně kopíruje z BSD (projekt WIDE/KAME). A je to dobře, od toho je tu opensource, nejde o to soutěžit, ale spolupracovat (jsme snad MS či co?)

A co je na OS nejdulezitejsi? Ze nabootuje? :-)
Ja treba zrovna od OS pro domaci pracovni stanici vyzaduju podporu multimedii. Tam mi pak bude sebelepsi system bez teto podpory k nicemu.
Takze pouzivam veci k cemu se nejlepe hodi a netvrdim jedno fuj a druhe huj.

Dalsi, ktery si mysli, ze je "extraliga", protoze ma BSD :-)

To mi silne pripomina ono "porovnani" na blackhole, kde polovina argumentu byla totalni blud a druha polovina byla zalozena na tom, ze autor porovnaval hrusky s jablkama - kompletni NetBSD a jenom jadro Linuxu.

A mimochodem - treba Debianovsky system init scriptu mi prijde velmi dobry :-)

By mě zajímalo, co si představuješ pod pojmem "Kompletní NetBSD"? Mimochodem, na blackhole.sk se mluvilo o FreeBSD. Zkus si nainstalovat BSD (Free nebo Net) trošku ho potrápit a pak si můžem pokecat. Nesnažím se být fanatik, ale taky nemám rád linuxové fanatiky (kdo si to tu dovoluje házet špínu na můj posvátný linux:-) Nejdřív se snaž poznávat a pak porovnávej. Souhlasím s tím, že článek na blackhole.sk byl trošku ujetej, ale zas tak úplně z cesty nebyl.
Ad init skripty: netvrdím, že v Linuxu jsou špatný. Jen to, že tu oproti Net/FreeBSD chybí jednotnej styl.
Know your enemy...:-)

Sorry, v mem predchozim %s/NetBSD/FreeBSD ;-) A linuxovy fanatik rozhodne nejsem, viz moje nazory treba u clanku o hrach :-)

Ja jsem nepsal nic o spine, jen jsem upozornoval, ze neni mozne srovnavat jablka s hruskama. Me prijde, ze BSDckari proste nechapou, ze Linuxovy svet ma jinou strukturu. Nema smysl porovnavat FreeBSD a Linux, ma smysl porovnavat (treba) FreeBSD a Debiana. TOHLE jsou hrusky a hrusky :-) Pak odpadnou treba i nesmyslne argumenty o jednotnem stylu - v Debianu to je vsechno jednotne.

Souhlas. Nechtěl jsem vyvolat slovní přestřelku. Jen se snažím říct, že i Linuxákovi se vyplatí něco vědět o BSD ev. dalších UNIXech. Čím víc toho znám tím víc dokážu některý věci ocenit. Samozřejmě nejde o to, co je lepší, ale jak to vyhovuje potřebám toho, kdo to používá/programuje v tom. Totalita je vždycky škodlivá.

Technický dotaz - je u BSD něco jako distribuce? Nikdy jsem s tímto systémem nedělal, ale mám nejasné tušení, že ne, že je to prostě jeden "balík" jádra a programů kolem, v podstatě jako by v Linuxu byla k dispozici jen jedna distribuce. A u jedné distribuce se jednotnost dodržuje celkem snadno ;-)
Kdyžtak mě opravte, možná se mýlím.

Prave ze je to tak jak pisete :-) Vycitat Linuxu, ze ma bordel v init scriptech je - striktne vzato - nesmysl, protoze LINUX je jadro, ktere s init scripty nema nic spolecneho :-)

V zásadě máš pravdu. Třeba u NetBSD 1.6.1 máš základní CDčko(cca 120MB) - vlastní OS. To obsahuje boot. kernel, base system, man, gcc, Xsy. Pak je tu (myšleno pro architekturu i386) dalších 7 CDček binárek. To už není NetBSD, ale tzv. "Packages" - aplikace(mc, perl, cdrecord, apache, gnome, kde...). Packages ale můžeš instalovat i ze zdrojáků (víc na jejich webu). Výhodou je přehlednost a snadná aktualizace.Stačí dát make a vše se stáhne a zkompiluje samo. V Linuxu si zase může člověk dle chuti vybrat mezi klikacíma (Mandrake) a syrovýma (Slackware) distribucema - prostě co mu víc vyhovuje.

Ac mam Debian jinak rad, jeho init scripty mi prijdou naprosto priserny (stejne jako v RedHatu, ba mozna jeste o neco prisernejsi). To, ze je po nainstalovani libovolneho balicku s nejakym demonem tento demon aktivovan je z bezpectnostniho hlediska zvrhlost. Podivejte se, kolik otevrenych portu je na pocitaci po instalaci Debianu. Navic tu neexistuje zadny standartni zpusob jak tyto slyzby vypnout (ja prejmenovavam symlinky S* na s*). To v RedHatu ci Irixu na to aspon existuje utilita (chkconfig tusim ci interaktivni ntsysv). A to ze mezi skripty nejsou definovane zavislosti a spravne poradi je vynuceno jejich ocislovanim je take zoufalost. Jediny rozumny system ktery jsem zatim pouzival je na NetBSD (tusim ze to ted prejali i ve FreeBSD). Jeste lepsi se mi to zdalo ve Windows NT, ale s tim nemam tak velke zkusenosti (mohl by nekdo komentovat?)

Jinak souhlasim s tim ze nema smysl porovnavat Linux s Net/FreeBSD, pouze Linux s jadrem BSD ci Debian/RedHat/... s Net/FreeBSD. Ti, kdoz tvrdi, ze Free/NetBSD je na rozdil od Linuxu konzistentni, by by se divili kdyby zkusili Debian GNU/BSD :-)

Co tak skusit update-rc.d ? je to skoro to iste ako chkconfig ... Nekde som videl aj link na chkconfig pre Debiana ... Je to len kozmeticka zalezitost ale aj mne to vadi pretoze zvazujem odchod z RH a prechod na debiho a dlhorocny zvyk je zelezna kosela ...

este by som doplnil. K ntsysv je alternativa: rcconf

To: pc
V NetBSD běží po default instalaci akorát inetd(v inetd.conf je vše comment out). Když dáš 'netstat -vat' - ticho po pěšině.
Ad WinNT: myslíš services?
Co myslíš tím Debian GNU/BSD? Já z linux. distribucí znám blíže akorát Slackware(na tom jsem v '97 začínal) a RedHat(později ve firmě). Dál jsem zkoušel třeba Mandrake, ale ten mě zvlášť neučaroval. Co je na Debian GNU z hlediska konzistence lepší oproti BSD?

> V NetBSD běží po default instalaci akorát inetd(v
> inetd.conf je vše comment out). Když dáš
> 'netstat -vat' - ticho po pěšině.

Ja vim - to se mi prave na NetBSD libi :-)

> Ad WinNT: myslíš services?

Jo. Ty maji oproti NetBSD tu vyhodu, ze je v nich lepe dotazene automaticke reseni zavislosti. V NetBSD kdyz chci povolit nejakou sluzbu, tak se musim podivat na jakych sluzbach zavisi a povolit je taky. To se v NT resi automaticky. Rovnez kdyz je nejaka sluzba vypnuta a ja ji chci rucne spustit, protoze ji na chvili potrebuju, a dam /etc/rc.d/foo start, tak se nespusti. Musim dat forcestart, ale to dela tusim neco trochu jineho, a nespusti to sluzby na kterych ta moje zavisi.

Ad Debian GNU/BSD: to je proste Debian, ktery ma misto Linuxu kernel z NetBSD nebo FreeBSD. Stejne jako je Debian GNU/Hurd ktery ma misto Linuxu Hurd.
Viz http://www.debian.org/ports/#nonlinux .

Co je na Debianu z hlediska konzistence lepsi nez na BSD? Predevsim je cely system zalozen na baliccich. V NetBSD (pokud vim plati to stejnou merou i pro Free/Open) je rozdeleni na zakladni system a aplikacni balicky (ports ci pkgsrc). To je sice pekne, ale to, ze je system spravovan odlisne od aplikacnich balicku uz tak pekne neni. System je distribuovan v tarech a upgrade se resi proste roztarovanim novych do stareho systemu a naslednym smazanim "zastaralych" souboru, ktere jsou v nejakem seznamu. Technologie balicku mi prijde propracovanejsi a je dobre, ze linuxove distribuce ji pouzivaji na spravu uplne vseho.

Dale je v Debianu podle me lepe propracovana kompatibilita sdilenych knihoven. Knihovny jsou v baliccich ktere maji ve svem jmenu zakodovane cislo verze (soname). Takze muze byt vice verzi knihovny nainstalovano a kazdy program zavisi na te kterou potrebuje.

U NetBSD mam dojem, ze kdyz se v pkgsrc obevi nova binarne nekompatibilni verze napr. knihovny libpng, musi se vsechny balicky ji pouzivajici rekompilovat.

Pro knihovny v zakladnim systemu je to tusim tak, ze se po upgradu nechavaji zastarale knihovny, pro pripad, ze by je nahodou nekdo potreboval, tudiz se v systemu postupne hromadi bordel. Naproti tomu v Debianu neni probrem udelat balicek se zastaralou verzi knihovny, ktery se nainstaluje, jen kdyz je potreba.

mozna bysme meli tuto diskusi presunout na regional-cs :-)

Naprosto souhlasim - debian ma init scripty hrozne neprehledny, s NetBSD se to neda srovnat. Ac pracuji s linuxem od roku 1996 tak se mi nektere veci lepe nastavuji v NetBSD - proste vsechno najdu na jednom miste, mam to bohate okomentovane a nemusim hned hledat prislusny oddil manualu. Jinak Linux nijak nehanim a souhlasim ze pro urcita pouziti je lepsi nez NetBSD, ale plati to i naopak.

V techhle clancich se zameruji pouze na kernel (asi se to melo jmenovat "Porovnani jader systemu"), takze se takovymi vecmi nebudu zabyvat vubec. V linuxu (RedHat 4.2, stale ho pouzivam) jsem nahradil systemove skripty (takovy ty adresare pro kazdy runlevel) tremi skripty (rc.sysinit, rc.3, rc.6) ktere proste pusti vsecky daemony, co jsou potreba, (a rc.6 je zase killne), takze mi to bootuje rychleji. Taky se to podle meho nazoru lepe spravuje.

Co se tyce ipv6, jadra jsou na tom asi stejne, s aplikacemi nemam zkusenosti (stejne mam pocit, ze ipv6 v soucasne dobe na nic neni, nebot na nem vetsina serveru neni).

Tohle je samozrejme sqele a lze tim dosahnout superrychlych bootu. Akorat je to sqele na sve pracovni stanici, ale daleko mene pokud clovek ma
15+ serveru a 100+ pracovnich stanic s ruznymi konfiguracemi, ktere musi byt schopen spravovat kdokoli z tymu treba 5+ lidi. Pak je lepsi se snazit byt co nejbliz tomu, co nabizi distribuce (a v tomto pripade jsou SysV-style startovaci skripty IMNSHO vyrazne elegantnim resenim).

-Yenya

Srovnavas nesrovnatelne. Zadny operacni system neni dokonaly, nebo bozstvo, na ktere vzhlizis s uctou, jak je krasne pekne ciste napsany. Operacni system se predevsim pouziva, sakra. Tohle je praxe, ne teorie. To, co je tobe sympaticke, muze byt nekomu PEKELNE na obtiz. Ad ipv6: to neni tak uplne pravda. Ad prudeni: Neprud, kravina. Na cem se zaklada tve tvrzeni o ligach? Jedine mozne hodnoceni systemu je "vohovuje mi/splni co od neho cekam"/"nevyhovuje" Takze tvoje pruzeni je jen ciste subjektivni tvuj nazor. Druhy clovek by te sjel s argumentem, ze tvuj BSD nestoji za nic, v porovnani s jeho QNX. A pro jeho cinost je to treba opravdu jediny pouzitelny system. Tech prikladu je vice, takze neprud s tim, ze BSD je to nejlepsi co mame. To NENI, nebyla a nikdy nebude pravda.
-djz

"Nechci prudit, ale BSD je extraliga, zatímco Linux "jen" 1.liga."
...taková tvrzení nemá smysl komentovat.

Také jsem pro porovnání jiných větví (NetBSD, OpenBSD). Nedávno vyšlo na webu (URL jsem zapomněl:-) porovnání výkonu z hlediska parametrů důležitých pro http server(vítěz FreeBSD 5.x před Linuxem 2.6.0). Ani NetBSD si nevedlo špatně. Když se veme v potaz jeho "multiplatformita"... Stejně jako opensource není jen Linux, není BSD jen FreeBSD.

http://bulk.fefe.de/scalability/#newdata

[Nov 1 2003]
I got an email suggesting that I re-check NetBSD. The results are nothing short of astonishing. In two weeks time the NetBSD team made dramatic improvements.
...
NetBSD now has better scalability than FreeBSD.

Linux 2.6 scales O(1) in all benchmarks. Words fail me on how impressive this is.
...
FreeBSD has by far the best performance of the BSDs and it comes close to Linux 2.6.

http://bulk.fefe.de/scalability/

Nevíte někdo, jak by se dal řešit následující problém :

Mám periferii, kterou musím (pokud je aktivní) obsluhovat v pravidelných poměrně krátkých intervalech (cca jednotky ms), přitom výpadek je nežádoucí.
Kdybych (čistě teoreticky - netvrdím že bych to uměl) napsal ovladač a zahrnul ho do kernelu, jak se dá zařídit, aby se tento můj ovladač dostal "k lizu" pokaždé včas ? Dejme tomu že přípustná tolerance intervalu je řádově desítky procent, ale pokud by obsluha přišla řekněme za dvoj- nebo troj-násobek obvyklé doby, mohlo by to dělat problémy.
Šlo by toto zařídit pomocí zmíněného low-latency patche ? Nebo až nastavením pre-emptivního kernelu v 2.6 ? A dalo by se (aspoň teoreticky) nastavit, že moje obsluha má vysokou prioritu a nikdo mě nemá rušit ? Samotné obsluhování je krátké a jednoduché (prakticky jen výstup 1 byte na port), alekdyby mi někdo "sebral pod rukama" CPU, docela by to vadilo.

Na toto pouzijte system, ktery vam to zaruci napr. RTlinux.

S RTAI (http://www.aero.polimi.it/~rtai/) se daj
zaridit i mnohem kratsi intervaly, ale je to trochu slozitejsi :-) . Ale ty jednotky ms by mel s preempt patchem (+ mozna i lowlatency patch) zvladnout i
userspace proces (asi s realtime prioritou). Nekde na webu jsem videl nejaka mereni, ale ted nevim, kde.

Pokud chcete delat ovladac v userspace (nebo v kernelu jako kernel thread), pak je low-latency patch nebo preemptivni kernel potreba. Pokud je ovladac v kernelu na interruptu, tak tyto veci nemaji vliv.

Otazka je, jestli si zarizeni samo rekne o interrupt, nebo je treba pouzivat timer. V pripade timeru je problem, ze timery jde nastavovat minimalne po 10ms. Existuji i patche, ktere meni casovani po 1ms, niz to nejde, protoze by to moc zpomalovalo. Dalsi moznosti je pouziti ovladace "real-time clock", ten by mel umet i nizsi intervaly.

>Existuji i patche, ktere meni casovani po 1ms, niz to nejde, protoze by to moc zpomalovalo.

Cas 10ms je dany historii z dob i386. Podivate-li se do zdrojaku jadra, zjistite ze jsou platformy, kde je cas kratsi. Pri dnesnich vykonech i pro platformu x86 je cas mensi nes 1ms byl pouzitelny. Ja osobne jsem si ho predelal na 1ms (na jednom PPC 50Mhz) a zpomaleni bylo neznatelne.

Na mem pocitaci (Pentium 200) trva obsluha casovaciho interruptu na Linuxu asi 2500 tiku. Z cehoz 400 tiku je ACKnuti interruptu na PICu + overhead procesoru, 600 tiku je zamaskovani a odmaskovani na PICu, zbytek je overhead se softirq, ktere se pokazde vola kvuli moznym timerum (na FreeBSD je tento overhead vyrazne nizsi, nebot to zadne softirq nevola). Kdyz to budete volat kazdou 1ms, sezere to 1% casu (a to nemluve o neprimo zmeritelnem zpomaleni programu zpusobenem vyprazdneni cachi). I 1% je moc. Niz uz to opravdu nejde.

PIC je na sbernici ISA, proto je pristup k nemu pomoci instrukci in a out hodne pomaly a rozhodne se to na lepsich pocitacich nezlepsi --- ISA je porad stejne pomala. Pri pouziti APICu jsou doby trvani vyrazne nizsi.

Jeste v dobe 486tek se pro zpozdeni cca 1 microsec pouzivalo cteni portu 0x20 (PIC), ktery BYL na sbernici ISA. Ale kratce po objeveni 586 se tento PIC prestehoval do chipsetu a tam je k nemu rychlejsi pristup. Me proto prestal fungovat jeden program, ktery generoval presne casovane prubehy - presneji receno na me 486 fungoval, na firemni 586 taky, na zakaznikove 586 ne. Opravil jsem to ctenim registru karty, ktera byla zasunuta do ISY. Ale dnes uz pocitace casto ISU nemaji vubec a pokud ji maji, tak standardni periferie na ni stejne nejsou a mala zpozdeni se delaji upne jinak.

Dakujem za vyborny clanok. Hoci nie som odbornik ani na jadra ani na programovanie, zacina mi byt po precitani clanku este viacej zrejme, ze je tazke, resp. az nemozne vytvorit univerzalny model prace jadra i systemu "najlepsi pre vsetko". Navrh architektury kernelu je a zrejme este dlho bude o tom, najst najlepsiu rovnovahu medzi vykonom, stabilitou, flexibilitou a programatorskym pohodlim. Kazdy navrh ma zrejme svoje slabe a silne stranky, to je skratka vec DIZAJNU. Tu sa koncia argumenty pre flame, skratka lopata je lepsia na prehadzovanie piesku a ryl je lepsi na rylovanie. Daju sa pouzit aj opacne, ale nie je to ono.

Zacinam tiez intuitivne tusit, ze v pripade mikrokernelu bude asi mozne lepsie prisposobovat konfiguraciu jadra konkretnym poziadavkam, ale priznam sa, ze nemam pre toto tvrdenie ziadny teoreticky zaklad. Velmi by som privital obdobny clanok na temu mikrokernel resp. HURD.

těžko můžete očekávat článek o mikrokernelech od lidí, kteří je považují za mrtvou cestu ;-)

Linux a jiné (pokud tím bylo myšleno *BSD) k mikrokernelu rozhodně nesměřují. jádro sice je stále více modularizováno, ale zůstává _monolitické_, jinými slovy ovladač i té nejposlednější periferie si může dovolit totéž co scheduler.

Nespeje. Pockej, krome sedivych/zadnych vlasu se nedockas niceho rozumneho. Jinak, to ze v QNX to nahodou docela uzasne funguje neimplikuje, ze mikrokernel nebude pomalejsi a ze nema vsechny neduhy kterymi trpi mikrokernelove systemy. Moduly v linuxu jsou fajn vec, ale linux tezko kdy bude mikrokernel.
-djz

Mikrokernely mrtvé jsou, na běžných stanicích ani serverech se nepoužívají. Pokud se mnou nesouhlasíte, nainstalujte si Hurd, Qnx, VSTA, L4, T4 nebo jiný mikrokernel na počítač. Mikrokernely mohou být používány tam, kde jsou třeba realtimové aplikace.

Dále třeba v tomhle seriálu bude popsáno, jak se dělá DMA rovnou z page-cache do síťové karty, aby data vůbec neprocházela procesorem --- třeba tohle se v mikrokernelu implementovat nedá --- filesystém, tcp/ip stack a ovladač síťové karty jsou procesy --- zkuste se zamyslet, jaké rozhraní by to chtělo? Rozhodně na to nestačí ono jednoduché send(int id_procesu, char *zpráva, int délka_zprávy).

Moc-moc dobry clanek ...
Ale mam dotaz ... planuje se v Linuxu zmenit to maskovani preruseni ? Tak jak to je popsany v clanku mi nahani strach, jelikoz planuju prejit nan.

pokud v obslužné rutině znovu povolíte přerušení (a většina interrupt handlerů právě toto dělá), je možné ji znovu přerušit. časově kritické části kódu jsou potom mezi spinlocky. vše je v rukou programátora. navíc filosofie "buď všichni nebo nikdo" činí věci krásně jednoduchými, žádné splx braindamage ;-)

btw, jsou architektury, které mají prioritu přerušení pevně danou. a na i386 existuje utilita, která ji umožňuje měnit.

Jedno preruseni muze na Linuxu prerusit jine. Ale zamaskovat se musi vsecky nebo zadne a to je ten problem. Treba pri psani na konzoli. Nikdo neplanuje, ze by s tim neco delal.

Mozna by stalo za to udelat aspon softwarove maskovani vsech preruseni --- misto "cli" tam dat "movl $1, interrupt_mask" a misto "sti" dat "movl $0, interrupt_mask;cmpl $0, interrupt_pending;jnz process_pending_interrupts" --- cli, sti, pushf a popf jsou na procesorech totiz hodne pomale a preruseni se v jadre zakazuji casto.

spl(9) je pomerne elegantni rekl bych... proc vsichni nebo
nikdo kdyz to tak neni :-) (resp. je - pro danou spl uroven,
ale ne globalne). bez spl by tam bylo silene moc zamku...

:-)

úplně na mě dýchla atmosféra přednášek na fi.muni.cz,
že Yenyo, tys to vždycky uměl :-)

Jo to byly časy, to jsme ještě byli mladí ;-)

Je moc příjemné si občas přečíst něco "odbornějšího".

Díky, díky, díky

Nostalgie? Taky tri roky zpatky? ;-)
Ale jo, leti to jako svina ...

Jo Mikulasi to se ti fakt povedlo :) Je to high-quality clanek. Chci se zeptat, kde jsi ty informace o etch vsech operacnich systemech nasbiral?

Informace jsem nasbiral temer vyhradne ctenim zdrojaku. Uz jsem si na to celkem zvykl, ze mi to jde rychle.

A pak že zdrojáky Windows nejsou dostupný... :-)

Vyborny clanok, len skoda ze nevysiel pred rokom ked som pisal diplomovku. Vdaka.

Jen detail,

> Nicméně implementace těchto funkcí je velmi mizerná —
> nevytváří se žádná fronta procesů jako na Linuxu a funkce
> wakeup prochází všechny procesy v systému, aby zjistila,
> který na danou událost čeká.

Presneji (alespon na NetBSD) je to tak, ze system udrzuje
128 front, pri tsleep se cekajici proces zaradi do jedne z
nich podle identifikatoru. Takze se neprochazi vsechny
procesy v systemu, ale jen ty ktere spadly do stejne waitq
tridy. Da se to brat jako hasovaci tabulka podle identu.

> Procházení všech procesů je celkem náročná operace a v
> tomto případě je to zcela zbytečné

Zalezi na tom jak dobra je distribuce toho rozskakovaciho
makra. Nejaky seznam se bude prochazet tak jako tak, jen
tam obcas bude neco navic. Linuxova implementace (jedna
fronta na kazdy wait channel) je asi v zasade lepsi, s ltsleep/wakeup se zas dobre pracuje (staci znat identifikator) a vsechno je na jednom miste...

Teď koukám, že to má i FreeBSD --- při čtení kódu jsem to přehlídl. Takže to není tak strašné, jak jsem si myslel.

Nemohu si odpustit poznámku ke tvrzení
sleep_on - tyhle funkce musí umřít.

Je to nesmysl, spinlok je účinný nástroj, pokud potřebujete synchronizovat přístup k proměnným.
Přístup by neměl trvat déle než jednotky mikrosekund.
Jinak čekající procesor u SMP mrhá výkonem a v případě spinlok_irqsave ohrožujete i včasné přijetí dat.

sleep_on případně v článku nepopsané wait_event je ideální pro čekání na dostupnost dat, událost nebo na vypršení časového přerušení. Využívá čekací fronty, je v Linuxu dobře implementované. Nad ním jsou postaveny všechny vyšší IPC mechanizmy (čekání a buzení). Proto můžete používat v programech select čekat na pakety atd.

Velmi pěkný ale již poněkud starší popis činnosti a principů Linuxového jádra naleznete v knížce

The Linux Kernel by D.A.Rusling

Hyperlinkovanou PDF verzi naleznete na mé stránce

http://cmp.felk.cvut.cz/~pisa/linux/tlk-0.8-3.pdf

wait_event volá add_wait_queue, pak otestuje podmínku a případně zavolá schedule podobně, jak jsem to tam popsal (ale nenapsal jsem, že to může dělat wait_event). wait_event se v jádře ani moc nepoužívá, většinou je to tam rozepsané (nenapadá mě proč, mohlo by to být čistší než s použitím stávajícího add_wait_queue a schedule; možná proto, že o něm nikdo neví).

sleep_on jde použít pouze pod big kernel lockem, jinak ne, neboť je v něm race (podmínka nastane po otestování ale před sleep_on). Na čekání na přerušení nejde sleep_on ze stejného důvodu použít vůbec.

Duvod je samozrejme ten ze wait_event() je podstatne novejsi rozhrani nez add_wait_queue(). Odhaduji ze to je vec Linuxu 2.3 nebo 2.1 zatimco add_wait_queue je vec linuxu 1.0. Pokud dobre vidim do vyvoje veci, kde se tohle nejcasteji pouziva (= drivery) tak driver se vetsinou pise tak, ze nekdo nahodny ma kus HW ke kteremu pise (svuj prvni) driver. Cili se podiva do vedlejsich driveru (ja jsem treba zkoumal ISA DMA z aha1542.c) a zkopiruje postupy tam pouzite. Pokud nekdo chce zavest "lepsi" rozhrani, musi projit kernel a opravit vyskyty "starych" rozhrani tam kde to vsichni od sebe navzajem zkopirovali. Vetsinou se to tak deje, v tomhle pripade zrejme ne (protoze to neni jen trivialni globalni nahrada retezcu).

-Yenya

sleep_on musí umřít! pokud mě chcete přesvědčit o opaku, odstraňte všechna chybná použití z jádra. tak za měsíc se zase ukažte ;-). nebudu se opakovat a opakovat jiné. autor článku ostatně vysvětluje úskalí s jejím použitím spojená. btw, "Používání funkce sleep_on je ve většině případů nevhodné"... Proti této větě mám výhrady - _vhodné_ použití této funkce totiž neexistuje. v článku je také vysvětleno, jak to dělat správně

Velmi pekny clanok na tuto temu bol v Softvarovych Novinach - myslim ze v cisle 9 alebo 10...

nejdrive nekolik citaci....

[..] Chcem citat taketo clanky kazdy den :))))
Skvele, skvele a este raz skvele!!! [..]


[..] Jinak samozrejme OK, po dlouhe dobe clanek na rootu ktery se da cist (a ne jen proletet prvni vety odstavcu, jestli tam nahodou neni vyhled na nejakou novou informaci). [..]

Maji byt skutecne vsechny prispevky takove? Netusil jsem, ze siroka verejnost zajimajici se o vypocetni techniku a zejmena unixy by se rada vyzivala v tom, jake typy preruseni v tom kterem jadre maji jake vyhody?
Vetsina tech, kteri to zde komentuji, jsou stejne jako autor studenti (aktivni nebo drivejsi) nejakeho informatk-oboru. Tento clanek zde ma samozrejme misto, ale v teoreticke sekci pratel informatiky odpovidajicich fakult uk a mu.

Pro nas obycejne smrtelniky, kteri hned nedostanou orgasmus, kdyz se vyvola scheduler, by zde mohlo stat, jakemu os dat za jakych okrajovych podminek prednost.
Eventuelne by zde mohl autor naznacit, jaky prakticky dopad jeho teoreticke vyvody maji. (0.3% , 10%, 90%)

Ano, jsem sokovan, kdyz zde mohu pozorovat budouci spicku informatiky se svou zamilovanosti k detailu bez celkoveho pohledu na vec. Ale my prosti obcane mame prece narok na prakticke vysledky vyzkumne cinnosti a ne pouze na popisne prace, jak to bylo za komunismu bezne. Nejen ze to platime na danich, zanedlouho budeme jako zeme bez zdroju na Vas zavisli - tak se proboha zammyslete.

dej si facku a bez spat :-)

týýý brďo, člověk přijde z dílny, koukne na net a tohle... teoritické vývody tohoto typu dopad nemají a mít nebudou. je to popis současné implementace - která již praktický dopad má. reps. ano, dopad by snad mohly mít v případě, že by nějaký programátor zabývající se jádrem linuxu shledal nějakou implementaci v bsd lepší (nebo naopak) a ten "svůj" systém poněkud vylepšil, aby, pokud možno, byla jeho implementace zase lepší. pokud zařídíte, že se část peněz, které platíte na daních přesune do mé kapsy, rád vám nějaký ten ovladač naprogramuji, případně nějakou tu existující chybičku opravím ;-). nejsem sice informatik, ale třeba vám to bude stačit. zkrátka se smiřte s tím, že tyhle systémy vznikly jako dílo pro radost a tak budou lidé dál dělat co je baví a opravovat, co je pálí.

Super clanek.

Ten nadpis ale je trochu matouci - puvodne jsem to nechtel cist, ze to bude nejaky flamebait, ale kdyz jsem clanek otevrel, okamzite me zaujal.

Tesim se na pokracovani.

Mam dva vsetetecne dotazy.

Mam na notebooku Linux 2.6.0 a FreeBSD 5.1 ktere skutecnce je rychlejsi a lepe reaguje na zatizeni nez Linux, coz je asi popsanym zpusobem obsluhy IRQ. Proc kdyz to tedy vsichni vi, ze se to neni idealni reseni, se nezvoli jine? Je to principielni problem to zmenit nebo se na to proste kasle?

Jak je to z IRQ obsluhou v FreeBSD 5.x?

Ta větší živost FreeBSD je asi způsobena spíš systémem virtuální paměti než zpracováváním přerušení. Kvalitnější zpracovávání přerušení by se projevilo, kdyby na tom běžel současně třeba router a ještě to bylo aplikačně vytížené.

V Linuxu se už nic moc lepšího udělat nedá --- kdyby se to začalo přepisovat, nadělá se v ovladačích spousta race-conditionů, které půjdou velmi těžko chytat.

ja mam na mysli treba pusteni prekladace pri prehravani mp3 s otevrenymi 1000x dalsimi aplikacemi typu gnome

pritom jde o to, ze pouzivam nejakych 100M ze swapu, u BSD (stejne jako treba u SUNu ktery pouzivam v praci) se v podstate nepozna kdy system swapuje a jak moc toho je na swapu, u Linuxu je to cim vic na swapu tim pomalejsi system.

Jo takze prepsat by to v principu slo, ale ve skutecnosti nejde.:)

Ta větší rychlost se swapem bude spíš způsobena algoritmem na výměnu stránek, ne způsobem zpracovávání přerušení.

U přehrávání MP3 záleží na typu zvukové karty --- pokud má člověk blbou kartu (jako třeba já mám CS4232), tak je malá latence přerušení potřeba.

Zdrawim,
muze mi nekdo vysvetlit, proc by se recenze na MDK nemely objevovat na root.cz? Ja vim, ze MDK je system pro zacatecniky, nenarocne uzivatele a ja nevim pro jake pouziti ani pro koho. Zatim toho v linuxu moc neumim a momentalne pouzivam Slack, ale na MDK jsem zacinal(ted dekuju za skveleho Slacka).

Ale to jsem trochu odbocil. Jak jsem napsal, na MDK jsem zacinal a lidem, kteri si chteji linux "osahat" nedoporucim asi nic jineho. Navic jsem myslel, ze root.cz je o vsem open-source a vubec o UNIXu a linuxu. Clanek porovnani Linuxu a FreeBSD mi sice moc nerika, protoze se o vyvoj OS nezajimam, ale rad si ho prectu, protoze se mi rozsiri znalosti. Hadky v prvnich komentarich clanku jsou pro me opravdu nepochopitelne a tezko si dokazu predstavit, ze je napsali lide, kteri maji po skole(nekteri po VS) a pracuji v tomto oboru.

Chvalim clanek a pokud mi nekdo posle vysvetleni, dekuji predem.

lnx_bfu

Tím bych se moc netrápil.

Ty komentáře pocházejí od skupiny fanatiků, který se snažej potlačit jakýkoliv realistický, nebo nedejbože kritický názor na předmět jejich zbožňování.

a aby me tu nekdo nekamenoval, jak muzu chvalit slack, kdyz jsou urcite lespi(verim ze jsou) distri, tak bych chtel podotknout, ze jsem se zatim k nicemu jinemu nedostal. Proste Slack se mi libi vic nez MDK.
Asi jsem take v predchozim komentari zapomnel podotknout, ze i kdyz MDK uz nepouzivam(a ani se k tomu nechystam(ne v blizke dobe)), tak se rad podivam, co je jinde noveho. Proto by se tu mely takove clanky objevovat. A je to snad o tom, co autor napise. Kdyz se nekomu nelibi, ze je tu serial o MDK, tak at ho proste necte.

btw> srovnani Linux vs FreeBSD je skvele! jsem o neco chytrejsi, mene lamovatejsi a lituji, ze v nekterych pripadech nemam BSD ;oP