Ponencia: Formas de implementar entornos de software de aplicación. Arquitectura, propósito y funciones de los sistemas operativos Tareas y ejercicios

Si bien muchas características arquitectónicas del sistema operativo están directamente relacionadas solo con los programadores del sistema, el concepto de múltiples aplicaciones (operativas) está directamente relacionado con las necesidades de los usuarios finales: la capacidad del sistema operativo para ejecutar aplicaciones escritas para otros sistemas operativos. Esta propiedad del sistema operativo se llama compatibilidad.

La compatibilidad de aplicaciones puede ser a nivel binario ya nivel de código fuente. Las aplicaciones generalmente se almacenan en el sistema operativo como archivos ejecutables que contienen imágenes binarias de código y datos. La compatibilidad binaria se logra cuando puede tomar un programa ejecutable y ejecutarlo en un entorno de sistema operativo diferente.

La compatibilidad a nivel de fuente requiere que se incluya el compilador apropiado en el software de la computadora en la que se ejecutará la aplicación, así como la compatibilidad a nivel de bibliotecas y llamadas al sistema. Esto requiere la recompilación del código fuente de la aplicación en un nuevo módulo ejecutable.

La compatibilidad a nivel de fuente es importante principalmente para los desarrolladores de aplicaciones que tienen estas fuentes a su disposición. Pero para los usuarios finales, solo la compatibilidad binaria tiene importancia práctica, ya que solo en este caso pueden usar el mismo producto en diferentes sistemas operativos y en diferentes máquinas.

El tipo de compatibilidad posible depende de muchos factores. El más importante de ellos es la arquitectura del procesador. Si el procesador usa el mismo conjunto de instrucciones (quizás con adiciones, como en el caso de la PC de IBM: conjunto estándar + multimedia + gráficos + transmisión) y el mismo rango de direcciones, entonces la compatibilidad binaria se puede lograr de manera bastante simple. Para ello, se deben cumplir las siguientes condiciones:

• La API que utiliza la aplicación debe ser compatible con el sistema operativo dado;
• la estructura interna del archivo ejecutable de la aplicación debe coincidir con la estructura de los archivos ejecutables del sistema operativo.

Si los procesadores tienen arquitecturas diferentes, además de las condiciones anteriores, es necesario organizar la emulación del código binario. Por ejemplo, se usa ampliamente la emulación de las instrucciones del procesador Intel en el procesador Motorola 680x0 de Macintosh. El emulador de software en este caso selecciona secuencialmente la instrucción binaria del procesador Intel y ejecuta la subrutina equivalente escrita en las instrucciones del procesador Motorola. Dado que el procesador Motorola no tiene exactamente los mismos registros, banderas, ALU interna, etc., que los procesadores Intel, también debe simular (emular) todos estos elementos utilizando sus propios registros o memoria.

Esta es una operación simple pero muy lenta, ya que una sola instrucción de Intel es mucho más rápida que la secuencia de instrucciones de Motorola que la emula. La salida en tales casos es el uso de los llamados entornos de software de aplicación o entornos operativos. Uno de los componentes de dicho entorno es el conjunto de funciones de la API que el sistema operativo expone a sus aplicaciones. Para reducir el tiempo de ejecución de los programas de otras personas, los entornos de aplicación imitan las llamadas a funciones de biblioteca.

La eficacia de este enfoque se debe al hecho de que la mayoría de los programas actuales se ejecutan bajo GUI (interfaces gráficas de usuario) como Windows, MAC o UNIX Motif, mientras que las aplicaciones pasan del 60 al 80 % del tiempo realizando funciones de GUI y otras llamadas a la biblioteca del sistema operativo. . Es esta propiedad de las aplicaciones la que permite que los entornos de aplicación compensen el gran tiempo dedicado a la emulación de programas comando por comando. Un entorno de aplicación de software cuidadosamente diseñado contiene bibliotecas que imitan bibliotecas GUI, pero escritas en código nativo. Así, se consigue una importante aceleración de la ejecución de programas con la API de otro sistema operativo. De lo contrario, este enfoque se llama traducción, para distinguirlo del proceso más lento de emular una instrucción a la vez.

Por ejemplo, para un programa de Windows que se ejecuta en un Macintosh, al interpretar los comandos de un procesador Intel rendimiento puede ser muy bajo. Pero cuando se llama a una función GUI, se abre una ventana, etc., el módulo del sistema operativo que implementa el entorno de aplicación de Windows puede interceptar esta llamada y redirigirla a la rutina de apertura de ventanas compilada para el procesador Motorola 680x0. Como resultado, en tales secciones del código, la velocidad del programa puede alcanzar (y posiblemente superar) la velocidad de trabajo en su propio procesador.

Para que un programa escrito para un sistema operativo se ejecute en otro sistema operativo, no basta con garantizar la compatibilidad con la API. Los conceptos subyacentes a los diferentes sistemas operativos pueden entrar en conflicto entre sí. Por ejemplo, en un sistema operativo, se puede permitir que una aplicación controle los dispositivos de E / S, en otro, estas acciones son prerrogativa del sistema operativo.

Cada sistema operativo tiene sus propios mecanismos de protección de recursos, sus propios algoritmos de manejo de errores y excepciones, su propia estructura de procesador y esquema de administración de memoria, su propia semántica de acceso a archivos y su propia interfaz gráfica de usuario. Para garantizar la compatibilidad, es necesario organizar una coexistencia sin conflictos dentro del mismo sistema operativo de varias formas de administrar los recursos de la computadora.

