kernel monolitici e microkernel

[lorenzo_ktm]

chi sa darmi una definizione, possibilmente diversa da quella di wikipedia, di kernel monolitico e struttura a microkernel?
grazie in anticipo

[jeremy.83]

Leggendo wikipedia, mi pare sia spiegato abbastanza bene e facilmente, ci sono anche i disegnini

Comunque a grandi linee la più grossa differenza è che i driver risiedono nel kernel tratandosi di monolitico, all'esterno trattandosi di micro.

Il kernel è il livello sw più basso in un sistema. In un monolitico il sw di livelli più alti parlano direttamente al kernel, in un microkernel ci parlano attraverso degli "intermediari" (ad es. i server), attraverso un sistema di comunicazione predefinito, il più famoso dei quali è quello dei messaggi.

Il monolitico si ingrossa o diminuisce, il microkernel rimane più o meno così com'è. Il vantaggio del monolitico è una più veloce ottimizzazione del sistema rispetto a sistemi microkernel, lo svantaggio è che occupa più spazio.

link di wikipedia

[lorenzo_ktm]

fino a qui è tutto chiaro, però mi sembra che non parli molto di vantaggi e svantaggi in termini di stabilità.

[khelidan1980]

Originariamente inviato da lorenzo_ktm

fino a qui è tutto chiaro, però mi sembra che non parli molto di vantaggi e svantaggi in termini di stabilità.

io non parlerei di vantaggi e svantaggi in stabilità,sono due approcci diversi al design di un so,con tutti e due si può arrivare ad un sistema stabile

[lorenzo_ktm]

Originariamente inviato da khelidan1980

io non parlerei di vantaggi e svantaggi in stabilità,sono due approcci diversi al design di un so,con tutti e due si può arrivare ad un sistema stabile

ok quindi la stabilità dipende unicamente dalla progettazione a prescindere dall'architettura?

[khelidan1980]

Originariamente inviato da lorenzo_ktm

ok quindi la stabilità dipende unicamente dalla progettazione a prescindere dall'architettura?

esatto o perlomeno questa è una mia opinione,e dallo scrivere buon codice,la stessa wikipedia fa due esempi di successo,qnx,microkernel,utilizzato nelle centrali nucleari,nello shuttle...linux,bsd monolitici....a proposito qualcuno sa com'è progettato win?

[jeremy.83]

Originariamente inviato da khelidan1980

...a proposito qualcuno sa com'è progettato win?

Caro khelidan, Bruschi non ti ha insegnato nulla???

Poi mica stai facendo la tesi con trentini?

Eccoti qua una bella slide di Win 2000:



Un microkernel ibrido, forse più simile a un monolitico. Secondo me un'accozzaglia! Ho installato oracle ultimamente su xp sp3 del mio portatile e ora il boot è diventato improponibile. Funziona meglio su xp virtualizzato

[khelidan1980]

Originariamente inviato da jeremy.83

Caro khelidan, Bruschi non ti ha insegnato nulla???

Poi mica stai facendo la tesi con trentini?

Eccoti qua una bella slide di Win 2000:



Un microkernel ibrido, forse più simile a un monolitico. Secondo me un'accozzaglia! Ho installato oracle ultimamente su xp sp3 del mio portatile e ora il boot è diventato improponibile. Funziona meglio su xp virtualizzato

Guarda io so lo fatto con Monga non ha mai minimamente accennato a win!Con Trentini sto facendo altro non avevo minimamente intenzione di infognarmi in una cosa cosi ampia per la tesi

Ritornando in topic,grazie per la slide,comunque l'ibrido non è poi così raro,anche il kernel di os x è un ibrido tra micro e kernel monolitico!

Ultimamente mi è ritornato il pallino della progettazione di so e programmazione di sistema,giusto per farmi un po male!!

[arara]

Il kernel NT inizialmente era un microkernel puro con un ottimo design: tutti i servizi giravano in user mode ognuno nel proprio address space, supportava oltre a Win32 anche le interfacce POSIX e OS/2 e girava su x86, PowerPC, Alpha, MIPS.
Per usi commerciali un microkernel puro si è dimostrato troppo inefficiente, quindi per motivi prestazioniali hanno deciso di spostare l'executive in kernel mode ed eliminare il supporto alle interfacce POSIX, OS2 e a tutte le architetture tranne x86.

