Perl 6 - the future is here, just unevenly distributed

IRC log for #divine, 2017-03-14

| Channels | #divine index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
02:48 ilbot3 joined #divine
02:48 Topic for #divine is now DIVINE | http://divine.fi.muni.cz | http://irclog.perlgeek.de/divine/
07:49 xstill_ joined #divine
09:37 yaqwsx Koncepční otázka - provolávání syscallů do hostovaného systému - separé konfigurace DiOSu nebo by mělo být možné zapnout v každé konfiguraci?
09:39 xstill_ co jsou teď konfigurace?
09:49 yaqwsx To je ta věc, kterou implementuji. Tzn. aby DiOS mohl běžet se single threaded schedulerem, bez VFS apod.
10:09 xstill_ jo já vím, že to implementuješ, šlo i o to udělat si představu co tam má být
10:10 yaqwsx Jo takhle. Ok poslední verze, na které jsme se domluvili je ta, že v optu předáš configuration:standard, configuration:minimal nebo např. configuration:svcomp. Konfigurace jsou hard-coded dopředu, poskytují vlastní implementaci stavu (naskládající si do stavu jen to nejnutnější), syscally jsou implementované jako metody prvků stavu.
10:18 xstill_ jako pokud v minimal není VFS tak by mi dávalo smysl aby passtrough byla anternativa k standard (tj. další konfigurace)
10:27 yaqwsx pasthrough se týká jenom VFS nebo je v plánu, že by se týkalo i něčeho jiného?
10:29 yaqwsx Pokud se týká jenom VFS, tak mi dává smysl mít pro každou konfiguraci možnost zapnout passthroug
10:29 xstill_ to je právě otázka, dávalo by možná smysl ho mít i u další syscallů, jenže tam se pak dostáváš k tomu, že potřebuješ být schpný rozlišit jestli ten syscall směřuje na něco uvnitř nebo venku (třeba takový kill by mohl dávat smysl na obojí) a co teprve kdybychom chtěli moct posílat signály z venku do DIVINE
10:30 xstill_ no to mi právě nedává, pokud se týká VFS tak má smysl jen jako alternativa k instanícm co mají VFS
10:30 yaqwsx Proč to nedává smysl? Pustím si instanci bez VFS a syscally pojedou na passthroug.
10:31 yaqwsx Řeknu to takto - vyrobit konfiguraci je cca 50 řádků kódu. A dává mi větší smysl to, aby konfigurace byla fixní (včetně passthrough).
10:50 yaqwsx Doufám, že bude mít Katka dobrou náladu, chystám se jí hrábnou do VFS :D
11:33 xstill_ jo to dává smysl aby byla fixní
11:34 xstill_ to si vyřiď s ní, dneska tu ani není
12:04 xstill_ hm, člověk pořádně neocení simulátor v DIVINE 4 dokud nevidí jak DIVINE 3 na monitor několik minut blije protipříklad
15:11 yaqwsx Na téma mého hloupnutí v Norksu.
15:11 yaqwsx Co dělám špatně?
15:11 yaqwsx http://pastebin.com/MML8Zg7L
15:11 yaqwsx Mám wrapper syscallu implementovaného pomocí metody. A nemůžu narvat struct statfs* do té metody
15:22 xstill_ nemáš nějakým omylem nadefinovaný statfs na něco jiného než struct statfs?
15:22 xstill_ potřeboval bych asi vidět alespoň ještě jak to voláš
15:23 yaqwsx Doufám, že ne. Ale ve FS je možné cokoliv... Zkontroluji to.
15:23 yaqwsx Co myslíš tím kde to volám? Obyčejnou funkci zatím nikde nevolám a tu metodu volám z toho wrapperu.
15:24 xstill_ aha to jsem nepochopil ten kód
15:24 xstill_ to je divný
15:24 yaqwsx Moje chyba. Ten poslední řádek je prototyp, který mám uvedený uvnitř třídy.
15:25 xstill_ ?
15:26 yaqwsx Syscall je po novu metoda, která má hezký prototyp, návratovou hodnotu a všechno. A kolem něj je pro jednotlivé konfiugurace postaven wrapper (funkce, která bere kontext a va_list), která va_list rozbalí a na správnou část kontextu zavolá metodu.
15:31 xstill_ ano, ale nechápu co jsi psat teď s tím prototypem
15:32 yaqwsx Toto je prototyp metody, který skutečně implementuje syscall: int fstatfs( int * err, int fd, struct statfs * buf );
15:34 xstill_ pořád nechápu co jsi se snažil říct tím "16:24 < yaqwsx> Moje chyba. Ten poslední řádek je prototyp, který mám uvedený uvnitř třídy."
15:35 yaqwsx To byla rekace na <xstill_> aha to jsem nepochopil ten kód
15:35 xstill_ aha
15:35 yaqwsx Myslím, že netřeba řešit. Ještě se zkusím zbavit auta a uvést typ explicitně.
15:39 yaqwsx Ha! error: cannot initialize a parameter of type 'struct statfs *' (aka '__dios::fs::statfs *') with an lvalue of type 'struct statfs *' (aka 'statfs *')
15:58 yaqwsx Co s monitory? Monitory jsou teď závislé na typu stavu (berou ho jako argument). Aby monitor byl schopen procházet stav, potřebuje jeho typ. Jak to vyřešit? Šablonovat monitory? Tzn. uživatel dodá monitor jako šablonu?
15:58 yaqwsx Nepřijde mi to jako elegantní řešení.
15:59 xstill_ to mi nepříjde moc dobré, obvzlášť pokud někdy chceme mít monitory v C
16:00 xstill_ co ten monitor od stavu potřebuje?
16:00 yaqwsx Můžou brát void pointer, ale to z bláta do louže.
16:00 yaqwsx To popravdě nevím.
16:00 xstill_ to je horší, protože ani nevíš kde v tom void pointru něco hledat
16:00 xstill_ tak základní monitor (pro LTL) bude potřebovat jen mít nějaké místo kam si může ukládat svůj stav
16:01 yaqwsx Hypoteticky mu jde hlavně o paměť programu. Takže globální proměnné + rámce vláken?
16:01 xstill_ ano to by mohl taky chtít
16:01 xstill_ na to ale už máme syscally (minimálně na vlákna) takž e to nemusí (a neměl by podle mě) číst ze stavu
16:01 xstill_ jen teda syscall nejde volat z monitoru asi, protože monitor běží v DiOSu, že?
16:02 xstill_ což možná časem budeme chtít taky změnit
16:02 yaqwsx Hehe, momentálně ale v kernelu nemůžeš volat syscally.
16:02 xstill_ ideálně by měl asi běžet v samostntené pseudo-procesu
16:03 yaqwsx Fuh, nebude to velký overhead?
16:03 xstill_ no ale můžeš volat to co je implementuje, stejně zatím asi nemáme použití pro monitory co to budou dělat a až budeme mít tak bude potřeba řešit i procesy
16:03 xstill_ co bude overhead?
16:03 yaqwsx Být pseudoprocess a na každý syscall skákat do scheduleru.
16:03 yaqwsx Ok, můžeš volat implementace přímo - to nic nemění na to, že potřebuješ znát typ Kontextu.
16:04 yaqwsx Leda kdyby byl monitor šablonovaný a dostal jako parametr objekt, který umí ze stavu vytáhnout jednotlivé komponenty.
16:05 yaqwsx Na nich potom můžeš přímo volat implementace syscallů.
16:05 xstill_ hm, to je pravda, že to by bylo dražší, ale bylo by to čistší, monitor podle mě nemá co měnit něco DiOSu ve stavu (kromě svého stavu) a když běží v jádře tak může
16:05 xstill_ ale to není tak podstatné
16:06 xstill_ no a kde syscall vezme typ kontextu? ten ho potřebuje taky
16:07 yaqwsx A jo, to neudělám. Leda nějakou hnusárnou, kdy si budu propagovat z initu název konfigurace ven.
16:07 yaqwsx Kdyby ale ten Getter měl virtuální metody...
16:07 yaqwsx ... tak jsi vlastně stejně v háji, až vyměniš např. scheduler.
16:09 xstill_ no ne, to fakt musí být ten stejný problém jako zavolat syscall, taky nějak potřebuješ vědět jakého typu je kontext
16:09 yaqwsx Nepotřebuji - mám tabulku syscallů.
16:09 yaqwsx A v initu nahodím tu správnou.
16:09 xstill_ a ta obsahuje pointry na funkce, které berou kontext správným typem?
16:10 yaqwsx jj
16:10 xstill_ tak úplně stejně může k částem stavu, ke kterým to dává smysl přistupovat monitor
16:10 xstill_ stejně nechceš aby si každý monitor implementovat sám procházení kontextu, protože se pak všechny rozdrbou když změníš kontext
16:11 yaqwsx Takže bude třeba vyrobit API pro monitory.
16:11 xstill_ ano, to by mi dávalo smysl, takže monitor musí mít jen svůj stav (nějak umístěný v kontextu, ale nemusí vědět jak) a monitor-syscally (které zatím asi ani nepotřebujeme nutně)
16:12 yaqwsx Ok, to dává smysl. Ok to nebude problém vyrobit. Děkuji za rychlou konzultaci.
16:13 xstill_ nemáš zač
16:17 mornfall mně se poslední dobou zdá, že nejlepší by bylo aby monitor běžel v kontextu toho procesu který ho zaregistroval
16:18 mornfall některý vlastnosti se budou stejně faktorizovat přes procesy a tam je to jedno
16:18 mornfall a ty který ne, aby to fungovalo civilizovaně, budou chtít nějakou formu RPC spíš než procházet stav
16:19 mornfall pak můžou mimo jiné na globální data toho procesu odkazovat přímo a nemusí skrz metadata
16:23 yaqwsx Ale i přesto mi stále dává smysl aby komunikoval přes "monitor syscally"
16:23 mornfall s kým?
16:23 yaqwsx Aby byl schopen zjišťovat informace o stavu.
16:24 mornfall potřebuje maximálně tak enumerovat procesy
16:24 mornfall no nakonec možná ani to ne
16:25 yaqwsx Ok, jak si sáhne na globální proměnné?
16:25 mornfall ono zatím teda není jasný jak přesně budou procesový kontextu fungovat, ale to co určitě nepůjde je volat funkce z jinýho procesu bez přepnutí kontextu
16:25 yaqwsx ...jo z registru.
16:25 mornfall kontexty*
16:28 xstill_ mornfall: co je execution v job tabulce statistik?
16:28 xstill_ s/statistik/benchmarků/
16:29 mornfall ono to je složitější, když je monitor součástí nějaké binárky, tak musí běžet s konstantama té stejné binárky, a jediná rozumná možnost jak to zaručit je že poběží v tom procesu kterej ho registroval
16:29 mornfall pokud by byl součástí kernelu tak s konstantama kernelu
16:29 mornfall xstill_: execution integer references execution( id ),
16:32 xstill_ aha jo a to si nějak zhmotní log
16:32 mornfall ne, to zhmotní Run::execute
16:32 mornfall 89     nanodbc::statement exec( _conn, "update job set execution = ? where id = ?" );
16:33 mornfall logger o job nic neví
16:33 xstill_ no ale execution zhmotní Run::execute to jen propojí
16:33 mornfall jistě
16:34 mornfall execution je věc logu, job je věc divbench-e
16:35 mornfall (divbench se jen logu zeptá na execution id a vyplní to v job-u)
16:35 xstill_ no jisté to je tak když víš jak to funguje, ale přijít na to znamená číst paralelně 4 soubory a definici databáze
16:39 yaqwsx mornfall: Krátký report o modularizaci DiOSu: Už to je skoro hotové, jen je třeba ještě překlopit VFS do nového stylu. A VFS má fakt spoustu syscallů :/
16:40 mornfall každopádně pokud jde o passthrough, tak se to určitě netýká jen VFS
16:41 mornfall a pokud jde o otázky typu jestli je něco uvnitř nebo venku, tak to se pozná z překladových tabulek
16:41 mornfall (stejně jako filedeskriptory, které je nutné mapovat)
16:42 mornfall s asynchronníma věcma který jdou z venčí dovnitř to je horší, zejména teda příjem signálů
16:43 mornfall stejně tak blokující syscally je potřeba nějak řešit, v passthrough módu asi bude muset každý dios-ový vlákno mít odpovídající divinový vlákno
16:45 mornfall (nebo teda pokud jde o pidy, v passthrough módu asi bude nutný aby diosový pid-y nespadaly do rozsahu používaného hostem, protože si ten debugovaný proces může přečíst nějakej pidfile a zavolat na to kill)
16:46 mornfall no nebo teda ještě jinak :-) ono asi ve skutečnosti nemá smysl aby v passthrough módu existovaly dios-level procesy
16:46 mornfall fork se může taky provolat, jen se musí nějak synchronizovat nahrávání pak
16:47 yaqwsx Ok... to zní celkem komplikovaně :D
16:47 mornfall valgrind na to má docela rozsáhlou mašinerii
16:47 mornfall nikdo neříká že to bude zadarmo :p
16:54 xstill_ to mi zní dost šíleně
17:34 mornfall ono to nebude zas tak zlý
17:34 mornfall největší blbárna bude s filedescriptorama, beztak
17:36 mornfall ale vlákna který jsou zablokovaný syscallem určitě nesmí blokovat zbytek divinu, to by nefungovalo ani trochu
17:36 xstill_ no už jen to, že v každém vlákně bude běžet jeden run, které se budou nějak střídat asi kontrolovaně a pak se to forkne mi zní docela složitě. Ale jo, dává mi to smysl, že je to cesta kterou by to mělo fungovat a jinou teď nevidím.
17:38 mornfall nevim jak to dělá valgrind, druhá možnost je překládat syscally vždy na neblokující, ale to je ve výsledku spíš víc práce než míň
19:12 blurry joined #divine
19:13 blurry mornfall: prosim si nechat vratit patche na prerobenie
20:18 mornfall blurry: jaj
20:19 mornfall blurry: looks good enough to me
20:27 yaqwsx :D :D :D
20:27 divine-next 3 new patches validated [xbaranov]
21:00 divine-buildbot Hey! build divine-next-debug #538 is complete: Failure [finished]

| Channels | #divine index | Today | | Search | Google Search | Plain-Text | summary