Hay varias opciones para crear entornos de múltiples aplicaciones, que difieren tanto en las características de las soluciones arquitectónicas como en la funcionalidad que proporciona distintos grados de portabilidad de la aplicación. Una de las opciones más obvias para implementar múltiples entornos de aplicaciones se basa en la estructura en capas estándar del sistema operativo.

Otra forma de construir múltiples entornos de aplicaciones se basa en el enfoque de microkernel. Al mismo tiempo, es muy importante señalar la diferencia básica, común a todos los entornos de aplicación, entre los mecanismos del sistema operativo y las funciones de alto nivel específicas de cada uno de los entornos de aplicación que resuelven problemas estratégicos. De acuerdo con arquitectura micronuclear todas las funciones del sistema operativo son implementadas por el microkernel y los servidores en modo usuario. Es importante que el entorno de la aplicación esté diseñado como un servidor de modo de usuario independiente y no incluya los mecanismos subyacentes.

Las aplicaciones, utilizando la API, realizan llamadas al sistema al entorno de la aplicación correspondiente a través del microkernel. El entorno de la aplicación procesa la solicitud, la ejecuta (quizás pidiendo ayuda a las funciones básicas del microkernel para esto) y envía el resultado a la aplicación. Durante la ejecución de la solicitud, el entorno de la aplicación, a su vez, tiene que acceder a los mecanismos del sistema operativo subyacentes implementados por el microkernel y otros servidores del sistema operativo.

Este enfoque para diseñar múltiples entornos de aplicaciones tiene todas las ventajas y desventajas de la arquitectura de micro-kernel, en particular:

• es muy fácil agregar y excluir entornos de aplicaciones, lo cual es consecuencia de la buena extensibilidad de los sistemas operativos de micro-kernel;
• si uno de los ambientes de aplicación falla, el resto permanece operativo, lo que contribuye a la confiabilidad y estabilidad del sistema en su conjunto;
• El bajo rendimiento de los sistemas operativos de microkernel afecta la velocidad de las herramientas de aplicación y, por lo tanto, la velocidad de las aplicaciones.

Como resultado, cabe señalar que la creación dentro de un sistema operativo de varias herramientas de aplicación para ejecutar aplicaciones de diferentes sistemas operativos es una forma que le permite tener una sola versión del programa y transferirlo entre diferentes sistemas operativos. Múltiples entornos de aplicaciones aseguran la compatibilidad binaria de un sistema operativo determinado con aplicaciones escritas para otros sistemas operativos.

1.9. Las máquinas virtuales como un enfoque moderno para la implementación de múltiples entornos de aplicaciones

El concepto de "monitor de máquina virtual" (VMM) surgió a finales de los años 60 como un software nivel de abstracción, que dividía la plataforma de hardware en varias máquinas virtuales. Cada una de estas máquinas virtuales (VM) era tan similar a la máquina física subyacente que la existente software se podría realizar en él sin cambios. En ese momento, las tareas informáticas generales se realizaban en mainframes caros (como IBM /360), y los usuarios apreciaban mucho la capacidad del VMM para asignar recursos escasos entre varias aplicaciones.

En las décadas de 1980 y 1990, el costo de los equipos de cómputo disminuyó de manera significativa y efectiva. sistema operativo multitarea, lo que redujo el valor del VMM a los ojos de los usuarios. Los mainframes dieron paso a las minicomputadoras y luego a las PC, y desapareció la necesidad de un VMM. Como resultado, la arquitectura de la computadora simplemente desapareció. hardware para su efectiva implementación. A fines de los años 80, en la ciencia y en la producción de VMM, se percibían solo como una curiosidad histórica.

Hoy MVM vuelve a ser el centro de atención. Intel, AMD, Sun Microsystems e IBM están creando estrategias de virtualización, y los laboratorios y las universidades están desarrollando enfoques basados ​​en máquinas virtuales para abordar los problemas de movilidad, seguridad y capacidad de administración. ¿Qué pasó entre la renuncia del MVM y su reactivación?

En la década de 1990, los investigadores de la Universidad de Stanford comenzaron a explorar la posibilidad de utilizar máquinas virtuales para superar las limitaciones del hardware y los sistemas operativos. Surgieron problemas con las computadoras con procesamiento paralelo masivo (Massively Parallel Processing, MPP), que eran difíciles de programar y no podían ejecutar los sistemas operativos existentes. Los investigadores descubrieron que las máquinas virtuales podrían hacer que esta arquitectura engorrosa sea lo suficientemente similar a las plataformas existentes para aprovechar los sistemas operativos estándar. De este proyecto surgieron las personas y las ideas que se convirtieron en la mina de oro de VMware (www.vmware.com), el primer proveedor de VMM para computadoras convencionales.

Por extraño que parezca, el desarrollo de sistemas operativos modernos y la disminución de los costos de hardware generaron problemas que los investigadores esperaban resolver con los VMM. El bajo costo de los equipos contribuyó a la rápida difusión de las computadoras, pero a menudo se subutilizaban y requerían espacio y esfuerzo adicionales para su mantenimiento. Y las consecuencias del crecimiento de la funcionalidad del sistema operativo se han convertido en su inestabilidad y vulnerabilidad.

