Visita Encydia-Wikilingue.con

Núcleo (informática)

núcleo (informática) - Wikilingue - Encydia

Error al crear miniatura:
Un núcleo de sistema conecta el software aplicativo al hardware de un ordenador.

En computación, el núcleo o cerne (en inglés: kernel) es el componente céntrico del sistema operativo de la mayoría de los ordenadores; él sirve de puente entre aplicativos y el procesamiento real de datos hecho a nivel de hardware. Las responsabilidades del núcleo incluyen gestionar los recursos del sistema (la comunicación entre componentes de hardware y software ).[1] Generalmente como un componente básico del sistema operativo, un núcleo puede ofrecer la capa de abstracción de nivel más bajo para los recursos (especialmente procesadores y dispositivos de entrada/salida ) que softwares aplicativos deben controlar para realizar su función. Él típicamente haces estas facilidades disponibles para los procesos de aplicativos a través de mecanismos de comunicación entre procesos y llamadas de sistema.

Tareas de sistemas operativos son hechas de maneras diferentes por núcleos diferentes, dependiendo de su dibujo y abordagem. Mientras núcleos monolíticos intentarán alcanzar sus objetivos ejecutando todos códigos de sistema en el mismo espacio de endereçamento para aumentar la performance del sistema, micronúcleos ejecutan la mayoría de los servicios del sistema en el espacio de usuario como servidores, buscando mejorar el mantenimiento y la modularidade del sistema operativo.[2] Una gamma de posibilidades existen entre estos extremos.

Tabla de contenido

Visión general

Error al crear miniatura:
Una visión típica de una arquitetura de ordenadores como series de capas de abstracción: hardware, firmware, montador, núcleo, sistema operativo y aplicativos (vea también Organización Estructurada de Ordenadores, por Andrew S. Tanenbaum.).

En la definición del 'núcleo', Jochen Liedtke dije que la palabra es "tradicionalmente usada para definir la parte del sistema operativo que es obligatoria y común a todo software en el sistema."[3]

La mayoría de los sistemas operativos depende del concepto de núcleo . La existencia de un núcleo es una consecuencia natural de proyectar un sistema de ordenador como series de capas de abstracción,[4] cada una de las funciones dependiendo de las funciones de las capas abajo de sí. El núcleo de este punto de vista, es simplemente el nombre dado al nivel más inferior de abstracción que es implementado en software. Para evitar tener un núcleo, tendría-si que proyectar todo el software en el sistema de modo a no utilizar abstracción alguna; esto iría a aumentar la complejidad y el proyecto hasta tal punto que sólo los sistemas más simples serían capaces de ser implementados.

Mientras esto hoy es llamado núcleo, originalmente la misma parte del sistema también fue llamado el nucleus o caroço [1][5][6][7] (Nota, sin embargo, este término caroço también fue usado para referirse la memoria primordial de un sistema de ordenador, por qué algunos de los primeros ordenadores usaron una forma de memoria llamada memoria de caroços magnéticos), y fue concebido originalmente como conteniendo sólo los recursos de soporte esenciales del sistema operativo.

En la gran mayoría de los casos, el proceso de iniciação comienza ejecutando el núcleo en el modo supervisor.[8] El núcleo después inicializa a sí y después el primer proceso. Tras esto, típicamente, el núcleo no ejecuta directamente, sólo en respuesta para eventos externos (p.ej., a través de llamadas de sistema usados por los aplicativos para requisitar servicios del núcleo, o veía interrupciones usadas por el hardware para notificar el núcleo sobre eventos). Además de eso, típicamente el núcleo suministra un lazo que es ejecutado siempre que ningún proceso esta disponible para ejecución; generalmente llamado de proceso desocupado.

El desarrollo del núcleo es considerado una de las más complejas y difíciles tareas en programación.[9] Su posición céntrica en un sistema operativo implica en la necesidad de buena performance, que define el núcleo como pieza de software crítica y hace su desarrollo correcto e implementación correcta difícil. Debido a diversas razones, el núcleo puede hasta no ser capaz de utilizar mecanismos de abstracción , que él suministra a otro software. Tales razones incluyen preocupaciones con la gestión de memoria (p.ej. una función en modo de usuario puede depender de memoria estando sujeta la paginación por demanda, pero como el propio núcleo suministra esta facilidad, él no puede utilizarla, pues él puede no permanecer en la memoria para suministrar esta facilidad) y la falta de reentrância , luego su desarrollo se hace aún más difícil para ingenieros de software.

Generalmente un núcleo va a suministrar recursos para decalaje de procesos de bajo nivel,[10] comunicación entre procesos, sincronización de procesos, cambio de contexto, manipulación de bloques de control de proceso, gestión de interrupciones , creación y destrucción de procesos, y suspensión y continuación de procesos (vea estados de procesos).[5][7]

Facilidades básicas del núcleo

El principal propósito del núcleo es gestionar los recursos del ordenador y permitir que otros programas rueden y usen de estos recursos.[1] Típicamente estos recursos consisten de:

Aspectos importantes en la gestión de recursos son la definición de un dominio de ejecución (espacio de endereçamento) y el mecanismo de protección utilizado para mediar el acceso a recursos dentro de un dominio.[1]

Núcleos generalmente tan ofrecen métodos para sincronización y comunicación entre procesos (IPC (en inglés)).

Un núcleo puede implementar estos recursos él aún, o depender de algunos procesos que él ejecuta para suministrar estas facilidades a otros procesos, sin embargo en este caso él debe ofrecer algún modo del IPC permitir que procesos acessem las facilidades suministradas uno por el otro.

Finalmente, un núcleo debe ofrecer un método de acceso a estas facilidades para los programas en ejecución.

Gestión de Procesos

La principal tarea de un núcleo es permitir la ejecución de aplicativos y ayudarlos con recursos como abstracciones de hardware. Un procesos define que porciones de la memoria el aplicativo puede acessar.[11] (Para esta introducción, proceso, aplicativo y programa son usados como sinônimos.) La gestión de procesos del núcleo debe llevar en cuenta el equipamiento de hardware embarcado para protección de memoria.[12]

