consulenza per un porting...

[jappilas]

nel laboratorio dove devo iniziare la tesi la piattaforma di riferimento è QUESTA COSA che attualmente gira su Win
EW è in pratica un framework e uno scheduler RT, sul il quale si innestano "moduli" di calcolo e visualizzazione che opereranno su flussi di dati in real time...
ora, con l' uscita della rel 4 su Win si sta prendendo in considerazione l' eventualità di effettuare in parallelo un porting su Linux
il che a occhio non sarebbe una banalità per vari motivi
uno dei quali è l' attuale sfruttamento di DirectX media in maniera piuttosto estensiva ...
un altro è il fatto che, da quello che sembra, chi lo sviluppò all' epoca (laureandi di anni passati, nessuno dei quali è più in Italia avendo colto ben altre opportunità d' impiego) progettò il framework e lo scheduler in modo da integrarsi abbastanza col kernel NT e le sue idiosincrasie...

ora, mi piacerebbe sentire pareri/opinioni/consigli/correzioni riguardo la fattibilità e le difficoltà dell' operazione...
soprattutto stante quello che, alcune cose lette riguardo la kernel preemptability, le kernel syscall latencies, lo stato del multithreading e multistreaming (soprattuttto a livello di flussi audio e video) , mi portavano a intuire (magari erratamente)
ciao e grazie

[ilsensine]

Immagini che le DirectX le utilizziate per l'acquisizione a/v, giusto?

[jappilas]

praticamente sì , tutti gli stream audio e video sono DX ...

in passato c' è stato anche "un po' " di MIDI per interfacciarsi con HW vario (guanto virtuale ma anche sincronizzazione e controllo remoto postazione1 -> postazione2 ... insomma "roba" varia ed eventuale )

[ilsensine]

Non vedo grossi problemi allora.
Per il resto, occorrerebbe avere qualche dettaglio più approfindito su come funziona attualmente il sistema.
Posso darvi qualche suggerimento se mi descrivi le situazioni tecniche precise.

Avete intenzione di utilizzare qualche licenza libera per la versione per linux?

[jappilas]

Originariamente inviato da ilsensine
Non vedo grossi problemi allora.
Per il resto, occorrerebbe avere qualche dettaglio più approfindito su come funziona attualmente il sistema.
Posso darvi qualche suggerimento se mi descrivi le situazioni tecniche precise.

allora...l' abbrecchio (E' un abbrecchio, il debug di un modulo che tracciava rettangoli e polilinee mi ha preso un mese... alla fine ho scoperto che era un problema di temporizzazione e anche dopo, fine mi sono rimasti gli incubi che potesse piantarsi in fase di "produzione"... ) per adesso è basato su oggetti DCOM (i moduli)
quelli che si interfacciano con l' esterno "lockano" i driver praticamente in accesso esclusivo nel caso del grabbing, capturing, MIDI e delle porte (INFATTI, a seconda di quello che deve fare, va eseguito da Amministratore... )
quelli che effettuano calcoli "puri" si appoggiano (almeno lo facevano fino alla versione 3) alle IPL e alle OpenCV e quelli di visualizzazione / uscita alle directsound/show/draw (DX 9 required, per questo motivo)
sotto, il framework schedula i processi secondo un real time ""best effort" ...stavo dando un' occhiata all' SDK per cercare do capire cosa permette di fare di preciso, però sembrerebbe che virtualizzi praticamente tutto (wait, semafori, locking...)

il fatto è, sembrerebbe che anche nello staff permanente del laboratorio, (molto esiguo , due persone, una impegnata nel proseguire la ricerca sulla gesture recognition/processing e l' altro impegnato più che altro a seguire gli alunni e i tesisti... tra cui il sottoscritto ) pochi sappiano mettere mano alla base del programma (infatti se fai caso , la ver 4 prevede un redesign/refactoring della "periferia", dell' interfaccia, del set di moduli ... )
che io sappia, il progetto EW > linux è stato più volte proposto e poi abbandonato in quanto ogni volta lo studente ha tentato per il periodo assegnatogli per realizzare il modulo di turno e superare l' esame di PPM, passando poi la palla... e ogni volta lo scoglio sembrava essere la riscrittura della sezione audio e del mutexing ... per quello chiedevo se ci sono cose peculiari e limitazioni da sapere riguardo al kernel ...

c' è anche da dire che tutte le prove erano all' epoca del kernel 2.4...

