[cdimauro]

Originariamente inviato da xeal
Questo forse sarebbe più semplice (per certi versi) e meno "costoso" (in termini di risorse) da realizzare, anche se richiederebbe un notevole sforzo (nel progettare il tutto) per coordinare le varie emulazioni ed evitare eventuali conflitti (non so, tra programmi, o servizi, che richiedono livelli di priorità superiori a quelli previsti, e magari entrano in conflitto perchè cercano di fare la stessa cosa contemporaneamente "pretendendo" di farla in maniera esclusiva, anche se con un po' di accortezza si potrebbe evitare). Si potrebbero fornire all'applicazione tutte le librerie dell'os di origine, con interfaccia immutata e implementate in modo da richiamare le funzioni "vere" dell'os nativo, prevedendo un meccanismo simile per i servizi "erogati" da applicativi dell'os (ad esempio richiamati in una pipe).

E' esattamente quel che pensavo.

Però, questo sistema implicherebbe un problema di supporto non da poco, anzi due. Il primo relativo ai driver, che, se non reperibili come nativi ed emulati per ogni sistema potrebbero creare davvero dei conflitti, oltre che richiedere uno spreco di memoria (RAM in particolare),

Hum. Non credo: proprio questo modello servirebbe a semplificare e razionalizzare l'uso della RAM, che viene gestita dal s.o. principale. E' chiaro che se ci sono due applicazioni che allocano 1GB di ram a testa, non ci si può far nulla...

anche se si potrebbe ovviare con un driver fittizio associato agli originali che richiama all'occorrenza questo o quel driver trattandoli come overlay mutuamente esclusivi, ma questo inciderebbe negativamente sulle prestazioni, sia per l'emulazione, sia per lo swapping anche continuo.

E' una soluzione che si potrebbe utilizzare all'inizio, data la cronica mancanza di driver, per poi essere abbandonata col tempo...

Il secondo, credo irresolubile, relativo alle specifiche degli os da emulare, pena la non "rimappabilità" delle funzioni di libreria e delle syscall...

E' chiaro che ogni applicazione si trascina anche un "contesto" legato al s.o. da emulare, e che permette di gestire i passaggi delle chiamate dall'applicazione al s.o. nativo, che si occupa di gestire il servizio, emulandone le parti.
Un po' come avviene con Wine, insomma.

Per il resto, si, il meccanismo che hai descritto mi l'ho capito. Però mi sono spiegato male io... :

Allora ho anche capito male io...

Nella mia ipotesi mi riferivo alla 3), aggiungendo qualche accorgimento per cercare di ridurre lo spazio richiesto du disco, e mi chiedevo quanto questi "accorgimenti" potessero incidere sulla velocità, rendendo preferibile la 3) senza compromessi:
a) per ridurre spazio, pensavo di archiviare su disco (compilate per intero) le applicazioni usate più spesso, insieme al kernel, ai driver e ai moduli dell'os, diciamo, "secondari" richiamati più frequentemente, in modo da personalizzare tutto in base alle esigenze dell'utente e all'uso che fa del sistema (dandogli la possibilità di compilare e archiviare tutto o niente);

OK, ho capito. Sì, sarebbe la soluzione migliore in termini prestazionali.

b) per occupare ancora meno spazio, sempre in maniera opzionale, mi chiedevo se non si potesse comprimere il codice compilato, in modo da decomprimerlo direttamente nella RAM durante l'allocazione, eventualmente ricompattando le parti decompresse per evitare frammentazione di istruzioni e dati contigui (sempre in ram), oppure memorizzando (su disco) informazioni su come allocare correttamente i blocchi da decomprimere e/o analizzando le varie parti, eventualmente eseguite subito dopo la decompressione e prima che si decomprimano le successive (una sorta di decompressione jit che sostituisca la compilazione al volo, sperando che si abbia comunque un vantaggio, altrimenti sarebbe inutile).

Mumble. Quest'ultima è una soluzione di compromesso che non mi piace molto.

Preferirei la prima, ossia comprimere l'eseguibile compilato (con qualcosa tipo UPX), ma che poi viene interamente decompresso in memoria al caricamento, ed eseguito a piena velocità.

E' chiaro che l'occupazione di memoria sarebbe consistente, ma dati i costi delle ram e il continuo aumento del taglio con cui vengono venduti i computer, sia l'ipotesi da prendere maggiormente in considerazione...

Insomma, pensavo ad un compromesso tra la 1) e la 3), più veloce della 1) e meno dispendioso di risorse (memoria non volatile) della 3), sperando di non incorrere in un ibrido che condensi i difetti di entrambe le opzioni di utilizzo (tipo la 2).

Ciao

Ti sei spiegato bene, non ti preoccupare.

Ciao