Come si invogliano nuovi dev a mettere mani in AROS?

[cdimauro]

• 

No. Le differenze architetturali sono profonde.

dicevo che posix non piaccia sono dettagli

Non per chi deve utilizzarlo per sviluppare software.

perche' di fatto tiene su mezzo mondo di applicazioni

Purtroppo.

chi ha messo su BeOS e poi Haiku queste cose le ha ben considerate

Si sono accodati alla massa...

Lo puoi implementare anche in altri s.o..

ma ti sei mai chiesto perche' sono sono anni che su linux BeFS e' in RO 
e nessun altro OS l'ha mai implementato ?

Perché è un filesystem particolarmente complicato (o ricco di feature), e richiede parecchio tempo per essere implementato correttamente. Un filesystem non è un software come un altro: è codice mission critical, e serve parecchio per la sua scrittura e, soprattutto, testing.

BeFS non è il solo s.o. che, nonostante anni di lavoro, non risulta ancora "perfettamente" implementato. Su Linux sono diversi, da ReiserFS a BTRFS (sì, è quasi stabile, ma non ancora "gold"), per finire al mito di ZFS...

che poi, per praticità, per entrambi si arriva a questa soluzione ibrida.

Che aborrisco. Anche ARIX funziona in maniera similare.

A me BeOS/Haiku piace tantissimo, riguardo POSIX finché è solo un layer di compatibilità e non il layer principale, non ci vedo nulla di male.

Come libreria a parte, che "wrappa" le API native, non c'è problema alcuno.

E poi non avere un layer di compatibilità POSIX implica (aimhé) che una buona parte delle applicazioni è tagliata fuori, se vuoi diffondere l'uso dell'OS è da fare

E' un problema comune, visto che nemmeno Windows ha un layer POSIX, nemmeno come libreria esterna. D'altra parte, anche con tutta la buona volontà che ci potrebbe essere, essere compatibili POSIX non è sempre possibile, a seconda delle caratteristiche del s.o. principale e delle API che offre. Ad esempio né Windows né il s.o. di Amiga hanno / supportano la famigerata fork()...

POSIX, a mio avviso, è un male (assoluto).

[cdimauro]

• 

E' un problema comune, visto che nemmeno Windows ha un layer POSIX, nemmeno come libreria esterna.

Windows è parecchio diffuso però, non hanno bisogno di un layer di compatibilità POSIX

Meno male.

In realtà c'è Interix, ma non credo sia molto utilizzato

E' molto valido, ma è disponibile soltanto con le versioni professionali di Windows. Per cui non puoi tenerne conto / utilizzarle quando devi realizzare il porting di un'applicazione da un sistema POSIX.

[saimon69]

• 

@cdimauro

il layer di compatibilita' POSIX, ancora un altra situazione "uovo o gallina" che si presenta per il port di software: ricordo come fosse stato parzialmente (e malamente) risolto sotto Amiga con la ixemul.library e tutto il software del GeekGadgets CD; se non fosse un passaggio quasi forzato per avere piu' programmi ne farei volentieri a meno, e si e' gia' discusso sia su aros-exec che nella mailing list su ncome espandere il sistema di librerie si da permettere il port di software che usa shared objects ma in un modo piu' compatibile con il modus amighista, e parmi di ricordare Staf opporsi a questo...

[cdimauro]

• 

Staf non lo conosco, ma personalmente sono contrario all'introduzione degli shared object quando dal day one il s.o. di Amiga si fonda sulle librerie. In un articolo di tempo fa avevo suggerito come estendere le librerie per consentire di avere il segmento dati "per task" (dunque privato), ma oltre questa soluzione non ha senso procedere: si snaturerebbe tutto, appiattendosi sulle posizioni di altri s.o..

A me piace ancora il s.o. di Amiga perché ha portato una ventata di novità nell'asfittico panorama (tutti a fossilizzarsi su Unix/POSIX). Mi piace AROS perché si fonda rigorosamente su di esso, ma consente di sperimentare e ricercare (grazie anche al fatto che il nucleo è piccolo, semplice, e leggero).

