Quote:
Originariamente inviato da Z80Fan
No, è qualcosa di più di un link.
Se fosse un normale link (ad esempio /time che punta all'utility per leggere la data), io quando faccio:
Codice:
ifstream file("/time", ios::in);
file = fopen("/time");
e poi leggo dal file,<...> |
e poi cosa fai, parsi il file testuale per ottenere i campi dati? non è molto più semplice ed efficiente invocare una funzione e farti restituire una struttura dati?
Quote:
Mi è venuta una piccola idea, i "file dinamici":
sono file che ci sono sul filesystem ma non hanno dati,
|
secondo me la prima cosa da fare è chiedersi: se sono file che non hanno dati, ha senso che stiano nel filesystem?
la seconda è lasciare da parte il fatto che ciò avvenga su unix, e ancora più su linux (con il kitchen sink che è appunto, /proc), entrare nell' ottica che se anche linux fa qualcosa in un certo modo, può non essere il modo più corretto ( o elegante, o efficiente) di farla (*) e ragionare liberamente dai requisiti ad una soluzione pulita, su cui eventualmente appoggiare in un secondo tempo un sistema di compatibilità, senza vincolarsi in partenza a paradigmi vecchi
*: per dire, su linux va di moda creare programmi gui come frontend per altri programmi con cui interagiscono facendo scraping dell' output (testuale e formattato) che questi producono (già che non possono sapere se dall' altra parte c'è un altro programma -con cui potrebbero più efficientemente scambiare strutture dati - o un essere umano di fronte a una CLI)
che è un modo al tempo stesso anacronistico, inefficiente e fragile (cambia una virgola non gestita dal parser, la comunicazione si rompe) di fare le cose, frutto di una certa mentalità in cui si partiva dal presupposto che l' utilizzo prevalente del sistema fosse da parte di un sysadmin di fronte a una shell, e il riuso del codice avvenisse non tramite librerie ma processi comunicanti, anche per non avere tempo (o voglia) di stare a modularizzare codice di tool console esistenti
discorso analogo per il trasformare qualunque cosa in file ed esporlo nel FS (con la pollution che ne deriva), fatta per consentire un accesso uniforme alle risorse del sistema da script e tool - quando un protocollo unificato per lo scambio di dati strutturati tra processi, e comandi / tool ad hoc per ogni API di sistema ad hoc (in pratica: spostare l' uniformità a un livello al di sopra del kernel), avrebbe praticamente ottenuto lo stesso risultato senza che quei dati fossero esportati nel FS ( anche se ciò avrebbe richiesto una diversa shell e nuovi script)
il tuo sistema è basato sulla stessa concezione?
ora, in pratica i requisiti sono
a) attivare, a richiesta, un programma associato a una certa funzione, senza saperne il nome (quindi disaccoppiare questo dai programmi richiedenti)
b) invocare delle procedure del programma handler di cui sopra (alla fine i messaggi sarebbero usati per quello) e avere indietro i risultati
per la prima si può benissimo evitare di passare per il file system - basta che il sistema implementi un meccanismo ed esporti una api (di base, 3 funzioni - register/create, open/join, call/send), che poi programmi sia server che client useranno, i primi per dichiararsi come handler per una funzione, i secondi per agganciarvisi e mandare messaggi o invocare i metodi ( a seconda di cosa decidi di fare per il punto b);
per quest' ultimo entra in gioco la IPC locale - ora, però, esistono dei sistemi che vanno oltre il limite dei sistemi di IPC ed RPC data based, anche supportati dalla memoria condivisa (perchè questa elimina la necessità di fare copie in memoria tra un buffer e l' altro, ma non quella di fare marshaling formattando nel messaggio gli argomenti e i risultati della chiamata)
http://en.wikipedia.org/wiki/Doors_(computing)
http://pages.cs.wisc.edu/~sschang/OS...ocess/LRPC.htm
http://www.jamesmolloy.co.uk/jimix/index.html
questi, di cui l' ultimo hobbysta (ma di un membro di OSDev.org) usano la memoria condivisa per mappare direttamente gli stack di passaggio, bypassando il marshaling di argomenti E nome/indirizzo del metodo da invocare
inoltre come puoi notare, una costante è l' implementazione mediata dal kernel di un sistema di publish/subscribe che bypassa il file system - e che nel complesso forma un infrastruttura
su cui i servizi locali di livello superiore, anche di sistema come networking e file system, sono costruiti - piuttosto che viceversa