El concepto de diseño del sistema operativo Dujiangyan

1. El principio noventa y nueve más uno y el controlador de interrupciones

Simplifica y facilita el trabajo del noventa y nueve en el diseño de software, reduciendo así la complejidad y dificultad general del diseño de aplicaciones. Y mejorar El único requisito extremo de 1 es considerar la viabilidad en lugar de la conveniencia, de modo que la aplicación pueda lograr estas funciones extremas sin complicar demasiado todo el sistema para la conveniencia de estas pocas tareas. Esta característica está en DJYOS. más evidente en la gestión de interrupciones.

Los sistemas operativos comunes solo proporcionan algunas funciones para facilitar a los programadores escribir funciones ISR y cambiar interrupciones, etc. DJyos es diferente. Considera las interrupciones como un evento especial y las incorpora a la gestión de eventos. En aplicaciones prácticas, hay interrupciones como teclados que no requieren rendimiento en tiempo real, y también hay señales de alta velocidad que tienen retrasos de respuesta a interrupciones muy exigentes.

Los sistemas operativos comunes no distinguen entre estas dos señales de interrupción y consideran todas las interrupciones como señales que requieren una respuesta rápida. Proporciona una respuesta rápida para señales que no tienen requisitos de tiempo real, pero no pueden mejorar aún más el tiempo de respuesta de las señales de alta velocidad. Sin embargo, DJyos trata las interrupciones de manera diferente. Las divide en interrupciones en tiempo real y señales asincrónicas. Cualquier fuente de interrupción puede establecer si es una interrupción en tiempo real o una señal asincrónica. Siempre que configure una interrupción como interrupción en tiempo real, obtendrá un retraso de respuesta mucho más rápido que el sistema operativo tradicional, y la habilitación de interrupción en tiempo real nunca se desactivará mientras el sistema operativo esté en ejecución. que el ISR de la interrupción en tiempo real no se puede utilizar en todas las API del sistema operativo. El tiempo de respuesta de las señales asíncronas es más lento que el de los sistemas operativos normales, pero puede utilizar casi todos los servicios del sistema operativo que pueden ser utilizados por los servicios de eventos. Por ejemplo, la señal asíncrona ISR permite el uso de la función malloc, que es mucho más. conveniente en programación que los ISR de sistemas operativos ordinarios. El segundo método de respuesta de señales asíncronas está completamente en el contexto del evento, que es más lento que la respuesta ISR de la señal asíncrona, pero obtiene los mismos servicios del sistema operativo que el programa principal.

Por lo tanto, la programación bajo djyos proporciona un entorno de programación mucho más conveniente que los sistemas operativos tradicionales para la mayoría de las interrupciones que no tienen altos requisitos de tiempo real, pero para un número muy pequeño de interrupciones que son muy exigentes en cuanto a respuesta. Las interrupciones de tiempo ofrecen mayores posibilidades de implementación que los sistemas operativos tradicionales.

2. La programación de eventos permite a los ingenieros liberar sus mentes. El hardware y los sistemas operativos son el escenario, los programadores son actores y los gerentes de proyectos y los ingenieros de sistemas son directores y guionistas. El escenario puede estar hecho de tablas de madera, arenisca y cemento, pero la plataforma de desarrollo de software consta de hardware, subprocesos administrados por el sistema operativo, etc. Al igual que un actor no necesita saber de qué material está hecho el escenario, Solo necesita ejecutar el script con cuidado, a nosotros, los programadores, no se les debe exigir que comprendan las operaciones internas de la CPU y mecanismos oscuros como subprocesos y procesos. Solo necesitan implementar las funciones del software.

En los sistemas operativos tradicionales, la creación, el inicio, la pausa, la detención, la eliminación, etc. de subprocesos están controlados por el propio programador. En los sistemas de escritorio (incluido Windows CE integrado), existen herramientas visuales como ésta. como C lo resume por usted, simplificando la programación de subprocesos múltiples. En un entorno integrado, los programadores deben estar familiarizados con todo lo relacionado con los subprocesos. Más importante aún, el programa de aplicación implementado por subprocesos múltiples está determinado por el proceso de ejecución de la CPU. Requiere que los programadores dominen los subprocesos operativos. De hecho, requiere que los programadores piensen en los problemas de acuerdo con el proceso de ejecución de la CPU.

djyos está programado por eventos, lo que permite a los programadores escribir programas de acuerdo con la forma en que los humanos perciben las cosas. No hay funciones API relacionadas con los subprocesos. Los programadores solo necesitan hacer las dos cosas siguientes.

<. p>(1) El tipo de evento registrado le dice al sistema operativo lo que debe hacer la computadora.

