NOS, NsaOS :D

[cdimauro]

• 

Sarebbe ottimo poter sfruttare il driver model di Windows, in modo da riciclare paro paro l'intero set di driver.

Impresa molto difficile, ma oggi bisogna fare i conti con la praticità: l'n-esimo s.o. che vuole fare il "fico" proponendo magari un nuovo driver model è da puro suicidio.

P.S. No, per favore, non mi parlate di riciclare il "driver model" di Linux, perché... non esiste. Linux è l'unico s.o. che offre compatibilità a livello di sorgente, quindi niente ABI stabili, e si sarebbe costretti a rincorrere tutte le modifiche che s'inventano.

[AmigaCori]

• 

Sarebbe ottimo poter sfruttare il driver model di Windows, in modo da riciclare paro paro l'intero set di driver.

Impresa molto difficile, ma oggi bisogna fare i conti con la praticità: l'n-esimo s.o. che vuole fare il "fico" proponendo magari un nuovo driver model è da puro suicidio.

No, appunto infatti ho chiesto se ci fosse un modo per sfruttare i driver...non tanto di "Windows" ma scritti per Windows, quindi scritti da chi produce HW che sa per bene come sfruttare il suo HW.
Mi chiedevo se i driver fossero scritti pensando all'OS ad un livello basso od a un livello piu' alto che sia "intercettabile" da un OS che non sia Windows.
Mi provo a spiegare ...mi chiedevo perche' non sia possibile riciclare i driver come si fa con i programmi, cioe' un programma scritto in C (od altri linguaggi) e portabile su tutti quei sistemi che hanno un compilatore per C quindi riprendendo il sorgente C scritto per Windows posso farlo girare, una volta ricompilato, su Linux.
Possono mancare delle librerie su Linux, ma una volta scritte le librerie il programma dovrebbe andare.
Un driver, quindi un programma che descrive l'HW della scheda all'OS, non puo' essere trattato alla stessa stregua?, cioe' non si possono semplicemente scrivere delle parti tipo librerie per NOS lasciando invariato il tutto?.

O forse meglio fare al contrario  :think:  per far girare i driver di Windows di ATI su un altro OS, tralasciando problemi burocratici , come si potrebbe fare?

@clros
Spero che il thread chiarisca un po' a tutti come funzioni e si crei un OS, quindi anche le domande banali vanno piu' che bene cosi' come le domande piu' tecniche pero'...sempre tenendo a mente che debba essere un OS non fine a se stesso ma utilizzabile.
Finora mi pare di capire che la soluzione piu' gettonata esista in parte e sia MOS, cioe' un microkernel con personality, quindi un OS molto minore.

Pero'...se ci pensate...MOS...NOS  :lol:

[TheKaneB]

• 

Il problema dei drivers è che generalmente si mischia la parte business con l'interfaccia verso l'OS. Sono pochi i produttori di driver che rispettano le basilari linee guida del software architecture. Capita spessissimo, infatti, che a scrivere driver ci si mettano gli stessi ingegneri che hanno progettato l'hardware, che non sono tenuti a conoscere in modo approfondito tutti i corretti patterns di programmazione, e ragionano molto "stile microcontroller", con codice scritto un po' alla cacchio e difficilmente mantenibile.

Ravanando sui sorgenti di Linux ne ho viste di cotte e di crude su questo versante.

Tuttavia, grazie all'imposizione di colossi come Microsoft, nel tempo sono nate delle interfacce standard per alcune classi di drivers, ed è possibile prendere un driver (anche binario) e farlo girare su un altro OS semplicemente attaccandogli un wrapper. Questo è il caso delle schede Wifi che rispettano le specifiche NDIS. Per le webcam esistono le specifiche UVC, per mouse, tastiere e joystick esiste lo standard HID, per i pen drive e chiavette USB esiste lo standard USB Mass Storage Device e così via.

Oggi, infatti, gli OS alternativi come Linux hanno tanti driver proprio grazie alla realizzazione di questi standard che semplifica il lavoro di scrittura dei driver, e consente anche la scrittura di drivers generici di buona qualità e portabili. Addirittura, come dicevo, si può usare un driver binario dotandosi di un opportuno wrapper.

Per le VGA esiste il già citato VESA da molto tempo, ma le funzioni di accelerazione 3D sono GPU-dependent e quindi al più si possono riutilizzare i driver open source (una roba tipo Gallium 3D) oppure tentare di creare un wrapper per far girare i driver binari. Questa seconda ipotesi, fattibile in teoria, nella pratica è semi-impossibile perchè i driver video per avere buone prestazioni devono girare in kernel space, e la nostra architettura a microkernel puro introduce parecchio overhead, che andrebbe a peggiorare se usassimo un ulteriore layer di astrazione per tradurre le chiamate Windows (o Linux) in chiamate NOS.
A peggiorare le cose, se usassimo i driver Linux accelerati, dovremmo portarci dietro quel mostro di X11 (o emularne parzialmente la struttura i XServer), che poteva andare bene negli anni '80 con i dumb terminals in rete, ma per un OS di classe desktop è un macigno inutile.

Quindi, come prevedibile, il tasto "driver" è quello che fa più male per un OS hobbistico.

[TheKaneB]

• 