Para reducir el impacto de los bloqueos del sistema y protegerse contra los piratas informáticos, los administradores del sistema han recurrido nuevamente a la monotarea. modelo computacional(con una aplicación en una máquina). Esto resultó en costos adicionales debido a mayores requisitos de hardware. Mover aplicaciones de diferentes máquinas físicas a máquinas virtuales y consolidar esas máquinas virtuales en unas pocas plataformas físicas ha mejorado la utilización del hardware, ha reducido los costos de administración y ha reducido el espacio físico. Por lo tanto, la capacidad de los VMM para multiplexar hardware, esta vez en nombre de la consolidación de servidores y la computación de utilidades, los ha devuelto a la vida.

En la actualidad, el VMM se ha convertido no tanto en una herramienta para organizar la multitarea como una vez se concibió, sino en una solución a los problemas de seguridad, movilidad y confiabilidad. En muchos sentidos, VMM brinda a los desarrolladores de sistemas operativos la capacidad de desarrollar funciones que no son posibles con los complejos sistemas operativos actuales. Las funciones como la migración y la protección son mucho más convenientes para implementar en el nivel de VMM, lo que mantiene la compatibilidad con versiones anteriores al implementar soluciones de sistema operativo innovadoras y al mismo tiempo mantener los logros anteriores.

La virtualización es una tecnología en evolución. En términos generales, la virtualización le permite separar el software de la infraestructura de hardware subyacente. De hecho, rompe la conexión entre un determinado conjunto de programas y una computadora específica. Monitor de máquina virtual se separa software del hardware y forma una capa intermedia entre el software que ejecuta máquinas virtuales y el hardware. Este nivel permite que VMM controle completamente el uso de los recursos de hardware. sistemas operativos invitados (GuestOS) que se ejecutan en la máquina virtual.

El VMM crea una vista unificada del hardware subyacente para que las máquinas físicas de diferentes proveedores con diferentes subsistemas de E/S tengan el mismo aspecto y la VM se ejecute en cualquier hardware disponible. Sin preocuparse por las máquinas individuales, con sus estrechas interrelaciones entre el hardware y el software, los administradores pueden tratar el hardware simplemente como un grupo de recursos para brindar cualquier servicio bajo demanda.

Gracias a encapsulación completa estados de software en la máquina virtual, el monitor VMM puede asignar la máquina virtual a cualquier recurso de hardware disponible e incluso moverla de una máquina física a otra. La tarea de equilibrar la carga en un grupo de máquinas se vuelve trivial y existen formas confiables de lidiar con las fallas de hardware y hacer crecer el sistema. Si necesita apagar una computadora fallida o volver a poner en línea una nueva, el VMM puede redistribuir las máquinas virtuales en consecuencia. La máquina virtual es fácil de replicar, lo que permite a los administradores proporcionar rápidamente nuevos servicios según sea necesario.

La encapsulación también significa que el administrador puede pausar o reanudar la máquina virtual en cualquier momento, así como guardar el estado actual de la máquina virtual o devolverla al estado anterior. Con la capacidad de deshacer universal, los bloqueos y los errores de configuración se pueden solucionar fácilmente. La encapsulación es la base de un modelo de movilidad generalizado, ya que una VM suspendida puede copiarse a través de la red, almacenarse y transportarse en medios extraíbles.

El VMM desempeña el papel de intermediario en todas las interacciones entre la VM y el hardware subyacente, lo que permite la ejecución de muchas máquinas virtuales en una sola plataforma de hardware y garantiza su aislamiento confiable. VMM le permite ensamblar un grupo de máquinas virtuales con bajos requisitos de recursos en una sola computadora, lo que reduce el costo de hardware y la necesidad de espacio de producción.

El aislamiento completo también es importante para la confiabilidad y la seguridad. Las aplicaciones que solían ejecutarse en una sola máquina ahora se pueden distribuir en diferentes máquinas virtuales. Si uno de ellos provoca un bloqueo del sistema operativo como resultado de un error, las demás aplicaciones se aislarán y seguirán funcionando. Si una de las aplicaciones se ve amenazada por un ataque externo, el ataque se localizará dentro de la máquina virtual "comprometida". Por lo tanto, el VMM es una herramienta para reestructurar el sistema para mejorar su estabilidad y seguridad, sin requerir espacio adicional y esfuerzos de administración, que son necesarios cuando se ejecutan aplicaciones en máquinas físicas separadas.

El VMM debe vincular la interfaz de hardware a la VM mientras conserva el control total sobre la máquina subyacente y los procedimientos para interactuar con su hardware. Para lograr este objetivo, existen diferentes métodos basados ​​en ciertos compromisos técnicos. Al buscar tales compromisos, se tienen en cuenta los requisitos principales para el VMM: compatibilidad, rendimiento y sencillez La compatibilidad es importante porque la principal ventaja de un VMM es la capacidad de ejecutar aplicaciones heredadas. Rendimiento determina la cantidad de sobrecarga para la virtualización: los programas en la máquina virtual deben ejecutarse a la misma velocidad que en la máquina real. La simplicidad es necesaria porque la falla del VMM provocará la falla de todas las máquinas virtuales que se ejecutan en la computadora. En particular, un aislamiento confiable requiere que el VMM esté libre de errores que los atacantes puedan usar para destruir el sistema.

En lugar de pasar por una reescritura de código compleja del sistema operativo invitado, puede realizar algunos cambios en el sistema operativo host cambiando algunas de las partes del kernel que más "interfieren". Este enfoque se llama paravirtualización. Está claro que en este caso solo el autor puede adaptar el kernel del sistema operativo y, por ejemplo, Microsoft no muestra ningún deseo de adaptar el popular kernel de Windows 2000 a las realidades de máquinas virtuales específicas.

