OS 4 Nuovo Kernel, scheduler e SMP! Fine retrocompatibilità?

[Raffaele]

ChrisH sul sito di Amigans.net (in un thread riguardante la riscrittura del sistema grafico di Amiga su base Gallium3D) ha postato queste citazioni da una e-mail di Thomas Frieden, che ha avuto il permesso di pubblicare, e che mi sembrano estremamente interessanti (anche se estremamente stringate), sul futuro del kernel di AmigaOS:

it somewhat astonishes me that one of the announcements of AmiWest, namely the fact that OpenGL (in the form of Mesa/Gallium) is currently already in the planning phase and will be the next big field of work for the graphics team was missed by everyone.

To recap what we announced at AmiWest: The current field of work is two-fold (for the core team). Kernel work will include an overhaul of the scheduler (which will include things like scheduling policies on a task by task basis, and SMP). The graphics work will be Mesa/Gallium. The latter will first be ported and put on top of the current system, and in an additional step, will replace the current system (and provide wrapper functionality for the current graphics system).

http://www.amigans.net/modules/newbb/vi ... mpost58607

Cioé detto in parole povere (e tralasciando il porting di Gallium che qui non ci interessa, ma che occupa buona parte dell'attenzione degli sviluppatori), il kernel di AmigaOS subirà una revisione (leggi la frase come: "subirà una quasi totale riscrittura") con modifiche che introdurranno nel kernel le policy di scheduling e il simmetrical multi processing (SMP), che permetterà finalmente ad AmigaOS di girare "spalmato" sui vari core delle nuove CPU, così come il nuovo software Amiga beneficerà anch'esso dell'architettura multicore.

Questo IMHO significa una quasi totale fine della retrocompatibilità all'indietro col vecchio software che, a meno che i Frieden non riusciranno a fare un vero miracolo dovrà poi girare solo emulato.

Secondo me è una cosa buona.

Ho letto nel passato gli articoli scritti dai Frieden sulle loro scelte per introdurre la deframmentazione della memoria RAM e il Paging, e ho trovato molto eleganti le soluzioni adottate, e spero che sia altrettanto elegante la soluzione che hanno scelto per dotare Amiga di queste nuove funzioni del kernel, ma ovviamente il vecchio software non potrà beneficiare del SMP in nessun modo, in quanto non è stato scritto dal principio per sfruttare questa caratteristica, e dovrà girare solo in un emulatore o in una sandbox.

Voi che ne pensate?

[Raffaele]

P.S.

Quando sarà stato integrato l'SMP in AmigaOS, dopo servirà anche un nuovo Software Development Kit, e gli sviluppatori dovranno abituarsi a ragionare e codificare i propri programmi in ragione dell'architettura multicore.

Persone come Andrea credo siano già pronte da adesso a fare il gran salto, ma ci riusciranno tutti i vecchi programmatori Amiga?

[Seiya]

c'è solo una cosa che non viene mai detta: il tempo?

[andres]

Ma se davvero è prevista una profonda revisione del Kernel, con una rottura della retrocompatibilità, ci sarà anche la memoria protetta?

magari il kernel lo riscrive Sassenrath

[clros]

P.S.
[...] gli sviluppatori dovranno abituarsi a ragionare e codificare i propri programmi in ragione dell'architettura multicore.

Perchè??

[TheKaneB]

sono belle parole quelle degli Hyperion's Twins, ma aspettiamo che si concretizzino in codice prima di trarre giudizi sommari basati su voli pindarici e fantasiose ricostruzioni :-)

allo stato attuale c'è un kernel vecchiotto, con un paio di sviluppatori che sostengono di volerlo rimodernare con l'apporto di tecnologie attuali. Mi sta benissimo, ma mi riservo di commentare DOPO l'avvenuta implementazione :-)

[clros]

Questo IMHO significa una quasi totale fine della retrocompatibilità all'indietro col vecchio software che, a meno che i Frieden non riusciranno a fare un vero miracolo dovrà poi girare solo emulato.

Il fatto di avere il supporto SMP non dovrebbe incidere negativamente sulla compatibilità dei programmi vecchi...
Forse mi sfugge qualcosa, ma non mi sembra che nessuno, su nessun sistema, abbia mai programmato tenendo conto di come l'OS sottostante distribuisce i processi o i thread sulle varie CPU/core..
Però, gente più fresca di me (TheKaneB - Shinkuro - AfxGroup, ...), potrà darci una risposta

[cdimauro]

E' stato fatto di peggio: http://www.appuntidigitali.it/13130/ami ... sing-asmp/

[TheKaneB]

@clros: sulla carta tutto è possibile, parlare di SMP "in generale" è inutile, perchè la retrocompatibilità è un fattore che dipende dalla particolare implementazione, non dall'SMP di per se (di cui il sistema a processore singolo è una caso particolare, in cui hai N=1 processori).

Dal punto di vista prettamente teorico (perchè al momento restiamo sul teorico), abbiamo la possibilità di eseguire N processi simultaneamente (con N processori logici). Dal punto di vista pratico, semmai arriveremo all'applicazione pratica su ExecNG, potrebbe rompere quasi certamente la compatibilità con il passato, oppure si potrebbe mantenere la compatibilità attuando varie tecniche (sandboxing, emulazione, mutua esclusione, paravirtualizzazione, ricompilazione dinamica, wrapper di Nonna Lina, ecc...)

[ghillo]

Personalmente se si fa un passo cosi' importante per il Kernel ,della retrocompatibilità con i programmi 68K non mi importerebbe molto.
Già adesso i software che uso 68k sono pochi e con l'andare avanti dovrebbero essere soppiantati in toto dagli applicativi PPC, e poi comunque non si esclude l'utilizzo di un emulatore .
Il problema è come si diceva prima è che questa cosa andrebbe fatta nel piu' breve tempo possibile.

[Varthall]

Raffaele, nel testo che hai citato non c'e' il minimo accenno a riscritture quasi totali del kernel, ne' di cambi alla compatibilita' con il vecchio software...

[Raffaele]

Raffaele, nel testo che hai citato non c'e' il minimo accenno a riscritture quasi totali del kernel, ne' di cambi alla compatibilita' con il vecchio software...

Il verbo "To Overhaul" non significa forse "rimaneggiare", e viene usato nel senso più largo di "mettere sottosopra per poi fare qualcosa di altro"?

E questo qualcos'altro non è di solito "riparare", "ricostruire", "rifare"?

No, cioé, spiegami tu, per favore, che altro vuole dire, se non che i Friedens ci vogliono avvertire "stiamo per mettere sottosopra tutto quanto nel Kernel riguarda lo scheduler"?

Se poi i Friedens riescono a dare ad AmigaOS lo scheduling con le policy e il supporto SMP senza deprecare la vecchia struttura kernel e garantire la retrocompatibilità, allora ben venga, ma la vedo difficile.

Se ci riescono sono dei MOSCTRI!

In bocca al lupo ai due fratelloni cloni...

[cdimauro]

http://www.wordreference.com/enit/To+Overhaul

1. overhaul /ˈəʊvəhɔːl/
nome
(of machine) revisione f.;
fig. (of system) riorganizzazione f. , ristrutturazione f.
2. overhaul /ˌəʊvəˈhɔːl/
verbo transitivo
revisionare, aggiustare [car, machine];
fig. riorganizzare [system]
(overtake) sorpassare, superare;
(catch up with) raggiungere [ship, vehicle].

Che non significa rivoltare come un calzino, ma aggiustare, appunto. Dargli una sistemata.

[Raffaele]

http://www.wordreference.com/enit/To+Overhaul

1. overhaul /ˈəʊvəhɔːl/
nome
(of machine) revisione f.;
fig. (of system) riorganizzazione f. , ristrutturazione f.
2. overhaul /ˌəʊvəˈhɔːl/
verbo transitivo
revisionare, aggiustare [car, machine];
fig. riorganizzare [system]
(overtake) sorpassare, superare;
(catch up with) raggiungere [ship, vehicle].

Che non significa rivoltare come un calzino, ma aggiustare, appunto. Dargli una sistemata.

Non si può revisionare una macchina senza smontarla pezzo per pezzo, se capisce l'analogia...

[cdimauro]

Puoi smontare quello che vuoi: contano le MODIFICHE che ci farai, e se si tratta di una revisione non è che la macchina te la trasformano in una Ferrari...