Il design attuale del kernel NT non ha niente di concettualmente sbagliato. Le critiche che vengono mosse riguardo la presunta instabilita dovuta al fatto di aver spostato alcuni componenti in kernel mode sono molto meno importanti di quello che si vuol far credere.
Per capire come funziona si puo leggere questo libro online:
Microsoft Windows Internals, Fourth Edition, Microsoft Press

Is Windows a Microkernel-Based System?

Although some claim it as such, Windows isn't a microkernel-based operating system in the classic definition of microkernels, where the principal operating system components (such as the memory manager, process manager, and I/O manager) run as separate processes in their own private address spaces, layered on a primitive set of services the microkernel provides. For example, the Carnegie Mellon University Mach operating system, a contemporary example of a microkernel architecture, implements a minimal kernel that comprises thread scheduling, message passing, virtual memory, and device drivers. Everything else, including various APIs, file systems, and networking, runs in user mode. However, commercial implementations of the Mach microkernel operating system typically run at least all file system, networking, and memory management code in kernel mode. The reason is simple: the pure microkernel design is commercially impractical because it's too inefficient.

Does the fact that so much of Windows runs in kernel mode mean that it's more susceptible to crashes than a true microkernel operating system?

Not at all. Consider the following scenario. Suppose the file system code of an operating system has a bug that causes it to crash from time to time. In a traditional operating system, a bug in kernelmode code such as the memory manager or the file system would likely crash the entire operating system. In a pure microkernel operating system, such components run in user mode, so theoretically a bug would simply mean that the component's process exits. But in practical terms, the system would crash because recovering from the failure of such a critical process would likely be impossible.


Is Windows Less Stable with USER and GDI in Kernel Mode?

Some people wondered whether moving this much code into kernel mode would substantially affect system stability. The reason the impact on system stability has been minimal is that prior to Windows NT 4 (and this is still true today), a bug (such as an access violation) in the user-mode Windows subsystem process (Csrss.exe) results in a system crash because the Windows subsystem process was (and still is) a vital process to the running of the system. Because it was the process that contained the data structures that described the windows on the display, the death of that process would kill the user interface. However, even a Windows system operating as a server, with no interactive processes, can't run without this process, because server processes might be using window messaging to drive the internal state of the application. With Windows, an access violation in the same code now running in kernel mode simply crashes the system more quickly, because exceptions in kernel mode result in a system crash.

There is, however, one additional theoretical danger that didn't exist prior to moving the windowing and graphics system into kernel mode. Because this body of code is now running in kernel mode, a bug (such as the use of a bad pointer) could result in corrupting kernel-mode protected data structures. Prior to Windows NT 4, such references would have caused an access violation because kernel-mode pages aren't writable from user mode. But a system crash would have then resulted, as described earlier. With the code now running in kernel mode, a bad pointer reference that caused a write operation to some kernel-mode page might not immediately cause a system crash, but if it corrupted some data structure, a crash would likely result soon after. There is a small chance, however, that such a reference could corrupt a memory buffer (rather than a data structure), possibly resulting in returning corrupt data to a user program or writing bad data to the disk.

Another area of possible impact can come from the move of the graphics drivers into kernel mode. Previously, some portions of a graphics driver ran within Csrss and others ran in kernel mode. Now, the entire driver runs in kernel mode. Although Microsoft doesn't develop all the graphics device drivers supported in Windows, it does work directly with hardware manufacturers to help ensure that they are able to produce reliable and efficient drivers. All drivers shipped with the system are submitted to the same rigorous testing as other executive components.

Finally, it's important to understand that this design (running the windowing and graphics subsystem in kernel mode) is not fundamentally risky. It is identical to the approaches many other device drivers use (for example, network card drivers and hard disk drivers). All these drivers have been operating in kernel mode since the inception of Windows NT with a high degree of reliability.

Some people speculated that the move of the window manager and the GDI into kernel mode would hurt the preemptive multitasking capability of Windows. The theory was that with all the additional Windows processing time spent in kernel mode, other threads would have less opportunity to be run preemptively. This view was based on a misunderstanding of the Windows architecture. It is true that in many other nominally preemptive operating systems, executing in kernel mode is never preempted by the operating system scheduler—or is preempted only at a certain limited number of predefined points of kernel reentrancy. In Windows, however, threads running anywhere in the executive are preempted and scheduled alongside threads running in user mode, and all code within the executive is fully reentrant. Among other reasons, this capability is necessary to achieve a high degree of system scalability on SMP hardware.