En la paravirtualización, el desarrollador de VMM redefine la interfaz de la máquina virtual, reemplazando un subconjunto del conjunto de instrucciones original que no es adecuado para la virtualización con equivalentes más convenientes y eficientes. Tenga en cuenta que aunque el sistema operativo debe ser portado para ejecutarse en dichas máquinas virtuales, la mayoría de las aplicaciones comunes pueden ejecutarse sin cambios.

La mayor desventaja de la paravirtualización es la incompatibilidad. Ningún sistema operativo, diseñado para ejecutarse bajo el control de un monitor VMM paravirtualizado, debe ser portado a esta arquitectura, para lo cual es necesario negociar la cooperación con los proveedores de sistemas operativos. Además, los sistemas operativos heredados no se pueden usar y las máquinas existentes no se pueden reemplazar fácilmente por máquinas virtuales.

Para lograr un alto rendimiento y compatibilidad en la virtualización x86, VMware ha desarrollado un nuevo método de virtualización que combina la ejecución directa tradicional con una traducción de código binario rápida y sobre la marcha. En la mayoría de los sistemas operativos modernos, los modos de operación del procesador durante la ejecución de los programas de aplicación ordinarios se virtualizan fácilmente y, por lo tanto, se pueden virtualizar a través de la ejecución directa. Los modos privilegiados inadecuados para la virtualización pueden ser ejecutados por un traductor de código binario, corrigiendo los comandos x86 "inconvenientes". El resultado es un alto rendimiento. máquina virtual, que es totalmente compatible con el hardware y mantiene una compatibilidad total con el software.

El código convertido es muy similar a los resultados de la paravirtualización. Las instrucciones ordinarias se ejecutan sin cambios, mientras que las instrucciones que requieren un procesamiento especial (como POPF y las instrucciones de registro de segmento de código de lectura) son reemplazadas por el traductor con secuencias de instrucciones que son similares a las requeridas para la ejecución en una máquina virtual paravirtualizada. Sin embargo, existe una diferencia importante: en lugar de cambiar el código fuente del sistema operativo o de las aplicaciones, el traductor binario cambia el código la primera vez que se ejecuta.

Aunque hay algunos costos adicionales involucrados en la traducción del código binario, son insignificantes bajo cargas de trabajo normales. El traductor procesa solo una parte del código y la velocidad de ejecución del programa se vuelve comparable a la velocidad de ejecución directa, tan pronto como la memoria caché está llena.

Crear un entorno de aplicación completo que sea totalmente compatible con el entorno de otro sistema operativo es una tarea bastante difícil, estrechamente relacionada con la estructura del sistema operativo. Hay varias opciones para crear entornos de múltiples aplicaciones, que difieren tanto en las características de las soluciones arquitectónicas como en la funcionalidad que proporciona distintos grados de portabilidad de la aplicación. .

En muchas versiones del sistema operativo UNIX, el traductor del entorno de la aplicación se implementa como una aplicación normal. En los sistemas operativos creados con el concepto de microkernel, como Windows NT o Workplace OS, los entornos de aplicaciones se ejecutan como servidores en modo de usuario. Y en OS/2, con su arquitectura más simple, la organización de los entornos de aplicación está profundamente integrada en el sistema operativo. Una de las opciones más obvias para implementar múltiples entornos de aplicaciones se basa en la estructura del sistema operativo en capas estándar. .

Arroz. 3.13. Entornos de aplicaciones que traducen llamadas al sistema

Desafortunadamente, el comportamiento de casi todas las funciones que componen la API de un sistema operativo, por regla general, difiere significativamente del comportamiento de las funciones correspondientes de otro.

En otra implementación de múltiples entornos de aplicaciones, el sistema operativo tiene múltiples interfaces de programación de aplicaciones del mismo nivel. En la fig. El ejemplo de sistema operativo de la figura 3.14 admite aplicaciones escritas para OS1, OS2 y OS3. Para ello, las interfaces de programación de aplicaciones de todos estos sistemas operativos se sitúan directamente en el espacio kernel del sistema: API OS1, API OS2 y API OS3. En esta variante, las funciones del nivel de API llaman a las funciones del nivel del sistema operativo subyacente, que debe ser compatible con los tres entornos de aplicación generalmente incompatibles.

Los diferentes sistemas operativos administran la hora del sistema de manera diferente, usan diferentes formatos de hora del día, dividen el tiempo de la CPU en función de sus propios algoritmos, etc. El núcleo implementa las funciones de cada API teniendo en cuenta las características específicas del sistema operativo correspondiente, incluso si tienen un propósito similar. Por ejemplo, como ya se mencionó, la función de creación de procesos funciona de manera diferente para una aplicación UNIX y una aplicación OS/2. De manera similar, al finalizar un proceso, el kernel también necesita determinar a qué sistema operativo pertenece el proceso. Si este proceso se creó a pedido de una aplicación UNIX, entonces, durante su finalización, el núcleo debe enviar una señal al proceso principal, como se hace en el sistema operativo UNIX. Y cuando finaliza un proceso OS/2, el kernel debe tener en cuenta que otro proceso OS/2 no puede reutilizar el ID del proceso. Para que el kernel seleccione la implementación deseada de una llamada al sistema, cada proceso debe pasar un conjunto de características de identificación al kernel.