(2) 2. Escribir función de procesamiento de eventos.

Sabemos que el software se utiliza para resolver problemas prácticos. Estos problemas pueden requerir una profunda experiencia en la industria, como ingeniería química, ciencias biológicas, etc. Es probable que los programadores sean expertos en estas industrias. un conocimiento profundo de la industria. Es posible que una computadora sepa mucho, especialmente en el mundo integrado.

Para que comprendan y apliquen el conocimiento de subprocesos de manera competente, les costará mucho dinero y muchos fondos de capacitación. Sin embargo, la programación bajo DJYOS les permite deshacerse de estas limitaciones y aprovechar al máximo sus conocimientos profesionales.

3. Pequeño goto y gran GOTO Cualquiera que haya escrito código C sabe que goto es una declaración muy tabú y algunas personas ni siquiera la usan en absoluto. Si bien estamos obsesionados con los gotos dentro de las funciones, ignoramos los grandes GOTO de larga data entre componentes y subprocesos. Algunos sistemas operativos incluso ofrecen una gran cantidad de grandes GOTO como punto de venta, diciendo lo que brindan para los servicios enriquecidos.

¿Qué es Big GOTO? Echemos un vistazo al resultado de la ejecución de la función del subproceso de activación. Supongamos que el nombre de esta función es task_resume y supongamos que el sistema operativo está programado de acuerdo con la prioridad. Después de que el subproceso A llama a task_resume (taskB_id), si el subproceso B tiene una prioridad más alta que A, cambiará inmediatamente al contexto de B para continuar la ejecución. Por lo tanto, para el subproceso A, es equivalente a ejecutar un GOTO entre componentes. Para el subproceso B, estaba durmiendo bien, pero se despertó sin ningún motivo. Para el director del proyecto, existe un control cruzado directo entre el equipo A y el equipo B, o salto cruzado.

djyos no proporciona operaciones similares. Todos los eventos controlan su propio comportamiento. No hay posibilidad de control cruzado entre las funciones de procesamiento de eventos. DJyos cree que el procesamiento de eventos no se detendrá sin ningún motivo. Continúa sin motivo, djyos proporciona varios servicios para permitir que la aplicación controle su propio comportamiento. Debe haber una razón para que el programa se detenga, ya sea para esperar un cierto período de tiempo, djyos proporciona la función de sincronización del despertador o para esperar a que esté disponible un determinado bloqueo, djyos proporciona la función de sincronización de bloqueo o esperar; para que finalice un evento, djyos proporciona la función de sincronización de eventos... ..., en resumen, con el soporte de estas funciones de sincronización, cada evento de la aplicación puede lograr el objetivo de controlar su propio comportamiento y abandonar por completo la cruz. -control entre módulos de aplicación. En otras palabras, no hay un gran GOTO entre eventos (correspondiente a subprocesos de otros sistemas operativos) en djyos.

4. División de grupo amigable para ayudar a los gerentes de proyectos a formar y administrar equipos. Un proyecto grande y mediano debe dividirse en varios equipos para el desarrollo conjunto. Lo que sueña el gerente de proyecto es reducir las disputas. entre los distintos equipos después de que el proyecto ingresa a la etapa de depuración conjunta, lo que sueña el gerente del proyecto es que después de que cada componente se ajuste de forma independiente, puedan ejecutarse juntos para reducir el tiempo de depuración conjunta. Incluso si el proyecto de una persona se divide en varios componentes, los problemas anteriores también existen. Además, una vez que el proyecto se completa y entra en el período de mantenimiento, la gran independencia de los componentes puede reducir en gran medida la carga de trabajo de mantenimiento.

En proyectos desarrollados conjuntamente por varios subequipos, los gerentes de proyectos y los ingenieros de sistemas deben considerar qué módulos se compilan juntos y qué módulos comparten el espacio de nombres. Si se admiten varios procesos, usted también lo hará al desarrollar en un entorno. Es necesario considerar qué módulos se ejecutan en el mismo espacio de direcciones. Estas cuestiones se unen para formular la cuestión de cómo dividir los "grupos amigos del software". En el capítulo 3 del libro "Sistema operativo y diseño de sistemas integrados de Dujiangyan", se utiliza una cantidad considerable de espacio para describir grupos amigos.