Another line of speculation was that SMP scaling would be hurt by this change. The theory went like this: Previously, an interaction between an application and the window manager or the GDI involved two threads, one in the application and one in Csrss.exe. Therefore, on an SMP system, the two threads could run in parallel, thus improving throughput. This analysis shows a misunderstanding of how Windows NT technology worked prior to Windows NT 4. In most cases, calls from a client application to the Windows subsystem process run synchronously; that is, the client thread entirely blocks waiting on the server thread and begins to run again only when the server thread has completed the call. Therefore, no parallelism on SMP hardware can ever be achieved. This phenomenon is easily observable with a busy graphics application using the Performance tool on an SMP system. The observer will discover that on a two-processor system each processor is approximately 50 percent loaded, and it's relatively easy to find the single Csrss thread that is paired off with the busy application thread. Indeed, because the two threads are fairly intimate with each other and sharing state, the processors' caches must be flushed constantly to maintain coherency. This constant flushing is the reason that with Windows NT 3.51 a single-threaded graphics application typically runs slightly slower on an SMP machine than on a single processor system.

As a result, the changes in Windows NT 4 increased SMP throughput of applications that make heavy use of the window manager and the GDI, especially when more than one application thread is busy. When two application threads are busy on a two-processor Windows NT 3.51–based machine, a total of four threads (two in the application plus two in Csrss) are battling for time on the two processors. Although only two are typically ready to run at any given time, the lack of a consistent pattern in which threads run results in a loss of locality of reference and cache coherency. This loss occurs because the busy threads are likely to get shuffled from one processor to another. In the Windows NT 4 design, each of the two application threads essentially has its own processor, and the automatic thread affinity of Windows tends to run the same thread on the same processor indefinitely, thus maximizing locality of reference and minimizing the need to synchronize the private per-processor memory caches.

So in summary, moving the window manager and the GDI from user mode to kernel mode has provided improved performance without any significant decrease in system stability or reliability, even in the case of multiple sessions being created in a Terminal Service enabled configuration.

[lorenzo_ktm]

grazie a tutti per l'aiuto.

vi chiedo solo un'ultima cosa.. avreste delle dispense sui sistemi operativi?

[sirus]

Quanto è stato riportato in Windows Internals edizione 4 è vero fino a XP e 2003. Il design di Vista e 2008 è differente.
Dal mio punto di vista il kernel di Windows 2000/XP/2003 è molto più vicino ad un kernel monolitico, con Vista/2008 si è ritornati "al passato" spostando parte del sistema che girava in kernel space in user space.

Ad ogni modo non credo che esistano sistemi commerciali (ed intento utilizzati in ambienti reali e non di sola ricerca) che dispongono di un kernel che possa rientrare nella definizioni di kernel monolitico o di microkernel.

[gepeppe]

Originariamente inviato da lorenzo_ktm

grazie a tutti per l'aiuto.

vi chiedo solo un'ultima cosa.. avreste delle dispense sui sistemi operativi?

ho trovato queste in rete, sono quelle dell'e-learning. tiè http://www.federica.unina.it/corsi/sistemi-operativi-2/

[khelidan1980]

Originariamente inviato da lorenzo_ktm

grazie a tutti per l'aiuto.

vi chiedo solo un'ultima cosa.. avreste delle dispense sui sistemi operativi?

sono cose complicate con una dispensa non ci fai niente,consiglio un buon libro,io mi son trovato benissimo con questo:

http://www.pearsonhighered.com/educa...USS_01DBC.html

Qui trovi le slide del corso che abbiamo fatto anche io e jeremy.83:

http://homes.dico.unimi.it/sisop/

Originariamente inviato da sirus

Quanto è stato riportato in Windows Internals edizione 4 è vero fino a XP e 2003. Il design di Vista e 2008 è differente.
Dal mio punto di vista il kernel di Windows 2000/XP/2003 è molto più vicino ad un kernel monolitico, con Vista/2008 si è ritornati "al passato" spostando parte del sistema che girava in kernel space in user space.

Ad ogni modo non credo che esistano sistemi commerciali (ed intento utilizzati in ambienti reali e non di sola ricerca) che dispongono di un kernel che possa rientrare nella definizioni di kernel monolitico o di microkernel.

Qnx dovrebbe essere un microkernel puro....