Arroz. 3.14 Implementación de la interoperabilidad basada en múltiples API de pares

Otra forma de construir múltiples entornos de aplicaciones se basa en el enfoque de microkernel.. Al mismo tiempo, es muy importante separar los mecanismos del sistema operativo básicos, comunes a todos los entornos de aplicación, de las funciones de alto nivel específicas de cada uno de los entornos de aplicación que resuelven problemas estratégicos.

Bajo la arquitectura de microkernel, todas las funciones del sistema operativo son implementadas por los servidores de microkernel y de modo de usuario. Es importante que cada entorno de aplicación esté diseñado como un servidor de modo de usuario independiente y no incluya los mecanismos subyacentes (Fig. 3.15). Las aplicaciones, utilizando la API, realizan llamadas al sistema al entorno de la aplicación correspondiente a través del microkernel. El entorno de la aplicación procesa la solicitud, la ejecuta (quizás pidiendo ayuda a las funciones básicas del microkernel para esto) y envía el resultado a la aplicación. Durante la ejecución de la solicitud, el entorno de la aplicación, a su vez, tiene que acceder a los mecanismos del sistema operativo subyacentes implementados por el microkernel y otros servidores del sistema operativo.

Este enfoque para diseñar múltiples entornos de aplicaciones tiene todas las ventajas y desventajas de una arquitectura de micronúcleo, en particular:

§ es muy fácil agregar y excluir entornos de aplicaciones, lo cual es una consecuencia de la buena extensibilidad de los sistemas operativos de microkernel;

§ la confiabilidad y la estabilidad se expresan en el hecho de que si uno de los entornos de aplicación falla, todos los demás permanecen operativos;

§ El bajo rendimiento de los sistemas operativos microkernel afecta la velocidad de los entornos de aplicación y, por lo tanto, la velocidad de ejecución de la aplicación.

Arroz. 3.15. Enfoque de microkernel para la implementación de múltiples entornos de aplicaciones

La creación de varios entornos de aplicaciones dentro de un sistema operativo para ejecutar aplicaciones de diferentes sistemas operativos es una forma que le permite tener una sola versión del programa y transferirla entre sistemas operativos. Múltiples entornos de aplicaciones aseguran la compatibilidad binaria de un sistema operativo determinado con aplicaciones escritas para otros sistemas operativos. Como resultado, los usuarios tienen una mayor libertad de elección del sistema operativo y un acceso más fácil a un software de calidad.

Conclusiones:

§ La estructuración más simple del sistema operativo consiste en dividir todos los componentes del sistema operativo en módulos que realizan las funciones principales del sistema operativo (núcleo) y módulos que realizan funciones auxiliares del sistema operativo. Los módulos auxiliares del sistema operativo se fabrican en forma de aplicaciones (utilidades y programas de procesamiento del sistema) o en forma de bibliotecas de procedimientos. Los módulos auxiliares se cargan en la RAM solo mientras duran sus funciones, es decir, son transitivos. Los módulos del kernel están constantemente en la RAM, es decir, son residentes.

§ Si hay soporte de hardware para modos con diferentes niveles de autoridad, la estabilidad del sistema operativo se puede aumentar mediante la ejecución de funciones del núcleo en modo privilegiado y módulos auxiliares del sistema operativo y aplicaciones en modo de usuario. Esto hace posible proteger los códigos y datos del sistema operativo y las aplicaciones del acceso no autorizado. El sistema operativo puede actuar como árbitro en disputas de aplicaciones sobre recursos.

§ El kernel, al ser un elemento estructural del SO, a su vez, puede descomponerse lógicamente en las siguientes capas (comenzando desde la más baja):

§ componentes del sistema operativo dependientes de la máquina;

§ mecanismos básicos del kernel;

§ administradores de recursos;

§ Interfaz de llamada al sistema.

§ En un sistema multicapa, cada capa sirve a la capa superior, realizando para ella un determinado conjunto de funciones que forman una interfaz entre capas. Basándose en las funciones de la capa subyacente, la siguiente capa en la jerarquía crea sus propias funciones, más complejas y más poderosas, que, a su vez, resultan ser primitivas para crear funciones aún más poderosas de la capa superior. La organización multicapa del sistema operativo simplifica enormemente el desarrollo y la modernización del sistema.

§ Cualquier sistema operativo interactúa con el hardware de la computadora para resolver sus problemas, a saber: soporte para modo privilegiado y traducción de direcciones, medios para cambiar procesos y proteger áreas de memoria, el sistema de interrupción y el temporizador del sistema. Esto hace que la máquina del sistema operativo dependa de una plataforma de hardware en particular.

§ La portabilidad del sistema operativo se puede lograr observando las siguientes reglas. Primero, la mayor parte del código debe estar escrito en un idioma cuyos traductores estén disponibles en todas las computadoras donde se supone que se transferirá el sistema. En segundo lugar, la cantidad de partes del código dependientes de la máquina que interactúan directamente con el hardware debe minimizarse tanto como sea posible. En tercer lugar, el código que depende del hardware debe localizarse de forma segura en varios módulos.

§ La arquitectura microkernel es una alternativa a la forma clásica de construir un SO, según la cual todas las funciones principales del SO que componen el kernel multicapa se ejecutan en modo privilegiado. En los sistemas operativos de microkernel, solo una parte muy pequeña del sistema operativo, llamada microkernel, permanece ejecutándose en modo privilegiado. Todas las demás funciones del kernel de alto nivel están empaquetadas como aplicaciones en modo de usuario.