Nel momento in cui si uniformerà agli altri, perderà il suo fascino e per quanto mi riguarda finirà nel dimenticatoio. Rimarrà solo WinUAE a ricordarmi i vecchi tempi.

Anche per questo non amo le versioni hosted o virtualizzate, tranne per lo sviluppo / smanettamento.

[Allanon]

• 

@dsar, ti ringrazio per avermi riportato alla mente questo interessantissimo os con cui ho avuto qualche sporadico incontro ma mai approfondito come si deve, adesso mi vado a cercare una distribuzione con cui smanettare 

[cdimauro]

• 

Fammi capire: in /dev/vdu_ctrl mandi quei comandi come line, square, ecc., e il driver che gestisce /dev/vdu_ctrl poi li decodifica, controlla se i parametri sono corretti, e procede con l'esecuzione del comando? Dunque abbiamo:
- l'applicazione che deve CODIFICARE il comando e i relativi parametri che devono essere eseguiti;
- l'applicazione che deve spedire il buffer a /dev/vdu_ctrl;
- il device che deve DECOFICARLI e CONTROLLARE che non gli hai mandato ciarpame nello stream;
- il device, alla fine, esegue ciò che gli hai richiesto.

Vedi perché Unix è una cacata pazzesca? A forza di estendere il concetto di "file per modellare / controllare tutto", si creano mostruosità come queste.

Sul s.o. di Amiga, invece:
- l'applicazione passa i parametri del comando/API sui registri;
- invoca l'API dell'apposita libreria;
- la libreria, AL MASSIMO, valida il valore dei parametri, ma poi passa immediatamente a eseguire il comando/API.

Per quanto mi riguarda: http://web.mit.edu/~simsong/www/ugh.pdf

@dsar: come sai, da pascaliano mi piacciono i linguaggi di Wirth, e ai tempi dell'Amiga ero rimasto affascinato da Modula-2 prima e Oberon poi (anche se alcune cose mi hanno fatto un po' storcere il naso). Ma non avevo mai sentito parlare del s.o. Oberon; alcune cose, come quella dei file che hai spiegato, sembrano molto interessanti.

[cdimauro]

• 

Rimane una "trovata" assolutamente inefficiente nell'uso comune. Un po' come quella cacata galattica di X11, che uccide l'accelerazione grafica sui sistemi Unix, se non trovi il modo di aggirarla.

[cdimauro]

• 

Nel primo caso (IRIX) un sistema a librerie sarebbe stato di gran lunga più efficiente.

Nel secondo caso (X11), è l'approccio a essere totalmente sbagliato. Localmente la grafica deve essere gestita al massimo dell'efficienza. SE (e solo se) ti serve lavorare con desktop remoto, metti in piedi un proxy che smista le chiamate alle primitive grafiche dove vuoi.

[Z80Fan]

• 

Si son creati due sotto-discorsi quindi rispondo a punti

1) In Linux, il driver ufficiale NVIDIA è composto da una parte user-mode e da una parte kernel-mode, le quali parlano tra di loro attraverso il device /dev/nvidia0; le prestazioni grafiche sotto Linux son state più volte misurate essere pari se non superiori (comunque di pochi %) a quelle della stessa versione su Windows (i due driver condividono la quasi totalità di codice).
Quindi un sistema del genere non impone "meno efficienza" (sarà anche che probabilmente la generazione dei command buffer avviene in user-mode e la parte kernel si preoccupa solo di fare DMA verso la GPU, quindi già i dati sono in forma di "bufferone di byte").

2) X11 è una cacata, e il fatto che sia usato in sistemi obsoleti o dal lunghissimo supporto non lo giustifica; come architettura andava bene negli anni '80 ma già toccando il millennio era inutilmente inefficiente e pesante. Al giorno d'oggi nessun desktop environment/window system/toolkit usa le primitive di disegno di X ma spediscono direttamente buffer di immagini (inefficientemente, perchè non esegue compressione né manda solo le zone dirty), quindi non regge neanche la scusa che è "network transparent".
L'unico motivo per tenere in vita X è solo quello di usarci le applicazioni troppo vecchie per essere aggiornate, nient'altro.