Avete intenzione di utilizzare qualche licenza libera per la versione per linux?

diciamo che non è deciso...
la licenza attuale per la versione win è praticamente di "distribuzione gratuita" del programma e dell' SDK

se si sviluppasse una versione linux non escludo si possa prendere in considerazione una licenza alternativa ... ma al tempo stesso non posso garantirlo, non dipende (per ora) da me

[ilsensine]

Originariamente inviato da jappilas
allora...l' abbrecchio (... ) per adesso è basato su oggetti DCOM (i moduli)

Puoi darmi una ripassata (o meglio lezione ) sul dcom? Qualcosa di molto sintetico.

quelli che si interfacciano con l' esterno "lockano" i driver praticamente in accesso esclusivo nel caso del grabbing, capturing, MIDI e delle porte (INFATTI, a seconda di quello che deve fare, va eseguito da Amministratore... )

Ha senso. Cosa intendi con "esterno"? Altre macchine?

quelli che effettuano calcoli "puri" si appoggiano (almeno lo facevano fino alla versione 3) alle IPL e alle OpenCV

Le OpenCV sono multipiattaforma, fortunatamente.

e quelli di visualizzazione / uscita alle directsound/show/draw (DX 9 required, per questo motivo)

...e qui va trovata un'alternativa. Ce ne sono diverse.

sotto, il framework schedula i processi secondo un real time ""best effort" ...stavo dando un' occhiata all' SDK per cercare do capire cosa permette di fare di preciso, però sembrerebbe che virtualizzi praticamente tutto (wait, semafori, locking...)

Se virtualizza tutto è un grosso vantaggio.

il fatto è, sembrerebbe che anche nello staff permanente del laboratorio, (molto esiguo , due persone, una impegnata nel proseguire la ricerca sulla gesture recognition/processing e l' altro impegnato più che altro a seguire gli alunni e i tesisti... tra cui il sottoscritto ) pochi sappiano mettere mano alla base del programma (infatti se fai caso , la ver 4 prevede un redesign/refactoring della "periferia", dell' interfaccia, del set di moduli ... )
che io sappia, il progetto EW > linux è stato più volte proposto e poi abbandonato in quanto ogni volta lo studente ha tentato per il periodo assegnatogli per realizzare il modulo di turno e superare l' esame di PPM, passando poi la palla... e ogni volta lo scoglio sembrava essere la riscrittura della sezione audio e del mutexing ...

E' un problema che deve essere affrontato con un design accurato. Non puoi fare un pezzo qui e un pezzo lì.

per quello chiedevo se ci sono cose peculiari e limitazioni da sapere riguardo al kernel ...

C'è poco da sapere, il kernel dovresti vederlo il meno possibile.
L'unica accortezza, se si programmano applicazioni di calcolo parallelo, è una gestione attenta degli sleep/wake up, ma immagino che sotto Windows il problema sia lo stesso. Non è una nota banale, sapessi quanti programmi mal scritti ho visto che facevano orrori del tipo "while(!ready) sched_yield();"
Un settaggio appropriato di strategie di scheduling particolari, se richieste, sono l'unica cosa da valutare.

diciamo che non è deciso...
la licenza attuale per la versione win è praticamente di "distribuzione gratuita" del programma e dell' SDK

Ricorda la BSD originale, con qualche requisito in più. Non male come punto di partenza, ma potete fare di meglio

[jappilas]

...e qui va trovata un'alternativa. Ce ne sono diverse.

intanto dò un' occhio alle sdl...

E' un problema che deve essere affrontato con un design accurato. Non puoi fare un pezzo qui e un pezzo lì.

il che pone come requisito, se si inizia il lavoro, un certo tempo per portare a termine una cosa come Dio comanda... non lo si vedrebbe domani

C'è poco da sapere, il kernel dovresti vederlo il meno possibile.
L'unica accortezza, se si programmano applicazioni di calcolo parallelo, è una gestione attenta degli sleep/wake up, ma immagino che sotto Windows il problema sia lo stesso. Non è una nota banale, sapessi quanti programmi mal scritti ho visto che facevano orrori del tipo "while(!ready) sched_yield();"
Un settaggio appropriato di strategie di scheduling particolari, se richieste, sono l'unica cosa da valutare.