§ Los sistemas operativos Microkernel cumplen con la mayoría de los requisitos de los sistemas operativos modernos, siendo portátiles, extensibles, confiables y creando un buen requisito previo para admitir aplicaciones distribuidas. Estos beneficios tienen el costo de un rendimiento reducido, que es el principal inconveniente de la arquitectura de microkernel.

§ Entorno de software de aplicación: un conjunto de herramientas del sistema operativo diseñado para organizar la ejecución de aplicaciones que utilizan un sistema específico de instrucciones de máquina, un tipo específico de API y un formato específico del programa ejecutable. Cada sistema operativo crea al menos un entorno de programación de aplicaciones. El problema es garantizar la compatibilidad de varios entornos de software dentro del mismo sistema operativo. Al crear múltiples entornos de aplicaciones, se utilizan varias soluciones arquitectónicas, conceptos de emulación de código binario y traducción de API.

tareas y ejercicios

1. ¿Cuáles de los siguientes términos son sinónimos?

§ modo privilegiado;

§ modo protegido;

§ modo supervisor;

§ modo de usuario;

§ modo real;

§ Modo núcleo.

2. ¿Es posible, analizando el código binario de un programa, concluir que no se puede ejecutar en modo usuario?

3. ¿Cuáles son las diferencias en el funcionamiento del procesador en los modos privilegiado y de usuario?

4. Idealmente, la arquitectura de microkernel del sistema operativo requiere que solo aquellos componentes del sistema operativo que no se pueden ejecutar en modo de usuario se coloquen en el microkernel. ¿Qué hace que los desarrolladores de sistemas operativos se alejen de este principio y amplíen el kernel trasladando funciones que podrían implementarse como procesos de servidor?

5. ¿Cuáles son los pasos necesarios para desarrollar una variante de sistema operativo móvil para una nueva plataforma de hardware?

6. Describir cómo interactúan las aplicaciones con un sistema operativo que tiene una arquitectura de micronúcleo.

7. ¿Cuáles son los pasos involucrados en la ejecución de una llamada al sistema en un sistema operativo microkernel y un sistema operativo con un kernel monolítico?

8. ¿Puede un programa emulado en un procesador "extranjero" ejecutarse más rápido que en uno "nativo"?

Alternativa de emulación - múltiples entornos de aplicación, que incluye un conjunto de funciones API. Imitan la llamada a las funciones de biblioteca del entorno de la aplicación, pero en realidad llaman a sus bibliotecas internas. Se llama traducción de la biblioteca. Esto es puramente software.

Para que un programa escrito en un sistema operativo funcione en otro, es necesario garantizar una interacción sin conflictos de los métodos de control de procesos en diferentes sistemas operativos.

Formas de implementar entornos de software de aplicación

Según la arquitectura:

1. Entorno de software de aplicación en forma de aplicación (la capa superior del núcleo del sistema operativo nativo).

Modo de operación de usuario, traducción de llamadas al sistema (llamadas API) en llamadas nativas del sistema operativo. Corresponde al sistema operativo multicapa clásico (Unix, Windows).

2. La presencia de varios entornos de aplicación que funcionan por igual. Cada uno en forma de una capa separada del núcleo.

Modo privilegiado de operación. La API llama a las funciones de la capa subyacente (privilegiada) del sistema operativo. La tarea de reconocer y adaptar la llamada recae en el sistema. Requiere una gran cantidad de recursos. Se pasa un conjunto de características de identificación al kernel para su reconocimiento.

3. Principio micronuclear.

Cualquier entorno de aplicación está diseñado como un servidor de modo de usuario independiente. Las aplicaciones, utilizando la API, realizan llamadas al sistema al entorno de la aplicación correspondiente a través del microkernel. El entorno de la aplicación procesa la solicitud y devuelve el resultado a través del microkernel. Podría usar funciones de microkernel. Es posible el acceso múltiple a otros recursos (mientras se ejecuta el microkernel).

interfaces del sistema operativo

interfaz del sistema operativo es un sistema de programación de aplicaciones. Regulado por estándares (POSIX, ISO).

1. Interfaz de usuario- se implementa utilizando módulos de software especiales que traducen las solicitudes de los usuarios en un lenguaje de comandos especial en solicitudes al sistema operativo.

El conjunto de tales módulos se llama Interprete. Realiza análisis léxico y sintáctico y ejecuta el comando en sí mismo o lo pasa a la API.

2. API- está destinado a proporcionar programas de aplicación con recursos del sistema operativo e implementar otras funciones. La API describe un conjunto de funciones, procedimientos que pertenecen al kernel y complementos del sistema operativo. La API utiliza programas del sistema tanto dentro como fuera del sistema operativo, utilizando programas de aplicación a través de un entorno de programación.

En el centro de la provisión de recursos al sistema operativo se encuentra, en última instancia, una interrupción de software. Su implementación según el sistema (vectorial, tabular). Hay varias opciones para implementar la API a nivel del sistema operativo (más rápido, más bajo), a nivel de programación del sistema (más abstracto, menos rápido) y a nivel de una biblioteca externa de procedimientos y funciones (pequeño conjunto).

Interfaces del sistema operativo Linux:

software (sin intermediarios - la ejecución real de llamadas al sistema);

línea de comando (intermediario: un shell del intérprete de Shell que redirige la llamada);

Gráfico (intermediarios - Shell + shell gráfico).