[cdimauro]

• 

Piccolo appunto sull'1): senza passare da /dev/nvidia0, ma con un sistema a librerie, le prestazioni sarebbero migliori e il consumo di memoria inferiore.

[Z80Fan]

• 

Piccolo appunto sull'1): senza passare da /dev/nvidia0, ma con un sistema a librerie, le prestazioni sarebbero migliori e il consumo di memoria inferiore.

[citation needed]; finchè non si prova non possiamo saperlo.

Anzi, sostengo che, usando un sistema a chiamate a funzione, le prestazioni peggiorerebbero. Ecco su cosa mi baso per dirlo:

• La gestione dell'I/O su file di Linux è estremamente ottimizzata (ci mancherebbe altro), e sopratutto anche per applicazioni in-memory (le pipe non sono altro che file descriptor)
• Son sicuro al 99% che NVIDIA fa tutto il lavoro in user-mode e manda all driver kernel solo i comandi già elaborati e formattati per essere letti dalla GPU (praticamente lato kernel basta avviare e gestire le operazioni di DMA); son ancora più sicuro basandomi sulla recente presentazione dove viene discussa una nuova estensione che hanno introdotto in OpenGL per permettere alle applicazioni di generare "manualmente" le command-list (e ridurre al minimo le draw-call che un'applicazione deve fare ogni frame). Con un'architettura come quella che ho descritto, questa aggiunta è molto più semplice e immediata.

Un sistema formato da chiamate a funzione dirette a una libreria di sistema può venire realizzato in due modi:

• La libreria di sistema è praticamente la libreria grafica (OpenGL diciamo), quindi ogni chiamata a funzione dell'API nell'applicazione deve essere inviata alla libreria di sistema in modo che la gestisca;
• La libreria di sistema si riduce solamente a send_buffer() e receive_buffer() per inviare i comandi direttamente alla GPU, e il driver rimane implementato come uno shared object che viene caricato dall'applicazione.

Nel primo caso, le prestazioni crollerebbero drammaticamente, perchè già adesso il tempo di esecuzione di ogni funzione dell'API grafica è critico; se poi dobbiamo anche introdurre una chiamata a una libreria (che per ragioni di sicurezza e tutto non sarà mappata nello spazio dell'applicazione, e se lo fosse, torneremo nel sistema che già è in uso quindi non cambierebbe nulla), la pesantezza aumenterebbe.
Nel secondo caso, le prestazioni rimarrebbero sempre le stesse, in quanto alla fine non abbiamo fatto altro che rinominare le funzioni read() e write().

[cdimauro]

• 

Piccolo appunto sull'1): senza passare da /dev/nvidia0, ma con un sistema a librerie, le prestazioni sarebbero migliori e il consumo di memoria inferiore.

[citation needed]; finchè non si prova non possiamo saperlo.

Proviamolo.

Anzi, sostengo che, usando un sistema a chiamate a funzione, le prestazioni peggiorerebbero. Ecco su cosa mi baso per dirlo:

• La gestione dell'I/O su file di Linux è estremamente ottimizzata (ci mancherebbe altro), e sopratutto anche per applicazioni in-memory (le pipe non sono altro che file descriptor)

Il fatto che sia ottimizzata su Linux non implica che sia migliore di altri metodi.

• Son sicuro al 99% che NVIDIA fa tutto il lavoro in user-mode e manda all driver kernel solo i comandi già elaborati e formattati per essere letti dalla GPU (praticamente lato kernel basta avviare e gestire le operazioni di DMA);

La stessa identica cosa si può fare anche con una libreria.