Para rodar un aplicativo, un núcleo generalmente crea un espacio de endereçamento para el aplicativo, carga el archivo conteniendo de instrucciones del programa en la memoria (tal vez veía paginación por demanda), crea una pila para el programa y ramos para una dada localización dentro del programa, iniciando, por lo tanto su ejecución.[13]

Núcleos multitarefa son capaces de dar al usuario la ilusión de que un número de procesos que esta rodando simultáneamente en el sistema es mayor del que el número de procesos que aquel sistema es físicamente capaz de rodar simultáneamente. Usualmente, el número de procesos que un sistema puede rodar simultáneamente es igual el número de CPUs que él posee instaladas (sin embargo, esto puede no ser el caso de procesadores que soportan múltiples líneas de ejecución simultáneas).

En un sistema multitarefas preemptivo, el núcleo dará a todos programas una parcela del tiempo y va a alternar de proceso a proceso tan rápidamente que dará al usuario la impresión de como si los procesos estuvieran siendo ejecutados simultáneamente. El núcleo utiliza algoritmos de decalaje para determinar cual proceso será ejecutado a continuación y cuánto tiempo le será dado. El algoritmo escogido puede permitir que algunos procesos tengan una prioridad más alta que muchos otros. El núcleo generalmente también provê a esos procesos una manera de comunicarse; es decir llamado comunicación entre procesos (IPC (en inglés)) y las principales implementaciones son memoria compartida, cambio de mensajes y llamadas de procedimiento remoto (vea computación concurrente).