La definición de grupo amigable es muy simple, es decir, los programas confiables forman un grupo amigable ¿Qué es un programa confiable? Los programas desarrollados por el mismo equipo son confiables. "Amigable" tiene dos significados: primero, estos códigos tienen un objetivo común y trabajan en estrecha colaboración para completar tareas; segundo, estos códigos no interferirán ni se destruirán entre sí de forma activa o maliciosa, ni realizarán acciones ilegales intencionalmente. Hay dos casos especiales: si dos módulos desarrollados por el mismo equipo pueden dividirse en dos equipos para su desarrollo en el futuro, deben dividirse en dos grupos amistosos; el segundo caso especial es que los niveles de confiabilidad de los dos módulos son bastante; diferente También debe pertenecer a dos grupos amigos, para que los dos módulos puedan utilizar métodos de prueba de diferente intensidad.

Centrarse en las personas que diseñan software es una de las ideas centrales de Dujiangyan Operating System.

En el desarrollo de software moderno, se hace gran hincapié en la idea del desarrollo de ingeniería. En el desarrollo de ingeniería, cualquier estrategia de software debe tener en cuenta los factores humanos. Clasificar programas amigables y programas sospechosos es una estrategia fundamental en el diseño del sistema operativo djyos. La clasificación se basa en el equipo de desarrollo, más que en las características técnicas, que es la elección natural del sistema operativo Dujiangyan. Todos los códigos desarrollados por equipos que trabajan juntos se denominan programas amigables y se clasifican en un grupo amigable, mientras que todos los programas desarrollados por equipos que no trabajan juntos y por individuos se tratan como programas sospechosos. La consideración principal son los factores humanos. De acuerdo con este principio, todo el código del sistema operativo en sí es desarrollado por un equipo central, que naturalmente se convierte en un grupo de código amigable. El equipo de desarrollo del sistema operativo no necesita colaborar con los equipos e individuos que desarrollan las aplicaciones. todas las aplicaciones como sospechosas. Del mismo modo, una aplicación es desarrollada por una sola persona o un equipo estrechamente coordinado, y todo el código del programa forma un grupo amigable que trata a todas las demás aplicaciones, así como al sistema operativo, como sospechosos. Esto es diferente del concepto tradicional de que el sistema operativo es un programa confiable y el programa de usuario es un programa que no es confiable.

djyos establece vallas para aislar a los grupos amigos de modo que no puedan afectarse ni destruirse entre sí, y proporciona espacios de nombres completos dentro de diferentes grupos amigos. La protección entre grupos amigos se divide en dos niveles según el soporte de hardware.

(1) Si el hardware lo admite, diferentes grupos amigos tienen espacios de direccionamiento independientes y los códigos y datos entre ellos son físicamente invisibles entre sí, por lo que no pueden destruirse entre sí.

(2) Si el hardware no lo admite, el aislamiento lógico se logra en el modo de memoria de la tableta. Al escribir software, el código del mismo grupo amigable se compila de forma independiente, tiene un espacio de nombres independiente y funciona entre ellos. En los grupos amigos, las variables son invisibles entre sí, por lo que no pueden destruirse explícitamente entre sí.

5. El acoplamiento ligero, al realizar el desarrollo y la depuración independientes de cada módulo de un sistema, conducirá inevitablemente a un contacto mutuo y una influencia mutua, lo que llamamos acoplamiento entre módulos. El acoplamiento se divide en acoplamiento benigno y acoplamiento maligno. Por ejemplo, los módulos que se transfieren datos necesarios entre sí son acoplamientos benignos, mientras que los módulos utilizan los datos de los demás o se exigen mutuamente que hagan lo que deben hacer, lo que hace que los módulos dependan entre sí. Este tipo de acoplamiento se denomina acoplamiento maligno. El acoplamiento mencionado a continuación se refiere a acoplamiento vicioso a menos que se especifique lo contrario. El propósito del diseño a nivel de módulo del sistema es hacer que cada módulo sea lo más independiente posible y minimizar el acoplamiento entre sí. Incluso si el acoplamiento es inevitable, la interfaz entre módulos debe diseñarse cuidadosamente para que sea un acoplamiento benigno. De esta manera, cada módulo puede desarrollarse, mantenerse y sobrevivir de forma independiente, y puede adaptarse a nuevas necesidades mediante una adaptación dinámica, lo que permite a las empresas formular estrategias de productos flexibles y reducir el costo de transformación cuando cambia el entorno operativo. Sabemos que el acoplamiento es el principal culpable que impide que los equipos se desarrollen de forma independiente y discutan entre sí durante el desarrollo del proyecto. Durante la depuración conjunta, cuanto más estrecho sea el acoplamiento entre módulos, mayor será la carga de trabajo de la depuración conjunta. djyos se compromete a ayudar a los diseñadores de programas a reducir o incluso eliminar el acoplamiento entre módulos desde una perspectiva técnica. Con este fin, djyos ha trabajado mucho.