quindi non mi dovrei preoccupare di locking, preemption ... (sto pensando ai thread che eventualmente si smazzeranno periferiche legacy che si ostinano a tenere, l' unica paura è che qualche 'stallo' rischi di far perdere il sincrono a quelli, ad es, di image processing che vanno in parallelo... )
bene bene molto bene

Originariamente inviato da ilsensine Puoi darmi una ripassata (o meglio lezione ) sul dcom? Qualcosa di molto sintetico.

sguap O_o mo' da dove comincio?
magari da CORBA conoscenti che operano su database , j2ee e affini mi confermano affinità di certo livello tra i due standard ...

allora, si vuole che una DLL possa incapsulare un certo oggetto, ed esportare una certa interfaccia, in modo che
- l' interfaccia sia tra l' altro, ereditabile
- l'interfaccia si possa associare univocamente ad un oggetto in modo che più DLL possano coesistere anche se l' interfaccia esportata è affine, e un' applicazione client si appoggi alla giusta versione

da quel poco che ho usato, l' elemento principale che permette ciò è costituito dai CLSID (class ID) / IID (interface ID):
questi vengono usati come identificatori globali per la DLL e la sua interfaccia
(sotto win le librerie vengono registrate con un identificatore globale che mi pare ricicli il CLSID... siccome so che COM è supportato anche macosX per interportabilità...) in modo che il sistema riesca a runtime a determinare quale DLL caricare

ad esempio qui viene esemplificato un programma che usa lo stesso metodo ridefinito in due oggetti diversi, quale chiamare alla pressione di un pulsante viene determinato in base al CLSID passato dai due oggetti passando per la Typelib information

ti chiedo scusa per la mancata esaurienza... sono una schiappa a spiegare, se dovessi insegnare dovrei passare una settimana a preparare una scaletta...

Ha senso. Cosa intendi con "esterno"? Altre macchine?

anche
MIDI (usato un po' per tutto, dalla connessione di periferiche non solo musicali, vedi guanto virtuale usato per acquisire movimenti di un mimo, altre periferiche di motion capturing, ma anche connessione master - slave tra due macchine...) ,
LAN, firewire, microfoni e telecamere (la tesi che probabilmente farò comporterebbe un numero arbitrario di telecamere - da cui acquisire con ricostruzione prospettica i movimenti di soggetti in numero arbitrario...) altri ingressi "vari ed eventuali" (mouse, tastiera e altro... alcuni su interfaccia specifica tipo scheda PCI per il motion capturer...)

[ilsensine]

Originariamente inviato da jappilas
intanto dò un' occhio alle sdl...

Le sdl sono una delle soluzioni, ma hanno una limitazione per quel che riguarda il video. Essendo pensate principalmente per i giochi, consentono di gestire solo un visual (esterno all'applicazione, cioè non "inglobabile" come parte di una finestra di un programma). Se non hai bisogno di più visualizzatori di immagini, può andar bene, altrimenti no.

il che pone come requisito, se si inizia il lavoro, un certo tempo per portare a termine una cosa come Dio comanda... non lo si vedrebbe domani

Quanto tempo hai a disposizione?

quindi non mi dovrei preoccupare di locking, preemption ... (sto pensando ai thread che eventualmente si smazzeranno periferiche legacy che si ostinano a tenere, l' unica paura è che qualche 'stallo' rischi di far perdere il sincrono a quelli, ad es, di image processing che vanno in parallelo... )

Un kernel preemptive ha latenze basse. Ovviamente se incappi in un vecchio driver mal scritto possono esserci dei problemi di latenza per quello specifico driver.

sguap O_o mo' da dove comincio?

La definizione di "com" la conoscevo, era la "d" che mi preoccupava
Ovviamente su linux devi cambiare struttura. Su linux è semplicissimo creare .so (equivalenti alle dll) di classi (ma veramente banale), quindi ti suggerisco questo approccio.

anche
MIDI (usato un po' per tutto, dalla connessione di periferiche non solo musicali, vedi guanto virtuale usato per acquisire movimenti di un mimo, altre periferiche di motion capturing, ma anche connessione master - slave tra due macchine...) ,
LAN, firewire, microfoni e telecamere (la tesi che probabilmente farò comporterebbe un numero arbitrario di telecamere - da cui acquisire con ricostruzione prospettica i movimenti di soggetti in numero arbitrario...) altri ingressi "vari ed eventuali" (mouse, tastiera e altro... alcuni su interfaccia specifica tipo scheda PCI per il motion capturer...)

Occhio ai paperweight senza driver per linux.