@AmigaCori: la "non portabilità" dei drivers è presto spiegata:

Quando crei un programma in C, se usi solamente la Standard C Library, e al massimo le funzioni POSIX più comuni, sei sicuro di avere un programma portabile perchè hai usato un set standard di funzioni che ogni produttore di compilatori e OS implementa nel proprio framework.

Quano crei un driver in C, la STDLIB e le librerie POSIX non esistono, sono rimpiazzate da funzioni simili interne al kernel stesso. Inolte spesso fai chiamate dirette a funzioni del kernel, che sono specifiche di quel sistema, dal momento che non esiste uno standard universale che dice "i driver devono avere sempre queste N funzioni con questi K parametri".
Ogni kernel ragiona a modo suo, progettato secondo un'architettura diversa, e le operazioni di interfaccia con l'hardware sono diverse. Poi internamente il driver puoi anche lasciarlo uguale, come fa nVidia che ha uno strato di interfaccia verso l'OS molto piccolo, e il 95% del codice rimane identico per tutte le piattaforme.
Molti driver però non sono programmati così bene, e anche se lo fossero dovremmo arrangiarci con il solo formato binario che si interfaccia al driver model di un OS esistente, dovendo quindi creare un wrapper.

I problemi del wrapper potrebbero essere mitigati se si sposta il driver in kernel mode, trasformando quindi il microkernel in un cosiddetto kernel ibrido.

Ecco quindi che NOS si avvicina di più alla struttura di Windows e MacOS X. Su AmigaOS il driver è esterno al microkernel, ma non essendoci separazione degli address spaces, dire "interno/esterno" è molto aleatorio. Infatti potremmo dire tranquillamente che su AmigaOS ogni programma che lanci ha la stessa autorità del kernel, quindi il concetto di segregazione e sicurezza di un microkernel va a donnine allegre... :-)

[Amig4be]

• 

Insomma alla fine uscira' fuori che l'OS "piu' migliore del mondo" e' AOS  :lol:

oppure un buono sconto per andarsi a comprare Seven  :lol:

[cdimauro]

• 

La mia idea era proprio quella di integrare eventualmente i driver "critici" in kernel space. A me sembra un ottimo compromesso.

[TheKaneB]

• 

La mia idea era proprio quella di integrare eventualmente i driver "critici" in kernel space. A me sembra un ottimo compromesso.

Chiaro, ma tu vuoi dargli la soluzione subito! Non vale :-D

Io volevo prima farli bagnare un po', poi smontargli il tutto con feroci critiche e devastanti falle architetturali, e poi dargli lo zuccherino finale con una soluzione di compromesso che abbruttisce la perfezione stilistica accademica del microkernel, ma guadagna di brutto nel mondo terreno dei computer puzzolenti e macinatori di elettroni  :lol:

[cdimauro]

• 

GLOM. Sadico! :?

[TheKaneB]

• 

GLOM. Sadico! :?

Come osi? [fimg=right:2maswj0l]http://i.imgur.com/k0BBj.jpg[/fimg:2maswj0l]

[clros]

• 

Cosa mi dite degli Esokernel e dei "NoKernel"? Apportano reali vantaggi (e di che tipo?) oppure sono solo curiosità accademiche?

@TheKaneB: potresti benissimo fare il docente universitario!

[AmigaCori]

• 

GLOM. Sadico! :?

 :lol:

Arrivare alla soluzione passando per i problemi dovrebbe far capire, anziche' "imporre" il perche' delle cose nella mente dello studente

[AmigaCori]

• 

Cosa mi dite degli Esokernel e dei "NoKernel"? Apportano reali vantaggi (e di che tipo?) oppure sono solo curiosità accademiche?

@TheKaneB: potresti benissimo fare il docente universitario!

IMHO TheKaneB sa molte piu' cose di molti docenti universitari, inoltre, cosa molto importante da' sempr uno sguardo al mondo reale differenziando la teoria dalla pratica, ci vorrebbe un approccio come il suo nell'insegnamento...poi...

Vabbe', basta senno' dopo e' troppo  :lol:

[rebraist]

• 

senza girarci intorno:
aros.
aros con memoria virtuale e protezione della memoria.
+ un wrapper per i driver (a la ndis sotto linux).

[Z80Fan]

• 

Per le VGA esiste il già citato VESA da molto tempo, ma le funzioni di accelerazione 3D sono GPU-dependent e quindi al più si possono riutilizzare i driver open source (una roba tipo Gallium 3D)

Ecco, Gallium3D è una di quelle cose che mi piace molto. Secondo me in futuro, vedendolo anche abbinato a Wayland, può rappresentare una buona opportunità, non solo per Linux, ma anche per i vari OS hobbistici.
Io per il video implementerei proprio questa interfaccia, che ne dite?

C'era anche un progetto chiamato Uniform Driver Interface, che potenzialmente avrebbe portato innumerevoli vantaggi a tutti questi OS free; a quanto pare però è defunto (wiki), anche per colpa di quegli idioti fanatici della FSF. (Sito ufficiale).

[cdimauro]

• 

Se è morto è inutile usarlo. Comunque complimenti a quel fanatico di Stallman: non si smentisce mai.

Gallium non lo vedo come una buona soluzione, visti i pessimi risultati ottenuti dopo anni di lavoro.