Sabemos que cuando se programa con soporte del sistema operativo, llamar a funciones de servicio del sistema durante la ejecución del hilo es la acción más común. Hay un problema oculto aquí. La función de servicio del sistema utilizará la pila del hilo actual. Si no prepara suficiente espacio de pila para estas llamadas, puede causar un desbordamiento de la pila y fallas impredecibles. por el equipo del sistema operativo y el código subproceso escrito por el equipo de la aplicación están brutalmente acoplados. Cuando se crea cada hilo, se le asignará una pila del tamaño apropiado. En las computadoras de escritorio, generalmente es de nivel M o superior. Este tipo de acoplamiento generalmente no causa problemas, debido a la escasez de memoria. pila Quizás solo unas pocas decenas de k. El tamaño de la pila no solo debe satisfacer las necesidades del subproceso, sino que tampoco debe ocupar demasiada memoria, lo que requiere la capacidad de estimar con precisión el tamaño de la pila requerido por el subproceso. Sin embargo, los programadores solo pueden estimar con precisión el tamaño de pila requerido por el código que escriben. Al llamar a los servicios del sistema, ¿cuánta pila requiere la función de servicio del sistema? Los programadores de aplicaciones son difíciles de estimar.

DJYOS resolvió esta situación y les dijo claramente a los programadores que solo necesitan estimar la pila requerida por el código que escribe, y explicó en detalle cómo estimar los requisitos de la pila. Cuando el sistema crea un hilo, agregará automáticamente los requisitos. pila de servicios del sistema, evitando así los problemas causados ​​por los servicios del sistema que utilizan pilas de subprocesos.

6. Naturalmente adaptado a los sistemas multinúcleo, en los sistemas operativos tradicionales, los subprocesos son el objetivo de la programación y los eventos existen como datos (recursos) procesados ​​por los subprocesos. y la CPU Y utilizando subprocesos como recursos, este método de configuración inversa es inherentemente más adecuado para múltiples núcleos. Se espera que logremos un soporte perfecto para CPU simétricas de múltiples núcleos en sistemas operativos que tienen solo unas pocas decenas de K de tamaño. En el futuro, los chips integrados también se desarrollarán en la dirección de múltiples núcleos. Por ejemplo, el blackfin de ADI ahora tiene un modelo simétrico de doble núcleo, y el blackfin es una CPU integrada típica sin mmu. Su competidor directo, Ti, también tiene un modelo similar. productos de doble núcleo.

En los sistemas operativos tradicionales, las aplicaciones crean subprocesos o procesos y escriben código para subprocesos y procesos. Los subprocesos generalmente están vinculados a un determinado núcleo. Uno es mediante el otro tipo de implementación del sistema operativo. lo especifica el programador. Por ejemplo, el sistema operativo VDK de ADI lo especifica el programador durante la etapa de compilación. La vinculación de subprocesos a los núcleos de la CPU es en realidad la vinculación del código de la aplicación a los núcleos de la CPU. Un subproceso maneja las tareas informáticas correspondientes. En el modo tradicional, incluso si las tareas informáticas de un determinado subproceso ocurren con frecuencia, solo pueden ser procesadas una por una por el núcleo de la CPU donde se encuentra el subproceso. Puede hacer un experimento y usar Word. Al convertir un archivo grande a PDF, durante el proceso de conversión, si no está ejecutando otros programas, la tasa de ocupación de la CPU siempre será de alrededor de 51. Es decir, un núcleo de la CPU siempre estará ocupado y el otro estará inactivo. .

En la programación de eventos de djyos, la aplicación solo prepara controladores para eventos, y el sistema operativo asigna los subprocesos a qué núcleo de CPU está vinculado un subproceso, por lo que esto elimina el problema. Vinculación del código de la aplicación a los núcleos de la CPU. Si un determinado tipo de evento ocurre con frecuencia, el sistema operativo le asignará varios subprocesos, y estos subprocesos se asignarán a diferentes CPU de acuerdo con la ocupación de cada núcleo de CPU.

