Názory k článku Komiks: dokonalý den

Proč? To, co Clock napsal, o tom VT_ACTIVATE i o tom „cli“ v xserveru, je pravda. Na mém psychopatickém systému se grafický videomód nastavuje v kernelu, takže tam takové obtíže nehrozí.

Kde se da tvuj psychopaticky kernel stahnout?

Pres torrenty, az bude mit BLEK. hotovy byznys plan a presvedci investory…

Dal jsem to na http://www.jikos.cz/….7.4.TAR.BZ2

Uz to doslo aj ludom okolo Linuxu, tak sa konecne robi na KMS.

Takze Clock minimalne nema pravdu v tom, ze by ty mplayery jely na tvem systemu pres SVGAlib, ne?

Porovnavat Linux v kombinaci s SVGAlibem (coz je sam o sobe sileny hack nezapadajici do navrhu Linuxu a nikdo ho nepouziva) s resenim, kterym ma modesetting v jadre, je dost nefer. Pokud by chtel Clock srovnavat srovnatelne, tak to porovnava s Linuxem s grafikou pres fbdev.

Mplayer jede na knihovně, která má rozhraní kompatibilní se svgalib, ale nesahá na hardware, místo toho používá syscally mého kernelu (k nastavení videomódu, namapování videoram a volání akcelerátoru).

Ten problém, co Clock popisoval, je, že na Linuxu nemůžeš spolehlivě přistupovat na videokartu a přepínat konzole. Je tam race-condition, že když se konzole přepne v určitém bodě, tak si dva programy budou myslet, že konzoli vlastní. Projevuje se to nejen na svgalib, ale např. i když si člověk pustí dva Xservery a zuřivě mezi nimi přepíná pomocí Ctrl-Alt-Fn. Je to chybné rozhraní Linuxu: viz zde: http://lkml.indiana.edu/….0/1139.html

Odkazovany text ale zminuje trochu jiny problem, ne?

Prvni zminovany problem se ciste tyka bugu v X serveru – nekontrolovana navratova hodnota VT_WAITACTIVE.

Druhy zminovany problem muze zpusobit ze dva programy si budou myslet, ze konzoli vlastni, ale ten se netyka prepinani konzoli, ale spousteni tech programu (a alokace konzole).

Máš pravdu. Ten další a největší problém (který není v tom mailu popsaný) je, že po VT_WAITACTIVE xserevr zavolá VT_SETMODE, čímž si přivlastní konzoli. Jenomže mezi nimi mohl kdokoli přepnout na jinou konzoli.

VT_WAITACTIVE sice počká než někdo danou konzoli neaktivuje, ale nezaručí ti, že je konzole aktivní, protože těsně po návratu VT_WAITACTIVE mohl uživatel přepnout jinam.

Popsané je to např. tady: https://bugs.launchpad.net/…/+bug/290197
http://lists.freedesktop.org/…/028837.html

Jo, tomuhle problemu rozumim. Ale jestli to spravne chapu, tak to je problem tykajici se ciste inicializace tech jednotlivych procesu (a asociovanych VT), nikoliv pak nasledneho prepinani (o kterem se zminoval Clock), ze?

Pokud tomu spravne rozumim, tak kdyz mam nekolik procesu, kazdy chce vlastni VT (a treba kresli do nej pres fbdev) a inicializace vsech techto procesu probehne uspesne, tak kazdy bude mit vlastni VT nastaveny pomoci VT_SETMODE na VT_PROCESS a pri naslednem prepinani sem tam se pouze budou durocovat signaly notifikace o prepnuti a ty potvrzovat pomoci VT_RELDISP a zadny race pri tom nehrozi.

Teď jsem koukal na ty signály a taky je v nich díra:

má to fungovat takhle:
* přepne se na konzoli řízenou procesem, dostane se signál, zaktivuje hardware, potvrdí pomocí ioctl(VT_RELDISP, 2).
* přepne se z konzole řízené procesem, proces dostane signál, proces uklidí hardware a potvrdí pomocí ioctl(VT_RELDIS­P, 1)

bug je v tom, že kernel ten ioctl(VT_RELDISP, 2) ignoruje a pokud je požadavek na přepnutí na jinou konzoli, tak ioctl(VT_RELDISP, 2) považuje jako potvrzení přepnutí (viz drivers/char/vt_i­octl.c … case VT_RELDISP:)

Takže:
* přepne se na konzoli řízenou procesem, proces dostane signál, zaktivuje hardware
* ještě než to proces potvrdí, tak uživatel přepne jinam
* proces to potvrdí pomocí ioctl(VT_RELDISP, 2) a kernel si myslí, že je to potvrzení toho přepnutí jinam
* i kernel i proces si myslí, že vlastní hardware

Další problém máš v tom, že se ti pořadí těch dvou signálů může pomíchat (Linux se je většinou snaži doručovat v pořadí, ale ne vždy).

> pokud je požadavek na přepnutí na jinou konzoli, tak ioctl(VT_RELDISP, 2) považuje jako potvrzení přepnutí (viz drivers/char/vt_i­octl.c … case VT_RELDISP:)

Zrovna tahle chyba by byla trivialni na opravu – staci nahradit ten else (pred ‚complete the switch‘) za ‚else if (arg == 1)‘. Nebo zajistit dusledne ignorovani toho ioctl(VT_RELDISP, 2) uz nekde driv.

> Další problém máš v tom, že se ti pořadí těch dvou signálů může pomíchat (Linux se je většinou snaži doručovat v pořadí, ale ne vždy).

Kterou dvojici signalu mas v tomto pripade na mysli? Myslis v pripade, ze se kernel prepnut na VT a pak pryc od nej, tak by kontrolnimu procesu nejdriv dorucil signal informormujici o pozadavku na prepnuti pryc a teprve potom ho informoval o prepnuti dovnitr? To by bylo blbe.

„staci nahradit ten else (pred 'complete the switch ) za 'else if (arg == 1)“

Ano, to by fungovalo.

„Kterou dvojici signalu mas v tomto pripade na mysli?“

Signál pro přepnutí na konzoli a z konzole.

Ano, pokud se nepodaří alokovat strukturu (je GFP_ATOMIC) a použije se pouze bitová maska, tak se můžou pomíchat.

Správně by se ten signál pro opuštění konzole neměl poslat dřív než proces potvrdí přijetí konzole pomocí ioctl(VT_RELDIS­P, 2).

Kdyz je to tak jednoduchy, proc uz to neni davno opraveny??!
(myslim, ze jeste nekde bude zakopany pes a proto kernel toto nehlida – neresilo se to mozna proto, ze by nastal jinej (vaznejsi) problem, treba by i kratce cekajici aplikace vytuhla. Jinak mam takovy pocit, ze jsem se s timhle jevem uz parkrat setkal osobne a nasledoval restart.)

To mi psycholog taky říkal o těch kyselých hroznech.

Ale (na rozdíl od psychologa) si nemyslím, že by to myšlení mělo být nějak špatné. Ta liška si může říct „hrozny jsou kyselé“ a jít pryč a udělat něco užitečnějšího. Nebo může pořád donekonečna pod tím stromem skákat na hrozny, na které stejně nikdy nedosáhne. První možnost je lepší.

Podobně já, „nedosáhnu-li“ na ženy, tak se o to ani nesnažím a radši budu programovat.

Tvůj přístup mi přijde rozumný. Btw. Ono se může stát, že některý z hroznů může spadnout ze stromu sám, tak proč se zbytečně vysilovat, když můžeš svou energii investovat do užitečnějších věcí. Programuj a možná, že někdy i ten hrozen bude.