sistema de archivos

sistema de archivos - esto es parte del sistema operativo, diseñado para proporcionar a los usuarios una interfaz conveniente para trabajar con archivos y garantizar el uso de archivos almacenados en medios externos (disco duro + RAM) por varios usuarios y procesos.

Según la composición del SF:

la totalidad de todos los archivos en el disco en todos los medios,

conjuntos de estructuras de datos utilizados para administrar archivos, como directorios de archivos, descriptores de archivos, tablas de asignación de espacio en disco libre y usado,

un conjunto de herramientas de software del sistema que implementan la gestión de archivos, en particular: creación, destrucción, lectura, escritura, denominación, búsqueda y otras operaciones en archivos.

Uno de los atributos de los archivos son los nombres de archivo, una forma de identificar un archivo para el usuario. En aquellos sistemas en los que se permiten varios nombres, al archivo se le asigna un inodo utilizado por el kernel del sistema operativo. Los nombres en diferentes sistemas operativos se establecen de manera diferente.

Considere la estructura de un sistema de programación de compilación abierto, multilingüe abstracto y el proceso de desarrollo de aplicaciones en este entorno (Fig. 1.4).

Se prepara un programa en el idioma de origen (módulo de origen) con la ayuda de editores de texto y se alimenta como archivo de texto o sección de biblioteca a la entrada del traductor.

La traducción de un programa fuente es un procedimiento para convertir un módulo fuente en una forma de objeto intermedia. La traducción generalmente incluye preprocesamiento (preprocesamiento) y compilación.

El preprocesamiento es una fase opcional que consiste en analizar el texto fuente, extraer de él las directivas del preprocesador y ejecutarlas.