7. Doctrina de tomar y tomar. La tecnología informática se ha desarrollado hasta el día de hoy y ha habido mucha acumulación de tecnología para desarrollar un producto integrado complejo, es necesario comprender el concepto de "tomar y tomar". tomar doctrina" y no desarrollar todo el software y el hardware completamente desde cero. ¿Pero cómo conseguirlo? Al desarrollar productos altamente confiables, seremos muy cautelosos al utilizar código externo, e incluso usaremos solo código externo compatible comercialmente. Cualquier código externo debe leerse detenidamente, analizarse cuidadosamente y probarse completamente antes de permitir su uso. Para los códigos con soporte comercial, el proveedor brindará soporte, por lo que el proceso es más rápido, mientras que para los llamados códigos de fuente abierta sin comercial. soporte, estos códigos Ni siquiera hay comentarios completos Leer dicho código ni siquiera llevará mucho menos tiempo que desarrollarlo usted mismo. Por lo tanto, el "préstamo" de productos de alta confiabilidad se basa principalmente en heredar los módulos de software acumulados por la propia empresa para reducir la carga de trabajo de desarrollo. Para tener algo que pueda usarse al desarrollar nuevos productos, el proceso de desarrollo de productos de la empresa solo necesita prestar gran atención a la "capacidad de aceptación". En una palabra, si no lo quita, ¿cómo puede hacerlo? La tomabilidad, en esencia, significa que se puede quitar. ¡Portabilidad! Con el apoyo del sistema djyos, el diseño del sistema enfatiza la "disponibilidad", es decir, la capacidad del sistema para integrar módulos de software ya preparados. En términos de diseño del módulo, enfatiza la "disponibilidad", es decir, los módulos deben poder; adaptarse a diferentes entornos operativos. La capacidad del sistema djyos para integrar módulos existentes, además de proporcionar las mismas capacidades de ejecución simultánea que los sistemas operativos tradicionales, también considera ayudar a los diseñadores de programas a combinar módulos existentes en un nuevo producto y la capacidad de diseñar módulos combinables. DJYOS tiene muchas funciones que admiten la doctrina de tomar y tomar, y el administrador de dispositivos panorámicos es uno de los módulos típicos que admite la doctrina de tomar y tomar.

Según la perspectiva de djyos, el entorno operativo al que se enfrenta cada módulo de aplicación incluye no sólo hardware y sistemas operativos, sino también otros módulos de software.

Incluso si no hay cambios en el hardware y el sistema operativo, si otros módulos del producto cambian, se considerará un cambio en el entorno operativo. DJYOS enfatiza que los módulos de software deben adaptarse a dichos cambios. Una empresa suele tener docenas o cientos de modelos de productos serializados. Estos modelos pueden estar construidos en la misma plataforma de hardware y sistema operativo, pero solo tienen diferentes combinaciones y configuraciones de módulos de aplicación. Para este tipo de empresas, la capacidad de combinar módulos de software de forma flexible es muy importante. La arquitectura de controladores de los sistemas operativos tradicionales está diseñada para permitir que las aplicaciones accedan al hardware de forma estándar, protegiendo las diferencias en las plataformas de hardware. Existe una relación jerárquica obvia entre los usuarios de los controladores y las personas conducidas. DJYOS considera otros módulos de la aplicación como entornos y el controlador se utiliza para proteger las diferencias en todo el entorno. DJYOS comienza desde la perspectiva del diseño conjunto de software y hardware. No existe una relación jerárquica entre módulos de software, módulos de hardware y módulos que combinan software y hardware, y colectivamente se denominan módulos de funciones del sistema. Por lo tanto, la arquitectura del controlador no es jerárquica. El usuario del controlador y la persona operada tienen una relación de igualdad. Un módulo de aplicación proporciona una interfaz estándar para el acceso mutuo con otros módulos a través del controlador. interfaz, entonces todos los módulos de software dentro de la empresa se pueden combinar de manera flexible.

8. Función malloc en tiempo real En RTOS, la función malloc generalmente se considera un componente no en tiempo real, porque incluso si hay suficiente memoria, el tiempo de ejecución de la función malloc es impredecible. y no cumple con los requisitos de tiempo de ejecución y resultados del sistema en tiempo real. El principio de previsibilidad. Sin embargo, la gestión de la memoria de djyos es en tiempo real bajo ciertas condiciones, siempre que se equipe suficiente memoria durante el diseño del sistema, el tiempo de ejecución de malloc es rápido y predecible en un sistema en tiempo real que solo ejecuta una aplicación, la memoria. El agotamiento no es suficiente. La asignación de memoria de djyos utiliza una estructura de recuperación de doble pirámide, con páginas como unidades. En un sistema con un espacio de direcciones 4G, un tamaño de página de 1K y una longitud de palabra de CPU de 32, solo se realizan 5 búsquedas (***5 comparaciones, 5 multiplicaciones y 5 sumas) pueden localizar una página gratuita, lo cual es bastante rápido.

Además de las funciones en tiempo real, la administración de memoria de djyos también puede prevenir pérdidas de memoria hasta cierto punto, y la función malloc permite llamar a ISR de interrupción.