Otros sistemas (particularmente en ordenadores más pequeños, menos potentes) pueden suministrar multitarefa de cooperación, en que cada proceso es permitido rodar sin ininterrumpidamente hasta que él haga una requisição especial que avisa al núcleo que él puede alternar para otro proceso. Tales requisições son conocidos como "indulgencias" (yielding(en inglés), y típicamente ocurren en respuesta a un pedido para comunicación entre procesos, o para esperar hasta el acontecimiento de un evento. Versiones más antiguas de ambos Microsoft Windows y Mac Los utilizaron el concepto de multitarefa cooperativa, pero alternaron para esquemas preemptivos conforme la potencia de los ordenadores blanco de su mercado aumentaba[carece de fuentes?].

El sistema operativo puede también soportar el multiprocessamento (multiprocessamento simétrico (SMP (en inglés)), o, acceso no-uniforme la memoria); en este caso, diferentes programas y líneas de ejecución pueden rodar en diferentes procesadores. Un núcleo para tal sistema debe ser proyecto para ser reentrante, lo que significa que él puede rodar seguramente dos partes de su código simultáneamente. Esto típicamente significa ofrecer mecanismos de sincronización (como traba-giros) para asegurar que dos procesadores no intentarán modificar los mismos datos a la vez.

Gestión de Memoria

El núcleo posee acceso completo la memoria del sistema y debe permitir que procesos acessem la memoria con seguridad conforme su necesidad. Frecuentemente el primer paso para eso es el endereçamento virtual, generalmente alcanzado a través de la paginación y/o segmentación . Endereçamento virtual permite al núcleo hacer con que un dato dirección física parezca ser otra dirección, la dirección virtual. Espacios de dirección virtual pueden ser diferentes para diferentes procesos; la memoria que un procesos acessa en una dirección (virtual) particular puede ser diferente de la que un otro proceso acessa por la misma dirección. Esto permite a todos programas funcionar como si él fuera el único en ejecución, además del núcleo, y por eso evita que aplicativos trabad unos a los otros.[13]

En varios sistemas, la dirección virtual de un programa puede referirse a datos que no están en la memoria actualmente. La cama de indireção ofrecida por el endereçamento virtual permite que el sistema utilice medios de armazenagem de datos, como un disco rígido, para almacenar lo que de otro modo tendría que permanecer en la memoria (RAM(en inglés)). Como resultado. sistemas operativos pueden permitir que programas usen más memoria del que está físicamente disponible. Cuando un programa necesita de datos que no están en la RAM, la CPU avisa el núcleo que esto ocurre, y el núcleo responde escribiendo el contenido de un bloque de memoria inactivo para el disco (si necesario), y sustituyéndolo en la memoria con los datos requisitados por el programa. El programa puede entonces continuar su ejecución del punto en que fue suspenso. Este esquema es generalmente conocido como paginación por demanda.

Endereçamento virtual también permite la creación de particiones virtuales de memoria en dos áreas separadas, una sedo reservada para el núcleo (espacio de núcleo) y el otro para los aplicativos (espacio de usuario). Los aplicativos no tiene permiso del procesador para acessar la memoria del núcleo, por lo tanto previniendo que un aplicativo pueda dañar el núcleo en ejecución. Esta partición fundamental de espacio de memoria contribuyó mucho para los proyectos de núcleos realmente de propósito general y es casi universal en tales sistemas, aunque algunas núcleos de investigación (p.ej. Singularity) usen otros métodos.

Gestión de dispositivos

Para realizar funciones útiles, procesos necesitan acessar periféricos conectados al ordenador, que son controlados por el núcleo a través del driver del dispositivo. Por ejemplo, para mostrar al usuario algo utilizando la pantalla, un aplicativo tendría que hacer un requisição al núcleo que encaminaría la requisição para su driver de pantalla, que es responsable por realmente tracejar los carácteres/pixeis.[13]

Un núcleo debe mantener una lista de dispositivos disponibles. Esta lista puede ser conocida de antemano (p.ej. en un sistema embarcado donde el núcleo será reescrito si el hardware disponible cambiar), configurado por el usuario (típico en ordenadores personales antiguos y en sistemas proyectados para uso personal) o detectado por el sistema durante la ejecución (normalmente llamado Conectar y Usar).

En un sistema "Conectar y Usar", un dispositivo realizar primero un sondeo en en los diferentes barramentos de hardware, como Interconector de Componentes Periféricos (PCI(en inglés)) o Barramento Serial Universal (USB(en inglés)), para detectar los dispositivos instalados, después busca los drivers pertinentes.

Como la gestión de dispositivos es un tópico mucho especifico del SO, estos drivers son manipulados de modos diferentes por cada tipo de dibujo de núcleo, pero en todos los casos, el núcleo tiene que suministrar la entrada/salida para permitir que los drivers acessem físicamente sus dispositivos a través alguna puerta o localización de la memoria. Decisiones muy importantes necesitan ser hechas al proyectar el sistema de gestión de dispositivos, ya que en algunos proyectos de acceso pueden envolver cambios de contexto , haciendo la operación custosa para el procesador y causando un gasto excesivo de recursos.[carece de fuentes?]

Llamadas del Sistema

Para realmente realizar algo útil, un proceso debe acessar los servicios ofrecidos por el núcleo. Es decir implementado por cada núcleo, pero la mayoría ofrece una Biblioteca normalizada de la C o una Interfaz de programación de aplicativos, que envuelve las funciones relativas al núcleo.[14]

El método de invocar las funciones del núcleo varía de núcleo para núcleo. Si el aislamiento de memoria está siendo usado, es imposible para un proceso de usuario llamar el núcleo directamente, por qué eso sería una violación de las reglas de control de acceso del procesador. Algunas posibilidades son:

Decisiones de dibujo del Núcleo

Problemas con lo soporte del núcleo para protección

Una consideración importante en el dibujo del núcleo es lo soporte que él ofrece para protección contra faltas (tolerancia la fallos) y de comportamientos # apenas-intencionados (seguridad). Estos dos aspectos generalmente no son claramente distinguidos, y la criba en el dibujo del núcleo lleva el rechazo de una estructura jerárquica de protección.[1]

Los mecanismos o políticas ofrecidos por el núcleo pueden ser clasificados en consonancia con varios criterios, como: estático (forzado durante el tiempo de compilación) o dinámico (forzado durante el tiempo de ejecución); preemptivo o post-detección; en consonancia con los principios de protección a que ellos corresponden (p.ej. Denning[15][16]); quiere ellos sean soportados por el hardware o basados en lenguaje; quiere ellos sean más un mecanismo abierto o me la política compulsiva; y muy más.

Tolerancia la fallos

Una medida útil para el nivel de tolerancia la fallos de un sistema es quão estricto él es con relación al principio del más pequeño privilegio.[17] En casos donde múltiples programas están rodando en un único ordenador, es importante prevenir fallos en uno de los programas de afectar negativamente otro. Extendiéndose al dibujo con malas-intenciones más del que el fallo en sí, esto también implica la seguridad , cuando es necesario impedir procesos de acessar informaciones sin que les sea dada a debida permiso.

Las dos principales implementaciones veía hardware[18] para protección (de informaciones sensibles) son dominios jerárquicos de protección (también llamadas arquiteturas anillo, arquiteturas de segmento o modo supervisor),[19] y endereçamento basado en capacidades.[20]

Error al crear miniatura:
anillos de privilegio, como en la x86 , son una abordagem habitual de dominios jerárquicos de protección usados en muchos sistemas comerciales para obtener algún nivel de tolerancia la fallos.

Dominios jerárquicos de protección son muy menos flexibles, como en el caso de cualquier núcleo con una estructura jerárquica presumida como un criterio de desarrollo global.[1] En el caso de protección no es posible designar diferentes privilegios a procesos que no están en el mismo nivel de privilegio, y por eso no es posible corresponder a los cuatro principios de Denning para la tolerancia la fallos,[15][16] particularmente el principio del más pequeño privilegio. Dominios jerárquicos de protección también cargan una enorme desvantagem en la performance, ya que la interacción entre diferentes niveles de protección, cuando un procesos tiene que manipular una estructura de datos en ambos 'modo usuario' y 'modo supervisor', siempre exige copia de mensajes (transmisión por valor).[21] Un núcleo basado en capacidades, sin embargo, es más flexible en designar privilegios, puede corresponder a los principios de Denning para la tolerancia la fallos,[22] y generalmente no sufren de problemas de performance de la copia por valor.

Ambas implementaciones típicamente exigen alguno soporte de hardware o firmware para ser operabais y eficientes. Lo soporte de hardware para dominios jerárquicos de protección[23] generalmente es de "modos de CPU." Un modo simple y eficiente de suministrar soporte a hardware es delegar a la unidad de gestión de memoria la responsabilidad por checar los permisos de acceso para todos accesos la memoria, un mecanismo llamado endereçamento basado en capacidades.[22] Falta en la mayoría de las arquiteturas comerciales, lo soporte la MMU para capacidades.

Una abordagem alternativa es simular capacidades usando dominios jerárquicos comumente soportados; en esta abordagem, cada objeto protegido debe residir en un espacio de endereçamento al cual el aplicativo no posee acceso; el núcleo también mantiene una lista de capacidades en tal memoria. Cuando un aplicativo necesita acessar un objeto protegido por una capacidad, él realiza una llamada de sistema y el núcleo realiza el acceso a él. El coste de performance de intercambiar de espacio de endereçamento limita la praticabilidade de esta abordagem en sistemas con interacciones complejas entre objetos, pero es utilizado en los sistemas operativos actuales para objetos que no son acessados frecuentemente o que no deben ser hechos rápidamente.[24][25] Implementaciones donde los mecanismos de protección no soportados por el firmware, pero son, en vez de eso, simulados en níveos más altos (p.ej. simulando capacidades al manipular tablas de páginas en hardware que no posee soporte directo), son posibles, pero hay implicações de performance.[26] Sin embargo, falta de soporte en el hardware puede no ser problema, para sistemas que escogen usar una protección basada en lenguaje.[27]

Una decisión importante en el proyecto del núcleo es la elección de los niveles de abstracción en que los mecanismos y políticas de seguridad deben ser implementados. Los mecanismos de seguridad del núcleo tienen un papel crítico en el soporte la seguridad en los niveles superiores.[22][28][29][30][31]

Una abordagem es utilizar soporte en el núcleo y firmware para tolerancia la fallos (ver arriba), y montar las políticas de seguridad para comportamiento malicioso encima de eso (añadiendo recursos como mecanismos de criptografia cuando necesario), delegar más responsabilidad para el compilador. Implementaciones que delegam la aplicación de políticas de seguridad para el compilador y/o nivel del aplicativo son generalmente llamados seguridad basada en lenguaje.

La falta de muchos mecanismos críticos de seguridad en los principales sistemas operativos impide la implementación adecuada de políticas de seguridad en el nivel de abstracción del aplicativo.[28] En la verdad, un engaño muy común en la seguridad de ordenadores es que cualquier política de seguridad puede ser implementada en el aplicativo, independientemente del soporte en el núcleo.[28]

Protección basada en hardware o lenguaje

Hoy, típicos sistemas de computación usan reglas aplicadas por el hardware sobre cuáles programas tienen permiso para acessar cuáles datos. El procesador monitora la ejecución y desconecta un programa que viole una regla (p.ej., un proceso de usuario que intenta leer o escribir en la memoria del núcleo, y así por delante). En sistemas que no poseen soporte para capacidades, procesos son aislados uno del otro, utilizándose espacios de endereçamento separados.[32] Llamadas de un proceso de usuario en el núcleo son regidas por la exigencia de que ellos usen uno de los métodos de llamada del sistema descritos arriba.

Una abordagem alternativa es usar protección basada en lenguaje. En un sistema de protección basado en lenguaje, el núcleo va a permitir la ejecución sólo de código producido por un compilador en que él confíe. El lenguaje puede entonces, ser proyectada de modo tal que será imposible para el programador instruya algo que violaría los requisitos de seguridad.[27]

Desvantagens incluyen:

Ventajas de esta abordagem incluyen:

Ejemplos de sistemas con protección basada en lenguaje incluyen el JX y Singularity .

Cooperación de procesos

Edsger Dijkstra probó que partiendo de un punto de vista lógico, operaciones atómicas de travamento y destravamento operando en semáforos binarios son suficientemente primitivos para expresar a cualquier funcionalidad de cooperación entre procesos.[33] Sin embargo esta abordagem es generalmente tomada como deficiente en términos de seguridad y eficiencia, mientras que una abordagem veía cambio de mensajes es más flexible.[7]

Gestión de dispositivos de entrada/salida

La idea de un núcleo donde dispositivos de entrada/salida son gestionados uniformemente con otros procesos, como procesos paralelos en cooperación, fue propuesta e implementada de entrada por Brinch Hansen (aunque ideas similares hayan sido sugeridas en 1967[34][35]). En la descripción de Hansen de esto, los procesos "comunes" son llamados procesos internos, mientras que los dispositivos de entrada/salida son llamados procesos externos.[7]

Abordagens de desarrollo de todo el núcleo

Naturalmente, las tareas y recursos listar arriba pueden ser suministradas de varios modos que difieren entre sí en proyecto e implementación.

El principio de la criba entre el mecanismo y la política es la diferencia sustancial entre la filosofía de micronúcleo y núcleo monolítico.[36][37] Aquí un mecanismo es el apoyo que permite la implementación de varias políticas diferentes, mientras una política es un "modo de operación" particular. Por ejemplo, una mecanismo puede ofrecer a la tentativas de entrada de un usuario un método de llamar un servidor de autorización para determinar si un acceso debe ser dado; una política puede ser para el servidor de autorización exigir una seña y checá-la contra una seña embaralhada almacenada en una base de datos. Debido al hecho del mecanismo ser genérico, la política puede ser alterada con más facilidad (p.ej. al exigir el uso de uno pase) del que si un mecanismo y política fueran integrados en el mismo módulo.

En un micronúcleo mínimo algunas políticas básicas son incluidas,[37] y sus mecanismos permite que lo que está rodando sobre el núcleo (la parte remanescente del sistema operativo y otras aplicaciones) decida cuáles políticas adopte (como gestión de memoria, decalaje de proceso de alto nivel, gestión de sistema de archivos, etc.).[1][7] Un núcleo monolítico en vez de eso, tiende a incluir varias políticas, entonces restringiendo el resto del sistema dependiente de ellas.

Per Brinch Hansen presentó un argumento convincente a favor de la criba del mecanismo y de la política.[1][7] El fallo en llenar completamente esta criba, es una de las mayores causas para la falta de innovación en los sistemas operativos existentes actualmente,[1] un problema común en las arquiteturas de ordenador.[38][39][40] El proyecto monolítico es inducido por la abordagem de arquitetura "modo núcleo"/"modo usuario" para protección (técnicamente llamada de dominios jerárquicos de protección), que es común en sistemas comercias convencionales;[41] en la verdad, todo módulo que necesite de protección es por lo tanto preferiblemente incluido en el núcleo.[41] Esta conexión entre proyecto y "modo privilegiado" puede ser reconduzida hasta el problema llave de la criba del mecanismo y de la política;[1] de hecho, la abordagem de arquitetura de "modo privilegiado" se funde al mecanismo de protección con las políticas de seguridad, mientras la principal abordagem de arquitetura alternativa , endereçamento basado en capacidades, claramente distingue ambos, llevando naturalmente al desarrollo de un micronúcleo design[1](vea Criba entre protección y seguridad).

Mientras núcleos monolíticos ejecutan todo su código en el mismo espacio de endereçamento (espacio de núcleo) micronúcleos intentan ejecutar la mayor parte de sus servicios en el espacio de usuario, buscando aprimorar el mantenimiento y modulabilidade del código base.[2] La mayoría de los núcleos no se encaja exactamente en una de estas categorías, siendo más encontrados entre estos dos proyectos. Los llamados núcleos híbridos. Proyectos más exóticos como nanonúcleos y exonúcleos están disponibles, pero son usados raramente utilizado para sistemas productivos. El virtualizador Xen, por ejemplo, es un exonúcleo.

Error al crear miniatura:
Diagrama de núcleos monolíticos.

Núcleos monolíticos

En un núcleo monolítico, todos los servicios del sistema operativo ruedan junto con la línea de ejecución principal del núcleo, por lo tanto, también se encuentran en la misma área de memoria. Esta abordagem permite el acceso vasto y poderoso de hardwares. Algunos desenvolvedores, como desenvolvedor del UNIX Ken Thompson, defienden que es "más fácil de implementar un núcleo monolítico"[42] que micronúcleos. Las principales desvantagens de núcleos monolíticos son las dependencias entre los componentes del sistema - un defecto en un driver de dispositivo puede paralizar todo el sistema - y el hecho de núcleos grandes pueden se haga muy difíciles de mantener.

Error al crear miniatura:
En la abordagem del micronúcleo, el propio núcleo suministra sólo funcionalidades básicas que permite la ejecución de servidores , programas separados que asumen funciones que serían del núcleo monolítico, como drivers de dispositivos, servidores de interfaz de usuario, etc.
Error al crear miniatura:
Diagrama de interacción de un micronúcleo.

Micronúcleos

La abordagem de micronúcleo consiste en definir abstracciones simples sobre el hardware, con un conjunto de primitivos o llamadas de sistema para implementar servicios mínimos del sistema operativo como gestión de memoria, multitarefas, y comunicación entre procesos. Otros servicios, incluyendo aquellos normalmente suministrados por un núcleo monolítico como red, son implementados en programas de espacio de usuario, conocidos como servidores. Micronúcleos son más fáciles de mantener del núcleos monolíticos, pero un gran número de llamadas de sistemas de cambios de contexto pueden desacelerar el sistema por qué ellos generalmente generan más degradación en la performance del que simple llamadas de función.

Un micronúcleo permite la implementación de las partes restantes del sistema operativo como aplicativos normales escritos en lenguaje de alto nivel, y el uso de diferentes sistemas operativos sobre el mismo núcleo no-modificado.[7] Él también hace posible alternar dinámicamente entre sistemas operativos y mantener más de uno de ellos activos simultáneamente.[7]

Núcleos monolíticos x micronúcleos

Conforme el núcleo del ordenador crecen, un número de problemas se hacen evidentes. Uno de los más obvios es que el espacio de memoria aumenta. Es decir mitigado de cierto modo al aperfeiçoar el sistema de memoria virtual, pero ni todas arquitetura de ordenador soportan memorias virtuales.[43] Para reducir el espacio utilizado por el núcleo, modificaciones extensivas necesitan ser realizadas para remover cuidadosamente código inútil, que puede ser muy difícil debido a dependencias poco aparentes entre partes de un núcleo con millones de líneas de código.

Por el comienzo de los años 1990, debido a varios problemas de núcleos monolíticos en comparación la micronúcleos, núcleos monolíticos fueron considerados obsoletos por virtualmente todos investigadores de sistemas operativos. Como resultado, el proyecto del Linux, un núcleo monolítico más del que un micronúcleo fue el tópico de la famosa discusión inflamada entre Linus Torvalds y Andrew Tanenbaum.[44] Hay méritos en ambos argumentos presentes en el debate Tanenbaum–Torvalds.

Performances

Núcleos monolíticos son proyectados para que todo su código quede en el mismo espacio de endereçamento (espacio de núcleo), que algunos desenvolvedores argumentan ser necesario para aumentar la performance del sistema.[45] Algunos desenvolvedores también sostienen la hipótesis de que núcleos monolíticos son extremadamente eficientes se sean bien escritos.[45][fuente fiable?]

La performance de micronúcleos construidos los años 1980 y comienzos de los 1990 era terrible.[3][46] Estudios empíricos que midieron la performance de estos micronúcleos no analizaron los motivos para tal ineficiência .[3] Las explicaciones para estos datos fueron dejadas para el "folclore"[necesario esclarecer], con la suposición de que ellos eran debido al aumento de la frecuencia del cambio de modo núcleo para modo usuario,[3] debido a mayor frecuencia de comunicación entre procesos[3] y la mayoría frecuencia de cambios de contexto.[3]

De hecho, como fue conjeturado en 1995, los motivos para la terrible performance de los micronúcleos puede también haber sido: (1) una real ineficiência en la implementación de toda la abordagem de micronúcleo, (2) conceptos particulares implementados en esos micronúcleos, y (3) la implementación individual de estos conceptos.[3] Por lo tanto aún falta estudiar si la solución para construir un micronúcleo eficiente fue, al contrario de tentativas anteriores, a de aplicar las técnicas correctas de construcción.[3]

En el otro extremo, la arquitetura de dominios jerárquicos de protección que lleva a un proyecto de núcleo monolítico[41] genera impactos significativos en la performance cada vez que hay una interacción entre diferentes niveles de protección (p.ej. cuando un proceso tiene que manipular una estructura de datos en ambos 'modo usuario' y 'modo supervisor'), desde que esto exija copia de mensaje por valor.[21]

A mediados de 1990, la mayoría de los investigadores abandonó la creencia de que ajustes cuidadosos podrían reducir estos impactos dramáticamente,[carece de fuentes?] pero recientemente, nuevos micronúcleos, optimizados para performance, tales como los L4[47] y K42 vienen trabajando en estos problemas.[necesario verificar]

Error al crear miniatura:
La abordagem de núcleo híbrido combina velocidad y proyectos más simples de un núcleo monolítico con la modularidade y ejecución segura de un micronúcleo.

Núcleos híbridos

Núcleos híbridos son un acuerdo entre el desarrollo de micronúcleos y núcleos monolíticos. Esto implica ejecutar algunos servicios (como la pila de red o el sistema de archivos) en el espacio del núcleo para reducir el impacto en la performance[carece de fuentes?] de un micronúcleo tradicional, pero aún ejecutar el código en el núcleo (como drivers de dispositivos) como servidores en el espacio de usuario.

Nanonúcleos

Un nanonúcleo delega virtualmente todos los servicios — incluyendo hasta los más básicos como controlador de interrupciones o el temporizador — para drivers de dispositivo para hacer el requerimento de memoria del núcleo aún más pequeño del que lo de los tradicionales micronúcleos.[48]

Error al crear miniatura:
Diagrama de interacción de un exonúcleo.

Exonúcleos

Un exonúcleo es un tipo de núcleo que no abstrai hardware in plantillas teóricas. En vez de eso él aloca recursos físicos de hardware, como el tiempo de un procesador, páginas de memoria, y bloques de disco, para diferentes programas. Un programa rodando en un exonúcleo puede conectar para una biblioteca del sistema operativo que usa el exonúcleo para simular las astrações de un sistema operativo conocido, o él puede desarrollar abstracciones específicas para aquel aplicativo para ume performance superior.[49]

Historia del desarrollo del núcleo

Núcleos de los primeros sistemas operativos

Hablando estrictamente, un sistema operativo (y, esto incluye un núcleo) no es gracias a rodar un ordenador. Programas pueden ser cargados directamente y ejecutados en la máquina de "metal descubierto", desde que los autores de estos programas estén dispuestos a trabajar sin nenuma abstracción de hardware o soporte a sistema operativo. Los primeros ordenadores operaron de este manera durante los años de 1950, comienzo de los 1960, eran reiniciados y recargados entre cada ejecución de diferentes programas. Eventualmente, pequeños programas auxiliares como carregadores de programas y depuradores fueron mantenidos en la memoria entre las ejecuciones, o cargados de memoria solamente de lectura . Conforme estas eran desarrolladas, ellas formaron la base del que después se haría el núcleo de los sistemas operativos. La abordagem de "metal descubierto" aún es usada hoy en algunos consoles de vídeo-juego y sistemas embarcados, pero en el general, ordenadores nuevos usan sistemas operativos y núcleos modernos.

En 1969 el RC 4000 Multiprogramming System introdujo la filosofía de desarrollo de sistemas de pequeño nucleus "en la cual sistemas operativos para diferentes propósitos podrían ser creados de manera metódica",[50] algo que podría ser llamado de abordagem de micronúcleo.

sistemas operativos de tiempo compartido

En la década precediendo el fenómeno Unix, ordenadores aumentaron mucho en poder de procesamiento — al punto donde operadores de ordenador estaban buscando nuevos modos de conseguir con que las personas usen el tiempo libre en sus ordenadores. Una de las mayores evoluciones durantes esta era fue el tiempo compartido, donde un número de usuarios conseguiría pequeñas parcelas del tiempo del ordenador, en una tasa que parecería que ellos estaban cada uno conectado su propia máquina, aunque más lenta.[51]

El desarrollo de los sistemas de tiempo compartido llevó a incontables problemas. Uno de ellos fue que usuarios, particularmente en universidades, donde los sistemas estaban siendo desarrollados, parecían intentar hackear el sistema para conseguir más tiempo de procesamiento . Por esta razón, seguridad y controles de acceso se hicieron un foco principal del proyecto Multics en 1965.[52] Otro problema corriente era gestionar apropiadamente los recursos del sistema: usuarios gastaban la mayor parte del tiempo iniciando en la pantalla y pensando en vez de realmente utilizar los recursos del ordenador, y el sistema de tiempo compartido debería dar tiempo de procesamiento para un usuario activo durante estos periodos. Por fin, típicamente los sistemas ofrecían una jerarquía de memoria de varias capas de profundidad, y particionar este recurso caro llevó a un gran desarrollo en los sistemas de memoria virtual.

UNIX

Error al crear miniatura:
Diagrama de la relación de familia de predecesor/sucesor para los sistemas tipo unix.

Durante la fase de proyecto del Unix, los programadores decidieron modelar todo dispositivo de alto nivel como un archivo, por qué ellos creían que el propósito de la computación era la transformación de datos.[53] Por ejemplo, impresoras eran representadas como un "fichero" en una localización conocida — cuando datos eran copiar# a el archivo, ella los imprimía. Otros sistemas, para suministrar una funcionalidad similar, poseen la tendencia de virtualizar dispositivos en un nivel más bajo — o sea, ambos dispositivos y ficheros serían ejemplares de algún concepto de nivel inferior. Virtualizar el sistema a nivel de ficheros permitió a los usuarios manipular todo el sistema usando sus conceptos y herramientas de gestión de ficheros, simplificando la operación dramáticamente. Como una extensión del mismo paradigma, el Unix permite que programadores manipulen archivos usando una serie de pequeños programas, usando el concepto de encadeamento , que permitir a los usuarios completar operaciones en etapas, alimentando un fichero a través de una cadena de herramientas de propósito único. Aunque el resultado final fuera el mismo, usar programas más pequeños de este modo aumentó drásticamente la flexibilidad, así como el uso y desarrollo, permitiendo que el usuario modificara su flujo de trabajo al añadir o remover un programa de la cadena.

En la plantilla Unix, el sistema operativo consiste de dos partes; primera, la enorme colección de programas de utilidades que guían la mayoría de las operaciones.[53] En el Unix, del punto de vista de la programación, la distinción entre los dos es extremadamente tenue; el núcleo es un programa rodando en el modo supervisor[8] que actúa como un carregador de programas y supervisor para los pequeños programas de utilidad que integran el resto del sistema, y suministran trabas y servicios de entrada/salida para estos programas; además de eso, el núcleo no interviene de modo alguno en el espacio de usuario.

Al largo de los años la plantilla de computación cambió, y el tratamiento del Unix de todo como un fichero o flujo de baites no era más universalmente aplicable como antes. Aunque una terminal pudiera ser tratado como un fichero o flujo de baites, de que se exhibía o leía, el mismo no parecía ser verdad para la interfaz gráfica. Red se hizo otro problema. Aún se la comunicación de red pudiera ser comparada al acceso de ficheros, la arquitetura de bajo nícel orientada a paquetes lidava con pedazos discretos de datos y no con ficheros completos. Conforme la capacidad de los ordenadores crecía, el Unix se hacía cada vez más desorganizado con relación a código. Mientras núcleos podían haber 100.000 líneas de código los años 1970 y 1980, núcleos sucesores modernos del núcleo del Unix como el Linux poseen más de 4.5 millones de líneas.[54]

Derivados modernos del Unix son generalmente basados un núcleos monolíticos que cargan módulos. Ejemplos de esto son el Linux, un núcleo monolítico con soporte a núcleos, y diversas distribuciones que lo incluyen, así como los núcleos de las variantes del BSD como FreeBSD, DragonflyBSD, OpenBSD, NetBSD, etc. Además de estas alternativas, desenvolvedores amadores mantiene una comunidad activa de desarrollo de sistemas operativos, llena de núcleos que son creados como pasa-tiempo que acaban compartiendo varios de los recursos con el Linux, y/o los núcleos del FreeBSD, DragonflyBSD, OpenBSD y NetBSD y/o siendo compatibles con ellos.[55]

Mac Los

La Apple lanzó Mac Los por primera vez en 1984, empaquetado con su ordenador personal Macintosh Apple. Por los primeros lanzamiento, el Mac Los (o Sistema de Software, como él fue llamado) #careció de muchos recursos básicos, como multitarefas y un sistema jerárquico. Con el tiempo, el sistema operativo evolucionó y se hizo el Mac Los 9 con algunos recursos añadidos, pero el núcleo se mantuvo básicamente el mismo.[carece de fuentes?] En oposición a esto, el Mac Los X es basada en el Darwin, que utiliza un concepto de núcleo híbrido llamado XNU, creado combinando el núcleo del 4.3BSD y el Mach.[56]

Amiga

Lo Amiga de la Commodore fue lanzado en 1985, y estaba de entre los primeros (y ciertamente más bien sucedidos) ordenadores domésticos a apresenter un sistema operativo con un micronúcleo. El núcleo del Amiga, la exec.library , era pequeña pero capaz, ofreciendo multitarefas rápidas y preemptivas en hardware similar al del Apple Macintosh, y un sistema avanzado de conexiones dinámicas que permitía una expansión fácil.[57]

Microsoft Windows

El Microsoft Windows fue lanzado en 1985 como una extensión para el MS-DOS. Debido a su dependencia de otro sistema operativo, el microsoft windows hasta la versión microsoft windows 95, son consideradas un ambiente operacional (no confunda con sistema operativo). Esta línea de productos continuó por 1980 y 1990, resultando en los lanzamientos de las series Windows 9x, atualizando las capacidades del sistema para endereçamento de 32 bites y multitarefas preemptivo, a través de los años 1990, terminando con el lanzamiento del Windows Me en 2000.

El lanzamiento del Windows XP en octubre de 2001 unió las dos líneas de producto, con la intención de combinar la estabilidad del núcleo NT con los recursos al consumidor de las series 9x.[58] La arquitetura del núcleo del windows nt es considerada híbrida pues la pŕoprio núcleo contiene tareas como el gerenciador de ventanas y el gerenciador de comunicación entre procesos, pero varios subsistemas son ejecutados en el modo de usuario.[59] El punto de quiebra exacto entre espacio de usuario y espacio de núcleo han desplazado conforme la versión, pero la introducción del Arcabouço de driver de espacio de usuario en el windows vista, y decalaje de línea de ejecución en el espacio de usuario en el Windows 7,[60] desplazó más recursos del núcleo núcleo para procesos en el espacio de usuario.

Desarrollo de micronúcleos

Aunque el Mach, desarrollado en la Universidad Carnegie Mellon de 1985 a 1994 , es el micronúcleo de propósito general más conocido, otros micronúcleos fueron desarrollados con objetivos más específicos. Uno familia de micronúcleos L4 (principalmente el micronúcleo L3 y la L4) fue creada para demostrar que micronúcleos no son necesariamente lentos.[47] Implementaciones más nuevas como Fiasco y Pistachio son capaces de ejecutar el Linux junto con otros proceso L4 en espacios de endereçamento separados.[61][62]

QNX es un Sistema operativo de tiempo-real con un proyecto de micronúcleo minimalista que viene siendo desarrollado de este 1982, siendo más bien-sucedido del que el Mach en alcanzar los objetivos del paradigma del micronúcleo.[63] Él es usado principalmente en sistemas embarcados y ẽm situaciones en que el software no puede fallar, como en los brazos robóticos del autobús espacial y máquinas que controlan la moeção de vidrio la tolerancias extremadamente finas, donde un minúsculo error podría costar centenares de miles de reales.

Ver también

Busca Wikiversity La Wikiversidade posee materiales sobre Operating Systems/Kernel Models at:

Notas

Para notas referentes la fuentes, vea la bibliografia abajo.

  1. a b c d y f g h i j k Wulf 74 pp.337-345
  2. a b Roch 2004
  3. a b c d y f g h Liedtke 95
  4. Tanenbaum 79, chapter 1
  5. a b Deitel 82, p.65-66 cap. 3.9
  6. Lorin 81 pp.161-186, Schroeder 77, Shaw 75 pp.245-267
  7. a b c d y f g h Brinch Hansen 70 pp.238-241
  8. a b El nivel de privilegio más alto posee varios nombres por las diferentes arquiteturas, tales como modo supervisor, modo núcleo, CPL0, DPL0, Anillo 0, etc. Vea [Anillo (seguridad)] para más informaciones.
  9. Desarrollo del SO Bona Fide - Tutorial del Bran para Desarrollo de Núcleo, por Brandon Friesen.
  10. Para decalaje de procesos de bajo nivel vea Deitel 82, ch. 10, pp. 249–268.
  11. Levy 1984, p.5
  12. Needham, R.M., Wilkes, M. V. Dominio de protección y gestión de procesos, Computer Journal, vol. 17, en el. 2 de mayo de 1974, pp 117-120.
  13. a b c Silberschatz 1990
  14. Tanenbaum, Andrew S.. Modern Operating Systems.  3rd Edition.ed.  pp.50–51.
  15. a b Denning 1976
  16. a b Swift 2005, p.29 quote: "isolação, control de recursos, verificación de decisión (checagem), y recuperación de errores."
  17. Cook, D.J. Midiendo la protección de la memoria, acepto en la tercera Conferencia Internacional de la Ingeniería de Software, Atlanta, Georgia, Mayo de 1978.
  18. Swift 2005 p.26
  19. Intel Corporation 2002
  20. Houdek et al. 1981
  21. a b Hansen 73, Sección 7.3 p.233 "interacciones entre diferentes niveles de protección exigen la transmisión de mensajes por valor"
  22. a b c Linden 76
  23. Schroeder 72
  24. Stephane Eranian & David Mosberger, Memoria Virtual en el núcleo Linux IBA-64, Prentice Hall PTR, 2002
  25. Silberschatz & Galvin, Conceptos de Ssistema Operativo, 4th ed, pp445 & 446
  26. Hoch, Charles; J. C. Browne (Universidad de Tejas, Austin) (Julio 1980). "An implementation of capabilities on the PDP-11/45" (pdf). ACM SIGOPS Operating Systems Review 14 (3): 22–32. DOI:10.1145/850697.850701.
  27. a b Una Abordagem la Seguridad Basada en Lenguaje, Schneider F., Morrissett G. (Universidad Cornell) y Harper R. (Universidad Carnegie Mellon).
  28. a b c P. A. Loscocco, S. D. Smalley, P. A. Muckelbauer, R. C. Taylor, S. J. Turner, and J. F. Farrell. La Inevitabilidade del Futuro: La Presunción Falsa de Seguridad en el Ambiente de Computación Moderna. En procedimientos de la 21ª Conferencia Nacional de Seguridad de Sistemas de Información, páginas 303–314, Oct. de 1998. [1].
  29. J. Lepreau y otros. La Relevancia Persistente del Ssistema Operativo Local a los Aplicativos Globales. Procedimientos de la 7ª ACM SIGOPS Eurcshelf/book001/book001.html Seguridad de la Información: Una Colección Integrada de Dissertações], IEEE Comp. 1995.
  30. J. Anderson, Estudio de Planificación de Seguridad de Ordenadores, Air Fuerce Elect. Systems Div., ESD-TR-73-51, Octubre de 1972.
  31. * Jerry H. Saltzer, Mike D. Schroeder (Septiembre de 1975). "La protección de información en sistemas de ordenador". Proceedings of the IEEE 63 (9): 1278–1308. DOI:10.1109/PROC.1975.9939.
  32. Jonathan S. Shapiro; Jonathan M. Smith; David J. Farber. "EROS: un sistema de capacidades rápido". Procedimientos de la 70º simpósio ACM sobre principios de sistemas operativos.
  33. Dijkstra, Y. W. Procesos Secuenciales Cooperadores. Math. Dep., Technological U., Eindhoven, Sep. 1965.
  34. SHARER, un sistema de reparto de tiempo para el CDC 6600. Página visitada en 2007-01-07.
  35. Supervisores Dinámicos - su proyecto y construcción. Página visitada en 2007-01-07.
  36. Baiardi 1988
  37. a b Levin 75
  38. Denning 1980
  39. Jürgen Nehmer La Imoralidade de los sistemas operativos, o: Investigación en los sistemas operativos aún es Justificável? Notas en Ciencia de la Computación; Vol. 563. Proceso del Taller Internacional sobre sistemas operativos de los años 90 en delante. pp. 77 - 83 (1991) ISBN 3-540-54987-0 [2] citação: "Los últimos 25 años mostraron que la investigación sobre arquiteturas de sistemas operativos tuvo poco efecto en los principales sistemas operativos." [3]
  40. Levy 84, p.1 citação: "Aunque la complejidad de los aplicativos de ordenador aumenta anualmente, la arquitetura de hardware subyacente para aplicativos se mantuvo intocada por décadas."
  41. a b c Levy 84, p.1 citação: "Arquiteturas convencionales soportan un único modo privilegiado de operación. Esta estructura lleva a un desarrollo monolítico; cualquier módulo necesitando de protección debe ser parte del único núcleo del sistema operativo. Si, al contrario, cualquier módulo pudiera ejecutar en un dominio protegido, sistemas podrían ser construidos como una colección de módulos independientes ampliables por cualquier usuario."
  42. Códigos Abiertos : Voces de la Revolución del Código Abierto.
  43. Endereçamento virtual es comumente más obtenido a través de la unidad de gestión de memoria incorporado.
  44. Registros del debate entre Torvalds y Tanenbaum pueden ser encontrados en dina.dk, groups.google.con, oreilly.con y Casa de campo de Andrew Tanenbaum
  45. a b Matthew Russell. Lo que es Darwin (y como él sostiene el Mac Los X). El'Reilly Medía. citação: "La naturaleza fuertemente unida del núcleo monolítico permite hacerlo eficiente en el uso del hardware subyacente [...] Micronúcleos, por otro lado, ruedan un número muy mayor de procesos en el espacio de usuario. [...] Infelizmente, estos beneficios traen el coste de micronúcleos tengan la necesidad de pasar informaciones dentro y fuera del espacio del núcleo a través de un procesos llamado cambio de contexto. Cambios de contexto traen una degradación de performance considerable." Estas afirmaciones no forman parte de un artículo revisto por partes.
  46. Härtig 97
  47. a b La familia de núcleos L4 - Visión general.
  48. Arquitetura de nanonúcleo del KeyKOS.
  49. Ssistema Operativo de Exonúcleo del MIT.
  50. Hansen 2001 (los), pp.17-18
  51. Versión BSTJ de la C.ACM Periódico Unix.
  52. Introducción y Visión General del Sistema Multics, por F. J. Corbató y V. A. Vissotsky..
  53. a b El Sistema UNIX — La Única Especificación del Unix.
  54. Linux 2.6: Él Vale Más!, por David A. Wheeler, 12 de octubre de 2004.
  55. Esta comunidad se reúne en su mayoría en el Desarrollo de SO Bona Fide, El Fórum de Mensajes Mega-Tokyo y otras casas de campo de entusiastas de sistemas operativos.
  56. XNU: El núcleo.
  57. Sheldon Leemon. Lo que hace eso tan óptimo! (Amiga Commodore). Creative Computing. Página visitada en 2006-02-05.
  58. LinuxWorld IDC: Consolidación de Windows acontece.
  59. Histórico del Windows: Histórico de Productos de Mesa de Trabajo.
  60. Holwerda, Thom (7 de febrero de 2009). Windows 7 gana decalaje de espacio de usuario. OSNews. Página visitada en 2009-02-28.
  61. El micronúcleo Fiasco - Visión general.
  62. L4Ka - La familia L4 de micronúcleos y amigos.
  63. Visión General del Ssistema Operativo de Tiempo-real.

Referencias

incluido en libro: Classic operating systems: from batch processing te lo distributed systems.  New York,: Per Brinch Hansen. pp.1–36.

Lecturas importantes

Conexiones externas