son ancora più sicuro basandomi sulla recente presentazione dove viene discussa una nuova estensione che hanno introdotto in OpenGL per permettere alle applicazioni di generare "manualmente" le command-list (e ridurre al minimo le draw-call che un'applicazione deve fare ogni frame). Con un'architettura come quella che ho descritto, questa aggiunta è molto più semplice e immediata.[/li][/list]

Perché non si potrebbe fare altrettanto con una libreria?

Un sistema formato da chiamate a funzione dirette a una libreria di sistema può venire realizzato in due modi:

• La libreria di sistema è praticamente la libreria grafica (OpenGL diciamo), quindi ogni chiamata a funzione dell'API nell'applicazione deve essere inviata alla libreria di sistema in modo che la gestisca;
• La libreria di sistema si riduce solamente a send_buffer() e receive_buffer() per inviare i comandi direttamente alla GPU, e il driver rimane implementato come uno shared object che viene caricato dall'applicazione.

Nel primo caso, le prestazioni crollerebbero drammaticamente, perchè già adesso il tempo di esecuzione di ogni funzione dell'API grafica è critico; se poi dobbiamo anche introdurre una chiamata a una libreria (che per ragioni di sicurezza e tutto non sarà mappata nello spazio dell'applicazione, e se lo fosse, torneremo nel sistema che già è in uso quindi non cambierebbe nulla), la pesantezza aumenterebbe.

Non ho parlato di libreria di sistema, ma di libreria. Dunque perfettamente gestibile in user-space, al costo di:
- una LOAD LibraryBase (solo la prima volta nel caso di chiamate consecutive alla libreria) nel registro usato per memorizzarla;
- una CALL a un certo offset dal registro per eseguire il codice.
Questo in un s.o. Amiga/like, perché c'è la necessità di passare / usare la LibraryBase.

In altri s.o. è possibile, invece, "risolvere" al caricamento della libreria gli indirizzi delle funzioni che sono necessarie all'applicazione, per cui chiamare un'API significa soltanto:
- una CALL PuntatoreAllaAPI (questo su x86/x64; su processori RISC in genere serve una LOAD e una CALL).

Dunque richiamare l'API di una libreria è un'operazione estremamente veloce, di gran lunga più veloce rispetto al meccanismo di:
- codifica dell'operazione da eseguire in un buffer (e quindi ti serve anche memoria allo scopo);
- invocazione della syscall fwrite (dunque passaggio da user a kernel mode: context switch!);
- in base al file handle, il kernel deve capire a quale device deve spedire i parametri della fwrite;
- chiamata al fwrite del device;
- nel caso del device nvidia0, questo deve analizzare il buffer e capire cosa ha scritto l'applicazione. Dunque parsing di uno stream dati -> recupero del codice/opcode del comando invocato & relativi parametri;
- a questo punto viene "invocato" il comando (codice comune all'API della libreria: stesse cose da fare);
- il device restituisce il controllo al kernel;
- il kernel restituisce il controllo all'applicazione (passaggio da kernel a user mode: un altro context switch).

Per quanto possa essere ottimizzato in Linux, tutto ciò rimane decisamente più pesante e complicato da gestire. Una chiamata a libreria è immensamente più semplice.

Nel secondo caso, le prestazioni rimarrebbero sempre le stesse, in quanto alla fine non abbiamo fatto altro che rinominare le funzioni read() e write().

Ma anche no: vedi sopra.

E non abbiamo nemmeno tenuto conto del fatto che per utilizzare /dev/nvidia0, devi aprire un file, e dunque devi eseguire una syscall che il kernel mapperà nell'apposito device, una volta che l'avrà trovato durante il parsing del path passato. Poi servirà allocare un file handle appositamente (dunque allocazione di memoria in kernel space per la struttura interna utilizzata allo scopo).

Non è una dimostrazione formale, ma mio avviso risulta piuttosto chiaro che l'approccio a libreria sia intrinsecamente più efficiente di quello tramite utilizzo di un file "speciale".

[cdimauro]

• 

Il fatto che X11 giri, pure bene in alcuni sistemi, non toglie nulla al fatto che sia una soluzione insensata e inefficiente.

[saimon69]

• 

@cdimauro

E' una risposta WorksForMe[tm]

[cdimauro]

• 

Lo so, e non ho nulla da dire da questo punto vista. Ma da sviluppatore con una certa esperienza mi si torcono le budella quando vedo certe porcate...