• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Estudio Comparativo de S.O.
 

Estudio Comparativo de S.O.

on

  • 7,153 views

Estudio comparativo de sistemas operativos de la cátedra Sistemas Operativos de la FRCU - UTN.

Estudio comparativo de sistemas operativos de la cátedra Sistemas Operativos de la FRCU - UTN.

Statistics

Views

Total Views
7,153
Views on SlideShare
7,116
Embed Views
37

Actions

Likes
0
Downloads
202
Comments
1

3 Embeds 37

http://www.slideshare.net 35
http://sistemas.frcu.utn.edu.ar 1
http://www.slideee.com 1

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • excelente material! precisamente necesitaba hacer un trabajo para la universidad con esta informacion muchas gracias!
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Estudio Comparativo de S.O. Estudio Comparativo de S.O. Presentation Transcript

    • Tema del día: Estudio comparativo de S.O. Unix BSD, GNU/Linux y Windows NT/2K
    • Objetivos Comparar los SO propuestos de acuerdo a:
        • Historia y Generalidades
        • Estructura del Kernel
        • Gestión de Procesos
        • Gestión de Memoria
        • Estrategias de Entrada/Salida
        • Manejo de Archivos y F.S.
        • Seguridad y Protección
    • Historia: Unix
        • Desarrollado en 1969 por Ken Thompson and Dennis Ritchie (tratando de copiar MULTICS).
        • La tercera versión se escribío en C en los laboratiorios de Bell (creado para soportar Unix)
        • La UC en Berkeley desarrolla su propio Unix (el Berkeley Software Distributions - BSD).
        • Desarrollado para las VAX, 4.3BSD es una de las versiones más influyentes y ha sido portada a innumerables arquitecturas.
        • Dos ramas incompatibles (BSD y System V) crean la necesidad de un estándar (nace POSIX)
    • Historia: GNU/Linux
        • Durante los '80 la FSF comenzó a desarrollar las herramientas para su S.O. (GNU). A principio de los '90 sólo les faltaba terminar el kernel...
        • En 1991 un estudiante finlandés presenta como tesis un kernel basado en Minix, lo llama Linux y lo distribuye bajo licencia GNU.
        • Al unirse con las herramientas de la GNU nace el sistema operativo GNU/Linux.
    • Historia: Windows 2000
        • En 1998, Microsoft decide desarrollar sistemas operativos portables de “nueva tecnología” (NT) que soporten las APIs OS/2 y POSIX...
        • Originalmente la API nativa de NT sería la OS/2, pero durante su desarrollo se la cambió por la Win32 debido a la popularidad de Windows 3.0
        • Luego evolucionó en Windows 2000, un S.O. de 32 bits, preemptive y con arquitectura de microkernel.
    • Principios: Unix Principios de diseño:
        • Diseñado para sistemas de tiempo compartido.
        • Interfaz de usuario sencilla y externa.
        • Sistema de archivos y directorios jerárquico.
        • Archivos como secuencias de bytes.
        • Soporte multiproceso.
        • Objetivos prioritarios: favorecer la interactividad y brindar herramientas al programador de aplicaciones.
    • Principios: GNU/Linux Comparte los principios de Unix y además:
        • Proporciona interfaz POSIX.
        • Pensado para ser portable. En lo posible el código fuente es independiente de la plataforma.
        • Kernel modular con módulos que se cargan de manera dinámica (DLKM).
        • Soporte para gran variedad de F.S.
        • Soporte multiproceso a través de SMP (multiprocesamiento simétrico).
    • Principios: Windows 2000 Principios de diseño:
        • Extensibilidad: usando arquitectura por capas.
        • Portabilidad: escrito en C y C++, con el código dependiente del Hw aislado en una DLL llamada HAL (Hardware Abstraction Layer)).
        • Confiabilidad: protección de memoria y protección de recursos.
        • Performance: kernel preemtive y con soporte de SMP.
        • Internacionalización: mediante la API NLS.
    • Estructura: Unix BSD
    • Estructura: GNU/Linux
    • Estructura: Windows 2K
    • Kernel: Arquitectura El kernel Linux y Windows son monolíticos
        • Todos los servicios corren en un área de memoria compartida en modo kernel.
        • Todos los servicios del sistema son parte de un solo archivo:
          • Linux: vmlinuz
          • Windows: ntoskrnl.exe
        • La interfaz es manejada de manera diferente:
          • Windows tiene un sistema de ventanas en modo kernel.
          • Linux tiene el sistema X-Window que corre en modo usuario.
    • Kernel: Arquitectura Device Drivers Process Management, Memory Management, I/O Management, etc. Win32 Windowing Application System Services User Mode Kernel Mode Hardware Dependent Code Windows Device Drivers Process Management, Memory Management, I/O Management, etc. X-Windows Application System Services User Mode Kernel Mode Hardware Dependent Code Linux
    • Kernel: Linux
      • Linux es monolítico pero con diseño modular.
        • Todos los subsistemas del kernel forman una sola pieza de código sin protección entre ellas.
      • La modularidad se soporta de dos maneras:
        • Opciones en tiempo de compilación.
        • La mayoría de los componentes se pueden compilar como DLKMs
    • Kernel: Linux (cont.) DLKMs (dynamically loadable kernel modules)
        • Se compilan separados del kernel
        • Se cargan en el kernel en tiempo de ejecución y bajo demanda (componentes poco usados ocupan memoria del kerenl sólo cuando son necesarios)
        • Lo módulos del kernel pueden ser actualizados gradualmente
        • Permite soportar kernel mínimos que se adaptan a la computadora y cargan sólo aquellos componentes que son utilizados.
    • Kernel: Windows
      • Windows es monolítico (y modular)
        • Sin protección entre componentes del kernel.
        • El soporte de modularidad es débil:
        • Los drivers de Windows permiten la extensión dinámica de las funcionalidades del kernel
      • Los drivers de Windows son módulos de carga dinámica
        • Gran cantidad de código (incluso protocolos y algunos servicios) corren como drivers.
        • Se compilan independientemente del kernel.
        • Pueden ser cargados de manera dinámica.
    • APIs y Compejidad
      • Windows
        • Kernel con unas 250 system calls (via ntdll.dll)
        • Subsistemas por capas Win32/POSIX
        • Rich Windows API (17500 funciones)
      • Linux
        • Kernel con cerca de 200 system calls
        • Librerías de sistema por capas: BSD, Unix SysV y POSIX
        • APIs compactas (1742 funciones en la Single Unix Specification Version 3; sin incluir las APIs de X-Window)
    • APIs y Compejidad
      • Windows
        • Kernel con unas 250 system calls (via ntdll.dll)
        • Subsistemas por capas Win32/POSIX
        • Rich Windows API (17500 funciones)
      • Linux
        • Kernel con cerca de 200 system calls
        • Librerías de sistema por capas: BSD, Unix SysV y POSIX
        • APIs compactas (1742 funciones en la Single Unix Specification Version 3; sin incluir las APIs de X-Window)
    • Procesos: Unix y Linux
      • Proceso:
        • Es la unidad básica de procesamiento.
        • Cada proceso tiene su espacio de direcciones a través de su BCP y tablas intermedias.
        • Relaciones padre/hijo entre procesos.
      • Hilos (threads)
        • Comparten el espacio de direcciones y las tablas intermedias con el proceso que las creó.
        • PThreads brinda herramientas para threads cooperativas.
    • Planificación
        Windows
        • Dos clases de planif.
          • Prioridad de Tiempo Real (fija) 16 a 31
          • Prioridad Dinámica de 1 a15
        • La prioridades más altas son favorecidas.
          • La prioridades de un thread no pueden ser reducidas.
        Linux
        • Tres clases de planif.
          • Normal (pri. 100-139)
          • RR fija (pri. 0-99)
          • FIFO fija (pri. 0-99)
        • Prioridades bajas son favorecidas.
    • Planificación: Prioridades 31 15 16 0 Fija Dinámica E/S Windows 140 100 99 0 FIFO Fija Round-Robin Fija Normal CPU E/S Linux
    • Planificación: Linux
      • La mayoría de los procesos usan políticas de prioridad dinámica.
      • El valor “nice” establece la prioridad base de un proceso.
        • Los valores de nice van desde -20 a +20 (más grande = menor prioridad)
        • Los usuarios no privilegiados sólo pueden especificar valores de nice positivos.
      • Los procesos normales se ejecutan sólo cuando no quedan procesos de tiempo real (de prioridad fija) en la cola de listos.
    • Planificación T-R Linux
      • Linux soporta dos políticas de prioridades estáticas para procesos de tiempo real:
        • Round-Robin y FIFO
          • Se selecciona con la llamada sched-setcheduler()
          • Usan prioridades estáticas con valores ente 1 y 99
          • Los procesos se ejecutan en estricto orden decreciente de prioridad
        • Procesos de T-R pueden provocar inanición a procesos de baja prioridad.
      • Llamadas al sistema de mucha duración pueden causar inversión de prioridades.
    • Planificación T-R Windows
      • Windows soporta planificación Round-Robin estática para hilos con prioridades en el rango de tiempo real (16-31)
        • Un hilo puede usar hasta un quantum de tiempo.
        • Las prioridades nunca son aumentadas.
      • Hilos de tiempo real pueden provocar inanición en servicios del sistema.
      • Ciertas llamadas al sistema pueden provocar una inversión de prioridades.
    • Planificación: Quantums
        Windows
        • La rodaja de un hilo es 10ms o 120ms
        • Reentrante y con expropiación.
        Linux
        • La rodaja de un hilo es 10ms a 200ms
          • Default: 100ms.
          • Varía de acuerdo a prioridad (según nivel de interactividad)
        • Reentrante y con expropiación.
      Fixed: 120ms 20ms Primer Plano: 60ms Segundo Plano 100ms 200ms 10ms
    • Soporte Multiprocesador
        Windows
        • Soporta SMP
          • Hasta 32/64 CPUs.
        • Soporta acceso a memoria no uniforme.
        • Soporta Hyperthreading
          • Favorece CPUs desocupadas cuando es posible.
        Linux
        • Soporta SMP
          • Sin límite de CPUs.
        • Soporta acceso a memoria no uniforme
        • Soporta Hyperthreading
          • Favorece CPUs desocupadas cuando es posible.
    • Memoria Principal
        Windows
        • Conjuntos de trabajo por proceso:
          • Tamaño dinámico.
          • Usa algoritmo del reloj.
        Linux
        • Conjunto de trabajo global:
          • Usa algoritmo del reloj.
      Process LRU Reused Page Other Process LRU LRU Reused Page
    • Memoria Virtual
        Windows
        • Se separa en usuario/kernel desde 2/2GB hasta 3/1GB
        • Memoria virtual paginada por demanda
          • CoW, compartir mem.
        • Mapeo de archivos.
        Linux
        • Se separa en usuario/kernel 4/4GB
        • Memoria virtual paginada por demanda
          • CoW, compartir mem.
        • Mapeo de archivos.
    • Entrada/Salida: Linux
      • Centrado alrededor del nodo-v.
      • Los drivers no están ordenados por capas, aunque hay cierta estructura: controlador / dispositivo.
      • La cantidad de interrupciones se controla mediante IRQL (internal interrupt request level)
      • Las int. se separan en rutina de trat. de la int.(ISR) e interrupción suave o tasklet.
      • Soporta Plug&Play
    • Entrada/Salida: Windows
      • Centrado alrededor del objeto archivo.
      • Drivers ordenados por capas y la mayoría de la E/S soporta operación asíncrona.
      • La cantidad de interrupciones se controla mediante IRQL.
      • Las int. se separan en rutina de trat. de la int. (ISR) y llamada a proc. diferido (DPC)
      • Soporta Plug&Play
    • Caché de Archivos
      • Tanto Windows como Linux soportan:
      • Caché global común.
      • Caché virtual de archivos
      • El caché se hace a nivel de archivos, no de bloques.
      • Los archivos son mapeados en memoria del kernel.
      • La caché permite servir archivos usando un protocolo de copia cero (zero-copy)
    • Bibliografía Esta clase puede ser ampliada viendo:
        • Carretero (S.O. Visión Aplicada) (1ra. ed.):
          • Capítulo 11 - Estudio de Casos: Linux.
          • Capítulo 12 - Estudio de Casos: Windows NT.
        • Tannenbaum (Sistemas Operativos Modernos):
          • Capítulo 10: Unix y Linux.
          • Capítulo 11: Windows 2000.
        • Stallings (Sistemas Operativos)
          • Los contenidos se encuentran distribuidos en los distintos capítulos del libro. Se puede descargar un resumen en : http://williamstallings.com/OS4e.html
    • Gracias ! Ing. Gabriel E. Arellano [email_address] http://www.gabriel-arellano.com.ar/so/ (2008) Gabriel E. Arellano Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. The GNU Free Documentation License as applicable to this document can be found at: http://www.gnu.org/copyleft/fdl.html