Las directivas de preprocesador son cadenas marcadas con caracteres especiales (generalmente %, #, &) que contienen abreviaturas, símbolos, etc. construcciones incluidas en el programa fuente antes de que el compilador las procese.

Los datos para la extensión del texto de origen pueden ser estándar, definidos por el usuario o contenidos en las bibliotecas del sistema operativo.

La compilación es generalmente un proceso de varias etapas que incluye las siguientes fases:

Análisis léxico: verificar la composición léxica del texto de entrada y traducir caracteres compuestos (operadores, paréntesis, identificadores, etc.) en alguna forma interna intermedia (tablas, gráficos, pilas, hipervínculos), conveniente para su posterior procesamiento;

analizando- verificar la corrección de las estructuras utilizadas por el programador en la preparación del texto;

análisis semántico- identificación de inconsistencias en los tipos y estructuras de variables, funciones y procedimientos;

La generación de código objeto es la fase final de la traducción.

La traducción (compilación) se puede realizar en varios modos, que se configuran mediante teclas, parámetros u opciones. Puede, por ejemplo, que solo se requiera realizar una fase de análisis, o similar.

Un módulo de objeto es un módulo de programa que es el resultado de compilar un módulo fuente. Incluye instrucciones de máquina, diccionarios, información de servicio.

El módulo objeto es inoperable porque contiene referencias ilegales a subrutinas invocables de la biblioteca del traductor (en el caso general, sistemas de programación) que implementan funciones de entrada/salida, procesamiento de variables numéricas y de cadena, así como otros programas de usuario o herramientas de paquetes de aplicaciones. .

Arroz. 1.4. Resumen multilingüe, de código abierto, sistema de programación de compilación

Módulo de carga – un módulo de software en una forma adecuada para su descarga y ejecución. La construcción del módulo de carga se lleva a cabo mediante herramientas de software especiales: enlazador, generador de tareas, enlazador, ensamblador, cuya función principal es combinar objetos y módulos de carga en un solo módulo de carga con la subsiguiente escritura en una biblioteca o archivo. El módulo resultante se puede usar más tarde para construir otros programas, etc., lo que crea la posibilidad de expandir el software.

El módulo de arranque después del ensamblaje se coloca en la biblioteca de programas del usuario o se envía directamente para su ejecución. La ejecución de un módulo consiste en cargarlo en la RAM, ajustarlo a su ubicación en la memoria y transferirle el control. La imagen del módulo de arranque en la memoria se llama módulo absoluto, ya que todos los comandos de la computadora aquí adquieren su forma final y reciben direcciones absolutas en la memoria. La formación de un módulo absoluto puede llevarse a cabo tanto programáticamente, procesando los códigos de comando del módulo por el programa cargador, como en hardware, aplicando indexación y basando los comandos del módulo de carga y trayendo las direcciones relativas indicadas en ellos a la forma absoluta.

Los modernos sistemas de programación le permiten pasar cómodamente de una etapa a otra. Esto se hace mediante la presencia del llamado entorno de programación integrado, que contiene un editor de texto, compilador, enlazador, depurador incorporado y, según el sistema o su versión, brinda al programador una comodidad adicional para escribir y depurar programas. .

Crear un entorno de aplicación completo que sea totalmente compatible con el entorno de otro sistema operativo es una tarea bastante compleja, estrechamente relacionada con la estructura del sistema operativo. Hay varias opciones para crear entornos de múltiples aplicaciones, que difieren tanto en las características de las soluciones arquitectónicas como en la funcionalidad que proporciona distintos grados de portabilidad de la aplicación.

En muchas versiones del sistema operativo UNIX, el traductor del entorno de la aplicación se implementa como una aplicación normal. En los sistemas operativos creados con el concepto de micronúcleo, como, por ejemplo, Windows NT, los entornos de aplicación se ejecutan como servidores en modo de usuario. Y en el sistema operativo OS/2, con su arquitectura más simple, los medios para organizar los entornos de aplicaciones están profundamente integrados en el sistema.

Una de las opciones más obvias para implementar múltiples entornos de aplicaciones se basa en la estructura en capas estándar del sistema operativo. En la fig. 2.7 El sistema operativo OS1 admite, además de sus aplicaciones "nativas", aplicaciones del sistema operativo OS2. Para hacer esto, incluye una aplicación especial, un entorno de software de aplicación que traduce la interfaz de un sistema operativo "extranjero", API OS2, a la interfaz de su sistema operativo "nativo", API OS1.

Modo de usuario

Modo privilegiado

Arroz. 2.7. entorno de software de aplicación,
llamadas del sistema de radiodifusión

En otra implementación de múltiples entornos de aplicaciones, el sistema operativo tiene múltiples interfaces de programación de aplicaciones del mismo nivel. En la fig. 2.8, el sistema operativo admite aplicaciones escritas para OS1, OS2 y OS3. Para ello, las aplicaciones se colocan directamente en el espacio del núcleo del sistema.

todos estos sistemas operativos: API OS1, API OS2 y
API OS3.

Modo de usuario

Privilegiado

Arroz. 2.8. Implementación de compatibilidad
basado en múltiples API de pares

En esta variante, las funciones del nivel de API llaman a las funciones del nivel del sistema operativo subyacente, que debe ser compatible con los tres entornos de aplicación generalmente incompatibles. Los diferentes sistemas operativos administran la hora del sistema de diferentes maneras, usan diferentes formatos de hora del día, dividen el tiempo del procesador según sus propios algoritmos, etc. Las funciones de cada API son implementadas por el kernel, teniendo en cuenta las especificidades del SO correspondiente, incluso si tienen un propósito similar.

Otra forma de construir múltiples entornos de aplicaciones se basa en el enfoque de microkernel. Al mismo tiempo, es muy importante separar los mecanismos básicos, comunes a todos los entornos de aplicación, del sistema operativo de las funciones de alto nivel específicas de cada uno de los entornos de aplicación que resuelven problemas estratégicos.

De acuerdo con la arquitectura del microkernel, todas las funciones del sistema operativo son implementadas por el microkernel y los servidores en modo de usuario. Es importante que cada entorno de aplicación esté diseñado como un servidor de modo de usuario independiente y no incluya los mecanismos subyacentes (Fig. 2.9). Las aplicaciones, utilizando la API, realizan llamadas al sistema al entorno de la aplicación correspondiente a través del microkernel. El entorno de la aplicación procesa la solicitud, la ejecuta (quizás pidiendo ayuda a las funciones básicas del microkernel para esto) y envía el resultado a la aplicación. Durante la ejecución de la solicitud, el entorno de la aplicación, a su vez, tiene que acceder a los mecanismos del sistema operativo subyacentes implementados por el microkernel y otros servidores del sistema operativo.

Aplicaciones Servidores SO

Personalizado

Privilegiado

Arroz. 2.9. Enfoque micronuclear
a la implementación de múltiples entornos de aplicación

Este enfoque para diseñar múltiples entornos de aplicaciones tiene todas las ventajas y desventajas de una arquitectura de micronúcleo, en particular:

es muy fácil agregar y excluir entornos de aplicaciones, lo cual es consecuencia de la buena extensibilidad de los sistemas operativos de microkernel;

la confiabilidad y la estabilidad se expresan en el hecho de que si uno de los entornos de aplicación falla, todos los demás permanecen operativos;

El bajo rendimiento de los sistemas operativos de microkernel afecta la velocidad de los entornos de aplicación y, por lo tanto, la velocidad de ejecución de la aplicación.

La creación de varios entornos de aplicaciones dentro de un sistema operativo para ejecutar aplicaciones de diferentes sistemas operativos es una forma que le permite tener una sola versión del programa y moverla entre sistemas operativos. Múltiples entornos de aplicaciones aseguran la compatibilidad binaria de un sistema operativo determinado con aplicaciones escritas para otros sistemas operativos. Como resultado, los usuarios tienen más libertad para elegir sistemas operativos y un acceso más fácil a software de calidad.

Preguntas para el autoexamen

50. ¿Cuál es la diferencia entre la arquitectura de microkernel y la arquitectura de sistema operativo tradicional?

51. ¿Por qué el microkernel se adapta bien a la computación distribuida?

52. ¿Qué significa el concepto de múltiples entornos de aplicación?

53. ¿Cuál es la esencia del método de traducción bibliotecaria?

Preguntas de control

54. ¿Cuál es el término utilizado en la arquitectura de microkernel para referirse a los administradores de recursos colocados en modo usuario?

56. ¿Por qué una arquitectura de sistema operativo microkernel es más extensible que un sistema operativo clásico?

57. ¿La arquitectura microkernel es más fiable que la tradicional?

58. Indique la razón por la que el rendimiento de una arquitectura microkernel es inferior al de un sistema operativo tradicional.

60. ¿Qué tipos de compatibilidad conoces?

61. ¿Debido a qué acciones se logra la compatibilidad binaria para procesadores de varias arquitecturas?

62. Especifique un método que le permita mejorar el rendimiento de la PC al ejecutar un archivo ejecutable "extranjero".

63. ¿Es suficiente un método de traducción de biblioteca para la compatibilidad total de la aplicación?