el principal / Problemas / Normalización de Unix de sistemas operativos y POSIX. Estándares de sistemas operativos en tiempo real.

Normalización de los sistemas operativos y POSIX UNIX. Estándares de sistemas operativos en tiempo real.

Sobre las normas en general

Entre los programadores, los programadores son la opinión de que no se necesitan las normas en la programación, ya que:

(1) Inicialmente, están sin sentido, ya que sus autores no escriben programas informáticos;

(2) Están luchando contra la iniciativa de los programadores;

(3) Los programadores siempre estarán de acuerdo sin estándares.

Tal vez esta opinión no debe prestarse atención a la atención si no es dos circunstancias:

(1) Sus prácticas expresan, es decir, es aquellos que "cuestionan los productos del programa";

(2) El argumento anterior fue descubierto por el autor de este artículo en una de las publicaciones en Internet en el estándar para el lenguaje de programación de C, que quedó claro que tal opinión se difundió "a escala internacional", y no solo entre Arrogantes rusos "Superfrogramistas".

La palabra "estándar" generalmente se asocia con algo material (dimensiones estándar, estándar voltaje eléctrico ), mientras que el programa de computadora es un objeto intangible ("el nuevo intangible"), y tal vez los estándares en la esfera intangible realmente tienen sentido "

Sin embargo, hay un ejemplo de refutación. La combinación de las reglas de la ortografía de la lengua rusa esencialmente es un estándar, aunque no aprobado por las autoridades de normalización. Además, a excepción de las reglas (o, si usted, los requisitos) de la ortografía, hay reglas sintácticas y, lo más importante, la semántica. Este último ilustra la pregunta "para los niños": ¿Por qué el gato llame a un gato? Hay una respuesta precisa a esta pregunta: porque nuestros antepasados \u200b\u200bestuvieron de acuerdo. Los antepasados \u200b\u200bde los británicos acordaron llamar al mismo gato bestial, los antepasados \u200b\u200bde los alemanes: gatito, etc. En general, el significado, o semántica, o las reglas para la interpretación de cualquier palabra o una combinación de palabras, la cuestión del acuerdo.

Nombramiento y "Superbate" de la POSIX estándar

De la siguiente manera desde el nombre, POSIX (Portátil Sistema operativo Interfaz) es un estándar para el emparejamiento (interfaz) entre el sistema operativo y el programa de aplicación. Veces cuando los programadores escribieron programas para la máquina "desnuda" (implementando sus propios paquetes de programas de E / S, funciones trigonométricas, etc.), pasadas irremediablemente. El texto POSIX enfatiza repetidamente que la norma no presenta ningún requisito para las operaciones del sistema operativo; Se puede considerar como una totalidad de acuerdos entre programadores de aplicaciones y desarrolladores. sistemas operativos. Por lo tanto, (de nuevo, contrariamente a una opinión bastante popular), POSIX es de interés, no solo para los desarrolladores de sistemas operativos, sino en primer lugar, para una categoría mucho más numerosa de programadores, aplicados.

La necesidad de la norma de este tipo se realizó en la década de 1980, cuando los sistemas operativos UNIX estaban generalizados. Resultó que aunque este sistema fue concebido como unificado, las diferencias entre sus implementaciones específicas llevaron al hecho de que los programas de aplicación escritos para un sistema no siempre pudieron ejecutarse en otro. Sobre la decisión de este problema en particular, conocido como el problema de la movilidad. software, Posix apuntado. La primera edición de la norma se publicó en 1988 (se encuentra una traducción, ver), en la que toda la variedad de temas relacionados con la movilidad del programa se dividió en dos partes: (1) Interfaz de aplicación, (2) Intérprete de comando y utilidades. (Interfaz de usuario); Estas partes se llamaban POSIX.1 y POSIX.2, respectivamente1.

Especificaremos que este artículo solo hablará sobre el estándar para la interfaz de la aplicación, POSIX.1, la segunda (y la última fecha) de los cuales se aprobó el 12 de julio de 1996.

La parte informativa de la norma también enfatiza que POSIX no es una descripción de la interfaz de algún sistema operativo "ideal", sino el resultado de la generalización y la sistematización de la experiencia obtenida en el desarrollo de sistemas operativos UNIX. Además, POSIX no puede servir como guía o manual de capacitación para sistemas operativos, aunque la parte informativa contiene recomendaciones a programadores y fragmentos de programas.

La norma se refiere al hecho de que es imposible crear un sistema operativo de flación completa, centrándose exclusivamente en las funciones de la interfaz descrita en ella. (En particular, POSIX.1 no refleja temas como redes y funciones de interfaz relacionadas o una interfaz gráfica. Sin embargo, los costos financieros causados \u200b\u200bpor la nongetabilidad de los programas y la necesidad de la unificación de la interfaz es tan grande que la mayoría de los fabricantes prefieren Tener al menos algún estándar que no tener a nadie. Por esta razón, muchos desarrolladores de software buscan navegar en POSIX. Esto hace posible si no elimina completamente la no asignación de programas, al menos reduce significativamente la parte Nongetable del programa.

Sobre semántica

Como ya se mencionó, POSIX se puede considerar como un conjunto de acuerdos entre el desarrollador del sistema operativo y el programador de aplicaciones. "Acuerdo" significa primero de toda la igualdad de la interpretación (semántica) de palabras y expresiones. Los siguientes son ejemplos que ilustran la dificultad de la tarea de lograr un acuerdo.

Cómo transmitir el significado al traducir

En primer lugar, debe recordar que el estándar POSIX se establece en inglés, que en la naturaleza provoca la ambigüedad (por ejemplo, la misma palabra puede ser sustantivos, adjetivos y verbos), y "trampas semánticas" escucharon casi en cada página. Una buena ilustración de lo dicho es un ejemplo de ficción. Una de las obras más famosas de Oscar Wilde, que utilizó brillantemente esta característica del idioma inglés, - la importancia de ser serio, se conoce en ruso llamada "qué tan importante ser serio". Sin embargo, el nombre de inglés tiene un segundo significado: Earnest (serio): el apellido de uno de los personajes, y el nombre podría traducirse de manera diferente: "Qué importancia ser Ernst". Hay un apellido ruso de plata, y si hubiera un apellido serio, la traducción sería perfectamente precisa, con la transferencia de ambos significados.

El mismo es el caso con el nombre de la interfaz estándar: interfaz del sistema operativo portátil. El adjetivo portátil (móvil) se refiere al sistema operativo, y al programa de aplicación, pero no es posible expresarlo en breve en ruso, puede traducirse como una "interfaz del sistema operativo móvil" o "Interfaz del sistema operativo que proporciona la movilidad de programas de aplicación." La segunda opción refleja mejor las intenciones de los desarrolladores estándar, pero al mismo tiempo se perdió el primer lavado (se conservó la primera opción más familiar).

Semántica de la palabra "estándar"

El texto principal de la norma está preamigado por el preámbulo, en el que se explica el significado de la palabra IEEE Standards2. De la siguiente manera de estas aclaraciones, hay al menos tres diferencias semánticas del Término de habla rusa GOST:

(1) Cree intuitivamente que GOST tiene el poder de la ley cuya violación es perseguida; POSIX es un conjunto de requisitos, lo cual es el caso exclusivamente voluntario.

(2) GOST actúa hasta la cancelación (muchos, probablemente, tuvieron que escuchar la expresión "Gost Nadie cancelado"); En el preámbulo de Posix, se dice que si la norma no se revisó durante 5 años, esto significa que las preguntas consideradas en ella probablemente perdieron la relevancia, y se puede considerar cancelada automáticamente;

(3) GOST ANONOMEN; En la parte introductoria de POSIX, se proporciona una lista de aquellas personas que participaron en el desarrollo de esta norma, y \u200b\u200btambién proporciona la dirección en la que puede enviar solicitudes de interpretación; También se dice que la respuesta a cada solicitud está sujeta al procedimiento de coordinación (en otras palabras, los autores de la norma están de acuerdo entre sí antes de dar la respuesta).

Por lo tanto, la traducción de una palabra así conocida como la palabra estándar "estándar" requiere comentarios.

La semántica de las palabras "debe", "no especificada", "no definida", "determinada por la implementación"

La Sección 2 del Estándar se llama "Terminología y Requisitos Generales". Contiene las definiciones de no solo los términos especiales (como el "proceso" o "semaphor"), sino también similares, parecerían las palabras evidentes, como "deben" o "mayo". Dado que POSIX.1 es un estándar en la interfaz, sus requisitos están relacionados con el sistema operativo y el programa de aplicación. El requisito explícito se expresa por la palabra "debe" (deberá), por ejemplo: "En caso de finalización exitosa, la función de enlace () debe devolver el valor cero". En este ejemplo, estamos hablando de los requisitos del sistema operativo: la función de enlace () debe implementarse de modo que, en una finalización exitosa, el valor cero devuelto.

Los términos "no especificados" y "no definidos" expresan la misma idea de que el estándar admite la libertad de elección, pero el significado de estos términos es variado. El término "no especificado" implica que estamos hablando de algunos correctos (acciones, estructuras de software, etc.), y el término "no definido", sobre incorrecto (erróneo). La parte informativa de la norma proporciona la siguiente explicación.

El término "no especificado" significa que se supone que muchas opciones (resultados, los resultados de la llamada de función, etc.) se sabe, y la norma le permite a cualquiera de ellos; En una implementación específica del sistema operativo, se puede seleccionar cualquier persona, y un sistema de este tipo se considera el estándar relevante. El programa aplicado (estándar estrictamente relevante) debe escribirse de tal manera que funcione correctamente en cualquier variante; Esencialmente, este término expresó implícitamente un requisito para un programa de solicitud.

Demos un ejemplo: la función "ReadDir () debe devolver un puntero a la estructura relacionada con el elemento de la siguiente directorio. Si los elementos del directorio se devuelven con los nombres "DOT" y "Punto de punto", no se especifica el estándar ". En este ejemplo, cuatro resultados son posibles, y el requisito de un programa de aplicación es que debe ser diseñado para cualquiera de ellos.

Otro ejemplo: "Si la función SIGWAIT (), que prescribe la espera de la señal con el número especificado, se produce en varias flujos de control, cuando se recibe la señal, no se debe regresar más de uno de ellos de Sigwait (). En qué tipo de flujo de control sucederá, la norma no se especifica ". En este ejemplo, muchos resultados posibles pueden ser más, pero también se conocen, y el requisito de un programa de aplicación es que debería funcionar correctamente en cualquier resultado.

El término "no definido" implica que incluso se conocen muchos resultados, ningún resultado es posible, incluso deplorable (por ejemplo, colapso del sistema, pérdida de datos, etc.). Esencialmente, este término expresó implícitamente el requisito para que el programa de aplicaciones no utilice los datos o diseños apropiados. Por ejemplo: "Si la función de argumento dirp readdir () no se refiere al directorio abierto actualmente, el resultado no está definido".

Este ejemplo contiene una solicitud para aplicar como un argumento ReadDir () solo enlace a un directorio abierto; La violación de este requisito puede llevar a consecuencias desastrosas, y la responsabilidad por ello se asigna a un programador de aplicaciones.

Aquí está otro ejemplo: "En caso de finalización exitosa, la función LEAD () debe devolver un número entero que indique el número de bytes de lectura virtualmente. De lo contrario, la función debe asignar un código de error a ERRNO y devolver -1, y el contenido del búfer al que se especifica el argumento de BUF no está definido ".

Use en un programa de aplicación de un búfer en caso de un error de la función de lectura (), la norma prohíbe, y las consecuencias de la violación de este requisito se imponen al programador de la aplicación.

El significado del término "está determinado por la implementación" difiere de intuitivo. Obviamente, en un sistema operativo específico, no puede haber un resultado "no consejo" o "incierto", se obtendrá un resultado particular. El término "determinado por la implementación" expresa el requisito de la norma a la documentación para el sistema operativo: el resultado no solo debe ser aclarado (el desarrollador del sistema operativo tendrá que hacer de todos modos), pero también refleja explícitamente la documentación de el sistema.

Semántica por defecto

Ningún documento regulatorio puede cubrir toda la variedad de casos que pueden reunirse en la práctica, por lo que es inevitable sobre algo silencioso3. Por ejemplo, en la descripción de la función se puede decir que su argumento puede tomar valores de un cierto rango, pero nada dice que será el resultado si el argumento no cae en este rango. Obviamente, para evitar malentendidos, es necesario tener una sola semántica predeterminada. En la parte informativa de la norma hay una frase curiosa: "La semántica generalmente aceptada del incumplimiento está prohibida". Esta declaración contradice el conocido eslogan de hace una década "Todo lo que claramente no está prohibido está permitido. Aparentemente, estaba tan arraigado en la conciencia de los ciudadanos que muchos, incluso programadores, no están de acuerdo con la declaración procitada de la norma. Mientras tanto, si el uso de cualquier diseño claramente no está permitido y no se sigue desde la descripción, entonces ningún programador de practicantes se da cuenta de que su uso es arriesgado, y si no funciona, no se produce una reclamación.

Procesos y flujos de control.

Ambos de estos términos expresan la idea del paralelismo de la ejecución. El sistema operativo UNIX se concibió originalmente como un multijugador, y los programas que son lanzados por diferentes usuarios deben aislarse de manera segura entre sí para distorsionar accidentalmente los datos de "otras personas". Este aislamiento se proporciona por el hecho de que el programa de usuario se ejecuta dentro de un determinado proceso que se desarrolla en su propio espacio de direcciones virtuales. Incluso si el programa tiene datos globales, cuando lo inicia en diferentes procesos, se "divorciarán" automáticamente por diferentes espacios de direcciones.

Sin embargo, el mecanismo de los procesos no es bastante satisfactorio al programar tareas en tiempo real. El programa de aplicación en tiempo real (actuando en nombre del mismo usuario) a menudo se puede representar naturalmente como paralelo a las partes ejecutables, que se denominan "flujos de control" (hilo). La diferencia más significativa de los procesos es que todos los flujos de control se están desarrollando en un solo espacio de direcciones; Esto garantiza un acceso rápido a los datos globales, pero al mismo tiempo el riesgo de distorsión no intencional de su distorsión, y que esto no ocurre, es necesario cumplir con alguna programación de disciplina. Las recomendaciones relevantes están contenidas en la parte informativa de la norma.

Se debe enfatizar que la idea de multithreading se implementa en muchos sistemas operativos en tiempo real, y se implementa de manera diferente en el sentido de que diferentes conjuntos de atributos y funciones de interfaz corresponden a cada flujo de control; A veces, en lugar del término "flujo de control" (hilo), utiliza el término "tarea" (tarea). Para evitar malentendidos, la norma enfatiza que viene exclusivamente sobre las corrientes de control POSIX, y los nombres de las funciones de la interfaz correspondientes tienen el prefijo PTHEADES (por ejemplo, PTHREAD_CREATE (), PTHREAD_JOIN (), etc.).

Cumplimiento de la norma. La semántica de la palabra "corresponde".

Es intuitivo que si dos sujetos se realizan de acuerdo con el mismo estándar, entonces están garantizados de "coincidir" entre sí y trabajarán juntos en un par; Es en esto que el propósito de la introducción de la norma para la conjugación (interfaz) es. Dado que POSIX es un estándar en la interfaz, puede hablar sobre el cumplimiento del estándar del sistema operativo y programa de aplicación.

POSIX.1 estándar contiene varios cientos (si no miles) requisitos; Se considera evidente que si al menos uno de ellos no se cumple, el sistema (o programa de aplicación) no satisface la norma. Al mismo tiempo, tal serie de sistemas operativos de UNIX y programas de aplicación para ellos están escritos hasta la fecha, lo que es poco probable que requiera razonablemente la correspondencia total en el sentido especificado. Las dificultades para desarrollar un estándar internacional de este tipo se exacerban por la existencia de diferentes idiomas nacionales. Incluso si se olvida de los programas de aplicación diseñados para procesar textos en idiomas nacionales, casi cualquier aplicación debe emitir algunos mensajes de diagnóstico y / o percibir los textos ingresados \u200b\u200bpor el operador.

estricto cumplimiento con la norma POSIX.1;
cumplimiento de la versión internacional de POSIX.1;
cumplimiento de la versión nacional POSIX.1;
cumplimiento POSIX.1 con extensiones.

En segundo lugar, muchos fondos de interfaz se declaran opcionales (opcional); La norma requiere que las funciones de la interfaz opcionales se desarrollarán según lo prescrito por el estándar, o siempre han devuelto un código de error especial, ENOSYS (lo que significa que la función no se implementa). Los medios opcionales se dividen en varios grupos, cada uno de los cuales corresponde a alguna constante de configuración, que se declara (operador #define) en el archivo de encabezado correspondiente; Esto garantiza la posibilidad de descubrir si la función se implementa en la fase de compilación.

La admisión descrita de la movilidad fue inventada no por los autores de POSIX, y hace mucho tiempo aplicado en la práctica; En muchos sistemas operativos, se aplican constantes de configuración para identificar el propio sistema o su versión. Y aquí la norma no ofrece nada fundamentalmente nuevo, pero solo sistematiza la práctica existente.

Objetos de estandarización y estructura estándar.

Para hablar brevemente, los objetos de la estandarización POSIX.1 son nombres y semánticas. Más específicamente, estamos hablando de lo siguiente.

Características de la interfaz. 357 Las funciones están estandarizadas, y se toman 107 funciones de las bibliotecas estándar SI (matemáticas, procesamiento de filas, entrada / salida, etc.); Estas funciones se consideran parte del estándar POSIX.1, pero su descripción completa está contenida en el lenguaje de programación estándar.
Nombres de los tipos de datos del sistema. Estos nombres tienen un sufijo _T.
Los nombres de los archivos de encabezado, así como la composición mínima de estos archivos.
Nombres de variables globales de todo el sistema (por ejemplo, errno).
Nombres simbólicos para códigos de error que se pueden instalar al trabajar las funciones. Estos nombres comienzan con la letra E (EPERM, ENOTEMPTY, etc.).
Nombres de configuración constante. Estos nombres tienen prefijo _POSIX_.
Nombres simbólicos de señales; Estos nombres tienen un prefijo SIG. Además de las señales "tradicionales" tradicionales (SIGABRT, SIGALRM, etc.), las señales en tiempo real están estandarizadas, los números de los cuales deben ocupar un rango sólido de Sigtmin a SigrTmax inclusive, que no contiene menos números RTSIG_MAX.
Nombres simbólicos correspondientes a los valores de los argumentos individuales de algunas funciones (por ejemplo, la función de argumento CMD FCNTL () puede tomar F_DUPFD, F_GETFD, valores F_GetLK, etc.).
Nombres de macros, constantes, banderas de bits, variables de medio ambiente.

En general, la norma consta de dos partes grandes de aproximadamente el mismo volumen. La primera mitad es la parte regulatoria: contiene los requisitos y las recomendaciones de la Norma (18 secciones), la parte de segunda información, contiene aplicaciones que proporcionan una lista de referencias, comentarios y explicaciones a la parte regulatoria, la composición de los archivos de encabezado , un ejemplo de un perfil ("proyección") de la norma (para Dinamarca), características y métodos para medir el desempeño de las funciones más importantes, así como una descripción de las funciones de interfaz adicionales para trabajar con archivos en tiempo real; Se espera que en las siguientes ediciones de la norma, estas funciones se incluyerán en la parte regulatoria.

La idea de que los tipos de servicios del sistema operativo están cubiertos por el estándar, proporciona la suma del "Resumen de las secciones estándar".

Conclusión

El contenido principal del estándar POSIX es la semántica de las funciones de la interfaz. Estandarización de la semántica: el caso en sí mismo no es fácil (todos saben lo difícil que es estar de acuerdo incluso a dos personas), y las dificultades son exacerbadas por muchas personas que actualmente están involucradas en las actividades de programación. Por ejemplo, el paradigma de ejecución paralelo se expresa por términos como el "proceso", "tarea" y "flujo de gestión", pero desde el punto de vista de la programación práctica "tarea" en el sistema operativo IBM OS / 360 y en el El sistema operativo en tiempo real VXWorks no es uno y también. Otro ejemplo es semáforos. Los semáforos son binarios, enteros ("con un medidor") y una excepción mutua (que, por cierto, los programadores se llaman "mutexes", buscando especialmente para evitar malentendidos). Y los semáforos enteros, por ejemplo, en el sistema operativo de VxWorks, no son en absoluto lo mismo que POSIX SEMAFORES.

Los autores del estándar POSIX, realizan perfectamente lo difícil que es hacer que las personas abandonen sus hábitos (que llaman la "práctica establecida"), declaran que hicieron un sistema lógicamente conectado y mínimo de funciones de interfaz que cubren la mayoría de los servicios tradicionalmente proporcionados Por el sistema operativo, en detalle describió la semántica exacta de estas funciones y ofrecemos a todos a usarlos en sus desarrollos4.

Al leer el estándar a veces, la impresión surge que algunas formulaciones tenían un solo objetivo: no retirar algunos programas de aplicación o sistemas operativos de la categoría. Dicho objetivo se estableció y se formuló claramente en la introducción: la norma debe tener en cuenta la práctica actual para maximizar la medida. Sin embargo, el objetivo principal es garantizar la movilidad de los programas de aplicación.

Sobre autentico

Sergey Romanyuk - investigador principal del Instituto de Investigación de Investigación del Sistema, Jefe de Grupo de traducciones estándar POSIX. Puedes contactarlo email por la dirección: [Correo electrónico protegido]

1 Se debe agregar que el trabajo en el estándar continúa durante muchos años; Se identifican nuevas preguntas, y se incluyen en una de las partes existentes, o se realizan en forma de una pieza separada, que luego puede cancelarse. Esto sucedió, por ejemplo, con los medios de interfaz de tiempo real, que se anunciaron por primera vez como POSIX.4, y posteriormente se incluyeron en POSIX.1.

2 IEEE es una organización en la que se ha desarrollado el estándar POSIX.

3 Aquí el "MISTOR" significa silencioso, no por defecto; Esto no se trata de algunos valores implícitos que realmente se declaran, sino sobre la declaración de mención en absoluto.

4 La traducción del estándar en ruso se publicará a principios de 2000.

Literatura

Estándar internacional ISO / IEC 9945-1 (ANSI / IEEE STD 1003.1) Segunda edición. 1996-07-12. Tecnología de la información - Interfaz del sistema operativo portátil (POSIX) - Parte 1: Interfaz del programa de aplicación del sistema (API).

M.I. Belyakov, Yu.I. Wereruve, a.l.fridman. Sistema operativo móvil. Directorio. Moscú, radio y comunicación, 1991.

ISO / IEC 9899: 1990, lenguajes de programación - C.

Sección 1	- Introducción
Sección 2.	- Terminología y definiciones.
Seccion 3.	- Funciones de gestión de procesos (creación, reemplazo de imágenes, finalización) y señales (gestión de máscara, respuesta de la señal)
Sección 4.	- Identificación (procesos, usuarios, sistemas, terminales), una encuesta de tiempos gastados en la ejecución del proceso, encuesta de variable de entorno.
SECCIÓN 5.	- Administrar archivos y catálogos.
SECCIÓN 6.	- Funciones de entrada y salida.
SECCIÓN 7.	- Funciones de gestión de terminales
Sección 8.	- Funciones prestadas del estándar.
SECCIÓN 9.	- Acceso a bases de datos de usuarios y grupos de usuarios.
SECCIÓN 10.	- Formatos de datos para archivar e intercambio (TAR y CPIO)
SECCIÓN 11.	- Herramientas de sincronización: semáforos, mutexes y condiciones variables.
SECCIÓN 12.	- Funciones de administración de memoria: espacio de dirección de fijación y desacuerdo, muestra archivos de memoria, protección de memoria, memoria compartida
SECCIÓN 13.	- Funciones relacionadas con los procesos de planificación y los flujos de control.
SECCIÓN 14.	- Gestionar relojes y temporizadores.
SECCIÓN 15.	- Informe de gestión de colas.
SECCIÓN 16.	- Funciones básicas relacionadas con los flujos de control.
Sección 17.	- Datos de flujo de control individuales (datos específicos del hilo)
SECCIÓN 18.	- Medios de destruir los flujos de control.

Estándares

Sergey Zolotarev,

El propósito de este artículo es intentar tomar cierta claridad en el historial de desarrollo de la norma POSIX en relación con los sistemas operativos en tiempo real (OS RV).

Como introducción: ¿Por qué necesita una estandarización de la interfaz de programación?

Una de las propiedades más importantes del estándar POSIX es que define una "interfaz de programación estandarizada", que los desarrolladores de software complejos y sistemas de hardware deben adherirse a los desarrolladores. Los creadores de estos sistemas se ven obligados a enfrentarse a dichos requisitos en poco tiempo de ingresar al mercado (debido a la competencia rígida), minimizar los costos y acelerar los rendimientos de inversión. Al mismo tiempo, la parte del león de los gastos causados \u200b\u200bpor la desaceleración en el proceso de desarrollo está relacionada con el hecho de que los programadores tienen que "inventar una bicicleta", una y otra vez la implementación de la funcionalidad, que durante mucho tiempo ha estado disponible. Pero esto podría ser evitado por:

Reutilizar código de proyectos pasados \u200b\u200by paralelos;

Transferencia de código de otro sistema operativo;

Atraer a los desarrolladores de otros proyectos (incluido el uso de otro sistema operativo).

Todo esto es posible debido al uso del sistema operativo con una API estandarizada. Además, si en el primer caso, la organización es suficiente para tener un determinado estándar interno (que es especialmente característico del sistema operativo de la marca), entonces los dos dos casos solo requieren la disponibilidad de normas generalmente aceptadas, por ejemplo, POSIX.

Por lo tanto, utilizando un proyecto de sistema operativo compatible con POSIX como plataforma, el desarrollador tiene la oportunidad de transferir código listo A nivel de texto de origen, tanto de sus proyectos pasados \u200b\u200bo paralelos como de proyectos de terceras empresas. Esto no solo reduce significativamente el momento del desarrollo del software, sino que también mejora su calidad, ya que el código probado siempre contiene menos errores.

Quién es quien en el desarrollo de POSIX.

Y comencemos con el Posix Muy estándar, pero al ordenar el papel de las organizaciones involucradas en trabajar en él.

El primer participante es IEEE. Instituto de Ingenieros Eléctricos y Electrones, Instituto de Ingenieros de Electricistas y Electrónica), Asociación Pública de Profesionales sin fines de lucro. IEEE lidera su historia desde 1884 (formalmente, desde 1963), combina a 380,000 miembros individuales de 150 países, publica la tercera parte de la literatura técnica relativa al uso de computadoras, gestión, tecnologías eléctricas e informativas, así como más de 100 revistas, popular en el medio ambiente de los profesionales; Además, la asociación es por año más de 300 conferencias importantes. IEEE participó en el desarrollo de más de 900 estándares existentes (www.ieee.ru/ieeee.htm). Hoy en día, este Instituto está involucrado en la preparación, aprobación, aprobación, las normas de publicación, pero en su estado formal no tiene la autoridad para aceptar dichos documentos como estándares internacionales o nacionales. Por lo tanto, el término "estándar" en la comprensión de IEEE, más bien significa "especificación", que se corresponde más con el estado de los documentos tomados por la Asociación. De acuerdo con IEEE, participa en los programas de una serie de organizaciones internacionales y regionales: IEC, ISO, UIT (Instituto Europeo de Normas de Telecomunicaciones para la Handartización electrotécnica) y en programas nacionales, como el programa de una organización como ANSI.

IEEE incluye PASC (Comité de Normas de Aplicaciones Portátiles; www.pasc.org/) - Comisión de asociación, que está desarrollando una familia familiar POSIX. Anteriormente, PASCC fue conocido como el Comité Técnico de Operaciones.

El segundo participante de trabajo - ANSI (Instituto Nacional de Normas Nacionales, American National Standards Institute; www.ansi.org) - una organización privada sin fines de lucro que administra y coordinan en los Estados Unidos sobre temas de normalización. Solo emplea a 75 personas, pero los miembros de ANSI son más de 1000 empresas, organizaciones, agencias gubernamentales e instituciones. ANSI representa a los Estados Unidos en dos principales organizaciones internacionales para la estandarización: ISO y IEC.

Tercer participante - YO ASI. Organización Internacional de Normalización, Organización Internacional sobre Normal; www.iso.org). Se creó en 1946 por decisión de coordinar los estándares y la Asamblea General de las Naciones Unidas y comenzaron oficialmente el 23 de febrero de 1947. ISO es una red de instituciones nacionales de estandarización de 146 países (un país - un miembro ISO) con la Secretaría Central en Ginebra (Suiza). Las normas ISO se desarrollan en los comités técnicos, el primer resultado de los cuales es un proyecto de documento estándar internacional (DIS), convirtiéndose después de varias coincidencias en el estándar final del Draft Internacional (FDIS). Después de eso, la cuestión de la aprobación de este documento se hace a votación; Con un resultado positivo, se convierte en un estándar internacional.

Finalmente, - IEC. Comisión Electrotécnica Internacional, la Comisión Internacional Electrotécnica - IEC; www.iec.ch/), fundada en 1906, IEC prepara y publica estándares internacionales para todas las tecnologías eléctricas, electrónicas y relacionadas. A partir del 1 de noviembre de 2004, los comités nacionales de 64 países fueron los miembros válidos de esta comisión. IEC también publica recomendaciones que salen en inglés y francés y realizan el estado de las normas internacionales. Se basan en estándares regionales y nacionales. Los comités técnicos (TC) son responsables de la preparación de estándares en diversas áreas de las actividades de IEC, y también participan los comités nacionales interesados \u200b\u200ben las actividades de un TC.

IEC. - Organización clave en la preparación de estándares internacionales para la tecnología de la información. Esta área tiene un comité técnico conjunto de tecnología de la información - JTC 1 formada en 1987 de conformidad con el acuerdo entre IEC e ISO. JTC1 tiene 17 subcomités que supervisan todo el desarrollo, desde el software hasta las lenguas de programación, los gráficos de computadora y las imágenes de edición, interconexiones de equipos y métodos de seguridad.

La preparación de nuevos estándares de IEC incluye varias etapas (preliminar, etapa de suministro, preparatoria, etapa del comité técnico, etapa de solicitud, aprobación, publicación). Si se planea que el documento IEC sea solo una especificación técnica, y no una norma internacional, la versión revisada del documento se envíe a la oficina central para su publicación. Para el desarrollo del proyecto final de la norma internacional (FDIS), se dan cuatro meses. Si todos los miembros del Comité Técnico están aprobados, va a la Oficina Central para publicar sin la etapa de aprobación de la FDIS. Después de eso, FDIS cae en comités nacionales para aprobarlo dentro de dos meses. FDIS se considera aprobada si hay más de dos tercios de los comités nacionales votados por él, y la cantidad de votos negativos no supera el 25%. Si el documento no está aprobado, se envía para revisar los comités técnicos y los subcomités. El estándar debe publicarse a más tardar dos meses después de la aprobación de la FDI.

Algunas organizaciones más están relacionadas con el desarrollo y la adopción de los estándares POSIX.

Grupo abierto. - Organización internacional para la estandarización de software, que combina a casi 200 fabricantes y comunidades de usuarios que trabajan en el campo de la tecnología de la información (www.opengroup.org/) .opengroup se creó en 1995 al fusionar a los dos predecesores: X / Open y Open Software Foundation ( OSF). El grupo abierto se especializa en el desarrollo de metodologías de certificación de software y pruebas para el cumplimiento de ciertos requisitos. En particular, Open Group está certificado por áreas como la plataforma COE, CORBA, LDAP, Base estándar de Linux, Marco de Interoperabilidad de las escuelas (SIF), Gateway S / MIME, Especificaciones de un solo Unix, Especificaciones de protocolo de aplicación inalámbrica (WAP) y Finalmente Familia de POSIX Normas (www.opengroup.org/certification/).

AustinCommonStandardSRevisionGroup (CSRG) - El Grupo de Trabajo Técnico Unido se formó en 2002 ISO, IEC y grupo abierto para crear y mantener las últimas versiones de la norma 1003.1, que se formará según ISO / IEC 9945-1-1996, ISE / IEC 9945-2-1993 , IEEE STD 1003.1-1996, IEEE STD 1003.2-1992 y una especificación única UNIX (www.opengroup.org/press/14nov02.htm).

Instituto Nacional de Normas y Tecnología (NIST) - La Agencia Federal cumplió con la Administración de Tecnología del Departamento de Comercio (www.nist.gov/public_affairs/general2.htm), fundada en los Estados Unidos en 1901. La tarea de NIST es el desarrollo y la propaganda de las normas y tecnologías para mejorar la calidad del producto. El NIST incluye el laboratorio de tecnología de la información. Laboratorio de tecnología de la información - ITL)Uno de los resultados de los cuales son los estándares federales de procesamiento de la información (estándares de procesamiento de información federal - FIPS, www.opengroup.org/testing/fips/general_info.html).nist/itl ofrecido en 1991 el conjunto inicial de pruebas para la certificación POSIX en 1991 Dentro de FIPS PUB 151-1 1990.

¿Qué es POSIX?

Término formal POSIX. propuesto por Richard Stallman (Richard Stallman) como una abreviatura de pag.ortable. O.privador S.interfaz de ystem para la ONU Ix. (Interfaz portátil de sistemas operativos para UNIX). POSIX se desarrolló para sistemas operativos similares a Unix (sus primeras versiones cuentan con el comienzo de los años 70) para garantizar la portabilidad de las aplicaciones a nivel de código fuente.

La descripción inicial de la interfaz se publicó en 1986, luego se llamó IEEE-IX (versión de IEEE de UNIX). Sin embargo, el nombre cambió rápidamente, convirtiéndose en POSIX, y ya en la siguiente publicación (en 1986) se utilizó esta nueva versión. Durante algún tiempo bajo POSIX, la referencia (o sinónimo) se entendió como un grupo de documentos relacionados con IEEE 1003.1-1988 y parte de ISO / IEC 9945, y como estándar internacional y aprobado ISO / IEC estándar 9945.1: 1990 se adoptó POSIX en 1990. Las especificaciones de POSIX definen la norma el mecanismo de interacción entre el programa de aplicación y el sistema operativo y actualmente incluye más de 30 estándares bajo los auspicios de IEEE, ISO, IEC y ANSI.

A lo largo de su historia, POSIX ha pasado por mucho tiempo, mientras que muchas veces cambió las designaciones de especificaciones, su contenido específico, procedimientos y logística de su verificación. En el pasado, se emitieron varias ediciones del estándar POSIX en varias organizaciones internacionales.

Historial de desarrollo estándar POSIX

La primera versión de la especificación IEEE STD 1003.1 se publicó en 1988. Posteriormente, se adoptaron numerosas ediciones de IEEE STD 1003.1 como estándares internacionales. Etapas de desarrollo POSIX:

- 1990 La oficina editorial lanzada en 1988 fue rediseñada y se convirtió en la base para otras ediciones y adiciones. Fue aprobado como una norma internacional ISO / IEC 9945-1: 1990.

- 1993 Viene la Oficina Editorial de 1003.1B-1993.

- 1996 IEEE STD 1003.1B-1993, se hicieron IEEE STD 1003.1C-1995 y 1003.1i-1995, pero la parte principal del documento se mantuvo sin cambios. En 1996, la edición de IEEE STD 1003.1 también fue aprobada como una norma internacional ISO / IEC 9945-1: 1996.

- 1998 Hay un primer estándar para "tiempo real" - IEEE STD 1003.13-1998. Esta es la expansión del estándar POSIX para aplicaciones en tiempo real incorporadas.

- 1999 Se decidió realizar cambios significativos en el texto principal de la norma durante los últimos 10 años, incluida la unificación con el estándar 1003.2 (Shell y Utilities), ya que en ese momento estos eran estándares separados. PASC decidió terminar de cambiar el texto básico después de la finalización de los estándares de IEEE 1003.1A, 1003.1D, 1003.1G, 1003.1j, 1003.1q y 1003.2b.

- 2004 Hoy en día, la placa editorial de 1003.1 fue publicada el 30 de abril y fue liberado bajo los auspicios de Austin Common Standards Revisión Group. Hizo cambios con respecto al Consejo Editorial de 2001. Formalmente, la Oficina Editorial de 2004 se conoce como IEEE STD 1003.1, Edición 2004, las especificaciones de la base de la Norma Técnica del Grupo Abierto, el número 6 e incluye IEEE STD 1003.1-2001, IEEE STD 1003.1-2001 / COR 1-2002 e IEEE STD 1003.1-2001 / COR 2-2004.

Los estándares más importantes de POSIX para RV OS

Para los sistemas operativos en tiempo real, las siete especificaciones estándar son las más importantes, pero solo tres fueron ampliamente apoyadas en el sistema operativo comercial:

1003.1A (Definición OS) define las interfaces básicas del sistema operativo, la gestión de trabajos, las señales, las funciones sistema de archivos y trabajar con dispositivos, grupos de usuarios, transportadores, buffers FIFO;

1003.1B (extensiones en tiempo real) describe extensiones en tiempo real, como la señalización en tiempo real, el despacho prioritario, los temporizadores, la entrada síncrona y asíncrona, semáforos, memoria compartida, mensajes. Inicialmente (hasta 1993), esta norma se indicó como POSIX.4;

1003.1c (hilos) define las funciones de soporte de la corriente (hilos): control de flujo, atributos de flujo, mutex, envío. Originalmente designado como POSIX.4A.

Además de estas normas, las siguientes normas son importantes para el RV, que se implementaron como parte del Proyecto STD 1003.1-2001:

IEEE 1003.1D-1999. Expansiones adicionales de tiempo real. Inicialmente designado como POSIX.4B;

IEEE 1003.1J-2000. Expansión mejorada (avanzada) en tiempo real;

IEEE 1003.1q-2000. Rastreo.

Procedimiento de certificación

Para cumplir con el estándar POSIX, el sistema operativo debe estar certificado de acuerdo con los resultados del conjunto de pruebas correspondiente. Desde la aparición de POSIX, el conjunto de pruebas ha sufrido cambios formales y reales.

En 1991, NIST ha desarrollado un programa de prueba POSIX dentro de FIPS 151-1 (http://sandards.ieee.org/regauth/POSIX/POSIX-A.FM5.PDF). Esta opción de prueba se basó en el estándar IEEE 1003.3 "para los métodos de prueba para medir la conformidad con el POSIX" Draft 10, mayo 3, 1989. En 1993, NIST se graduó del programa de prueba para FIPS 151-1 y comenzó un programa para FIPS 151 -2 (www.itl.nist.gov/fipspubs/fip151-2.htm).fips 151-2 Adaptada "Tecnología de la información - Interfaz del sistema operativo portátil (POSIX) - Parte 1: Interfaz del programa de aplicación del sistema (API)," Audio ISO / IEC 9945-1: 1990 estándar. Los conjuntos de pruebas para FIPS 151-2 se basaron en el estándar IEEE 2003.1-1992 "para los métodos de prueba para medir la conformidad con POSIX".

NIST distingue a dos metodologías de certificación: autocertificación (autocertificación) y certificación acreditada en laboratorios de pruebas de IEEE (laboratorios de prueba de POSIX acreditados - APTL). En el primer caso, la compañía realiza pruebas de manera independiente, pero según el plan aprobado en NIST. En el segundo caso, la prueba es realizada por un laboratorio independiente utilizando conjuntos de pruebas automatizados. Dos laboratorios APTL fueron acreditados: MindaCraft (www.mindcraft.com) y perenne (www.peren.com).

En 1997, NIST / ITL anunció su intención de cancelar la certificación de FIPS 151-2 al final del año en curso (oficialmente - 31 de diciembre de 1997), al mismo tiempo, el grupo abierto anunció que iba a tomar el 1 de octubre. El año del servicio de certificación de acuerdo con FIPS 151-2, basado en el programa NIST / ITL. Las mismas funciones del 1 de enero de 1998 asumieron la Asociación de Normalización de IEEE (IEEE-SA), y también basadas en FIPS 151-2.

En 2003, IIEE-SA y Open Group anunció el comienzo de un nuevo programa conjunto para la certificación de las versiones recientes de POSIX, comenzando con IEEE 1003.1 (TM) 2001. Ahora el grupo abierto tiene varias pruebas que cubren IEEE STD 1003.1-1996, IEEE STD 1003.

2-1992, IEEE STD 1003.1-2003 e IEEE STD 1003.13-1998 (www.opengroup.org/testing/testsuites/POSIX.HTML). El producto se considera certificado por POSIX si aprobó el procedimiento de certificación completo, de acuerdo con los resultados de las pruebas, satisface todos los requisitos presentados y se enumeran en el Registro Oficial de Productos Certificados.

Los conjuntos de pruebas incluyen:

VSX-PCTS1990 (www.opengroup.org/testing/testsuites/vsxpcts1990.htm): un conjunto de pruebas de conformidad para las interfaces del sistema IEEE STD 1003.1-1990;

Vspse54 (www.opengroup.org/testing/testsuites/vspse54.htm) - Un conjunto de pruebas de conformidad para IEEE STD 1003.13-1998 PERFIL PSE54 (tiempo real multiuso);

VSX-PCTS2003 (www.opengroup.org/testing/testsuites/vsxpcts2003.htm): un conjunto de pruebas de conformidad para las interfaces del sistema IEEE STD 1003.1-2003 (solo partes obligatorias);

VSC-PCTS2003 (www.opengroup.org/testing/testsuites/vscpppts2003.htm): un conjunto de pruebas de conformidad para IEEE STD 1003.1-2003 (Shell y Utilidades, solo partes obligatorias).

Además, Open Group ha desarrollado pruebas para las normas de tiempo real de POSIX y el perfil incorporado de los estándares POSIX. Un conjunto de pruebas para POSIX RealTime (www.opengroup.org/testing/testsuites/realtime.html) incluye las siguientes pruebas:

IEEE POSIX 1003.1B-1993/113.1I-1995 Extensión en tiempo real e IEEE POSIX 1003.1,2003 Edición;

IEEE STD POSIX 1003.1C-1995 Hilos (PTHEADS) Extensión e IEEE POSIX 1003.1,2003 Edición;

IEEE POSIX 1003.1D-1999 Extensión en tiempo real adicional y IEEE POSIX 1003.1,2003 Edición;

IEEE POSIX 1003.1j-2000 Extensión avanzada de RealTim y IEEE POSIX 1003.1,2003 Edición;

IEEE POSIX 1003.1q-2000 Trace y IEEE POSIX 1003.1,2003 Edición y IEEE POSIX 1003.1,2003 Edición;

Conjunto de pruebas de perfiles de estándares POSIX EMBEDDED (www.opengroup.org/testing/testsuites/EMBEDDED.HTML) Incluye las siguientes pruebas:

IEEE POSIX 1003.1-1990 (5310 pruebas);

IEEE POSIX 1003.1B-1993/113.1I-1995 Extensión en tiempo real (1430 pruebas);

IEEE STD POSIX 1003.1C-1995 extensión hilos (PTHEADS) (1232 prueba);

IEEE POSIX 1003.13-1998 Perfil 52.

Un poco de confusión en la terminología.

En relación con el grupo de estándares POSIX en inglés, no uno, sino hasta tres términos. Desafortunadamente, son similares en valor y a menudo se traducen por igual, lo que trae cierta confusión. Términos Estos son:

Compatibilidad (compatibilidad literalmente ");

Cumplimiento (literalmente "Cumplimiento");

Sonformance (literalmente "consistencia").

El primer término aplicado a POSIX no se define formalmente. El segundo significa que la organización es un productor de software declara de manera independiente que este producto (total o parcialmente) cumple con los siguientes estándares de NIST-PCTS. El tercer término implica que el software ha pasado. sistema instalado Pruebas usando un laboratorio acreditado o dentro del grupo abierto y esto tiene una confirmación documental (la llamada declaración de conformidad). Además, en el texto del artículo en todas partes, habrá originales de los términos para excluir la ambigüedad.

OS RV certificado.

Si se adhiere a las normas estrictas que requieren que los datos sobre el OS RV certificados se publiquen en el Registro Oficial y se realizaron pruebas por nivel conformidadActualmente, solo tiene dos operaciones operativas certificadas (los datos se dan en orden cronológico):

- Lynxos v.3. (El producto de la compañía Lynx Systems en tiempo real, que ahora se llama Lynuxworks, Inc., www.lynuxworks.com) está diseñado para el desarrollo de sistemas incorporados que operan en fabricantes difíciles en tiempo real, fabricantes de equipos completos y de telecomunicaciones, En particular los fabricantes de sistemas a bordo de uso militar. El desarrollo se puede realizar tanto en el sistema de destino (auto-alojado) como en la computadora de la herramienta (host), listo para diseñar para trabajar en el sistema de destino (objetivo). Lynxos V.3 está certificado por consistencia (Conformidad)posix estándar en la plataforma Intel y PowerPC. La información sobre esto se puede encontrar en el sitio web de IEEE http://standards.ieeee.org/regauth/posix/posix2.html.lynxos certificado por POSIX 1003.1-1996 Mindcraft, que es el laboratorio de pruebas de POSIX acreditado por IEEE POSIX para NIST FIPS 151 Pruebas 2 Suite de prueba de conformidad. Certificación de confirmación del número de documento: archivo de referencia: IP-2LYX002, archivo de referencia: IP-2LYX001.

- Integridad v.5 (El producto de la empresa Green Hills Software, www.ghs.com) está certificado por consistencia (Conformidad) Por POSIX 1003.1-2003, interfaces del sistema para la arquitectura PowerPC en julio de 2004 (http://get.positixcertified.ieee.org/select_product.tpl). Conjunto de pruebas VSX-PCTS 2003.

Sistema operativo POSIX y QNX

QNX V.4.20(Desarrollador - Sistemas de software QNX firmes, www.qnx.com) certificado para su cumplimiento (CUMPLIMIENTO) POSIX 1003.1-1988 para la plataforma Empresa de intel DataFocus incorporado. La prueba se realizó el 13 de septiembre de 1993, la fecha de emisión del documento: 1 de noviembre de 1993. Conjunto de pruebas NIST PCTS 151-1, versión 1.1.

QNX Neutrino (versión 6.3) cumple (cumple a) Siguientes Normas de la Familia POSIX (www.qnx.com/download/download/8660/portability.pdf):

POSIX.1 (IEEE 1003.1);

POSIX.1A (IEEE 1003.1A);

Posix.2 (IEEE 1003.2);

Posix.4 (IEEE 1003.1B);

Posix.4a (IEEE 1003.1c);

POSIX.1B (IEEE 1003.1D), IEEE 1003.1J;

Posix.12 (IEEE 1003.1G).

QNX Software Systems, el Creador de QNX Neutrino, también planea certificar (conformes) QNX Neutrino de acuerdo con algunas de estas normas; Las obras están programadas para 2005 (www.qnx.com/news/pr_959_1.html).

Literatura

1. Manual de operación de la Asociación de Estándares de IEEE. IEEE, octubre de 2004.

2. Kevin M. Oonseland.. POSIX en tiempo real, programación de sistemas incorporados, 2001.

3. Norma IEEE / ANSI 1003.1: Tecnología de la información - (POSIX) - Part1: Aplicación del sistema: Interfaz del programa (API).

4. Gallmeister B. O. Programación para el mundo real, POSIX.4 Sebastopol, CA: O'Reilly & Associates, 1995.

5. Instituto Nacional de Normas y Tecnología, PCT: 151-2, POSIX Test Suite.

6. POSIX: Certificado por IEEE y el grupo abierto. Política certificada. El grupo abierto, 21 de octubre de 2003, revisión 1.1.

Software) - la tarea de importancia y complejidad excepcionales; Hoy en día, esta circunstancia apenas necesita justificaciones extensas. Una de las formas generalmente aceptadas de mejorar la movilidad del software está estandarizando el entorno de las aplicaciones: interfaces de programación proporcionadas, utilidades, etc. A nivel servicios del sistema Un entorno similar describe el estándar POSIX (Interfaz del sistema operativo portátil - Interfaz del sistema operativo móvil); El nombre es propuesto por un especialista bien conocido, el fundador de la Fundación Free Software Richard Tornen.

Consideraremos las versiones más modernas de la norma POSIX, modificada en 2003, que se puede llamar "Triple estándar", a saber: IEEE STD 1003.1 estándar, Norma técnica Grupo abierto y (consulte [6]), lo que es más importante para nosotros, la norma internacional ISO / IEC 9945 (ver [1], [2], [3], [4]).

La historia de crear esta versión es tal. A principios de 1998, representantes de tres organizaciones: el Comité de Normas de Applicaciones Móvil Instituto de Ingenieros de Ingeniería Eléctrica y Instituto de Electrónica, Grupo Abierto y Grupo de Trabajo 15 del Subcomité 22 del Comité Técnico Conjunto 1 (JTC1 / SC22 / WG15) de la Internacional Organización para la estandarización: comenzó a consultar sobre la fusión y el desarrollo de las normas de la interfaz supervisadas por ellos a los servicios del sistema: IEEE STD 1003.1, IEEE STD 1003.2, especificaciones básicas del grupo abierto, ISO / IEC 9945-1, ISO / IEC 9945-2. En septiembre del mismo año en la ciudad de Austin, Texas, una reunión organizativa del Grupo formada para lograr el objetivo (ver http://www.opengroup.org/austin) tuvo lugar en la oficina de IBM.

El documento fundamental para la norma revisada, cuyo primer proyecto se presentó en julio de 1999, fueron las especificaciones básicas del grupo abierto, ya que incluían las disposiciones de las normas IEEE e ISO / IEC. En 2001, al finalizar el trabajo preparatorio, la norma contenía las siguientes cuatro partes:

definiciones principales (términos, conceptos e interfaces comunes a todas las partes);
descripción aplicación C-interfaz a los servicios del sistema;
descripción de la interfaz a los servicios del sistema a nivel. lenguaje de comando y programas de servicio ;
una explicación detallada de las disposiciones estándar, la justificación de las decisiones tomadas.

Además, en ISO, IEEE y grupo abierto con una velocidad mayor o menor (en 2001-2002), ha aprobado una aprobación formal del nuevo estándar POSIX. Mientras tanto, se acumularon correcciones relativamente menores, tenidas en cuenta en el año 2003.

Con el desarrollo de la norma, la interpretación del término "POSIX" se estaba expandiendo. Inicialmente, se refirió a IEEE STD 1003.1-1988, descrito interfaz del programa de aplicación Clase OS UNIX. Después de estandarizar la interfaz en el nivel de idioma y los programas de servicio, se entiende más correctamente bajo la palabra "POSIX" estándar en general, que denota la parte 2 y 3 que se enumeran anteriormente a través de POSIX .1 y POSIX .2 de acuerdo con la numeración de Documentos IEEE y ISO / IEC.

Las ideas principales de la POSIX estándar.

El estándar POSIX describe una pluralidad de servicios básicos de sistema requeridos para el funcionamiento de las aplicaciones. El acceso a ellos es proporcionado por una interfaz especificada para el C, Idioma de comando y programas de servicio comunes.

Cada interfaz tiene dos lados: causando y llamado. El estándar POSIX está orientado principalmente a la llamada. Su objetivo es hacer solicitudes. móvil en el nivel de idioma de origen. Esto significa, en particular, que al transferir los programas C a otra plataforma operativa, se requerirá la recompilación. Acerca de la movilidad de los programas ejecutables y / o los archivos de objetos no importa.

POSIX Standard no se limita al marco de entorno UNIX. Hay sistemas operativos (OS) "Origen independientes" (por ejemplo, sistemas en tiempo real), proporcionando los servicios necesarios y, por lo tanto, apoyando la ejecución de solicitudes postizables. Se puede argumentar que después del estándar POSIX facilita la transferencia de aplicaciones a casi cualquier plataforma operativa común. Los esfuerzos adicionales para mejorar la movilidad adjuntos durante la fase de desarrollo definitivamente pagarán.

Determinar la interfaz a los servicios del sistema, POSIX abandona el marco de su implementación. En particular, no distinguir. llamadas del sistema y funciones de la biblioteca. No son un objeto de medios de normalización. administración, limitaciones de hardware y funciones necesarias solamente súper sucesorLo que una vez más enfatiza el foco de la norma.

Hoy intentaremos averiguar qué describe el estándar POSIX. Los estándares están destinados a garantizar que mi computadora pueda interactuar con la suya. Gracias a ellos, en dos computadoras web similares o video de transmisión en tiempo real se verán igualmente.

Sin embargo, la norma está destinada a tareas más grandes que un simple intercambio de datos entre usuarios. Algunas normas definen un modelo especial, gracias a las características que son significativamente superiores en su compatibilidad con el valor de los archivos o redes. El estándar POSIX se refiere a su número.

¿Qué es POSIX?

POSIX (pronunciado "Posiks") es una interfaz del sistema operativo portátil. Pero, ¿qué significa? Primero, debe designar el área del concepto de "portabilidad", en este caso concretoy decidir sobre el concepto de "interfaz". Para averiguar esto, es necesario repelirse del hecho de que ambos conceptos están inextricablemente vinculados.

"Portabilidad", en el contexto del estándar POSIX, se refiere a código fuente (No al binario que se recolectan de estas fuentes. Ahora averigüe qué es la "interfaz". En la programación, la "interfaz" es la interacción de su código con el resto del código. La interfaz está esperando la provisión de información específica de su código. Su código, a su vez, implica obtener cierta información de la interfaz. Buen ejemplo - FOPEN () FUNCIÓN EN SI. Espera información de dos partes: la ruta al archivo y el modo en el que se abrirá. Usando estos datos, el sistema operativo devuelve otro tipo de información llamada "descriptor de archivo". El mango de archivo se puede utilizar para leer el archivo o escribir en el archivo. Esta es la interfaz. De todo esto se deduce que se puede compilar un código compatible con POSIX en cualquier sistema operativo compatible con POSIX sin cambios importantes, lo que significa que será portátil.

Sin embargo, la lista de interfaces relacionadas con el estándar POSIX es, sin embargo, a pesar de su enorme longitud, es posible que sea deficiente. POSIX no se limita a los desafíos del sistema, sino que también define los estándares para conchas de sistemas operativos (estantes, de lo contrario, interfaces línea de comando), utilidades del sistema, como "AWK" o "Echo", bibliotecas del sistema y muchas otras cosas.

El estándar POSIX apareció en forma de un proyecto de Richard Pokalman en 1985 y se decoró aún más como IEEE STD 1003.-1998. Como se puede ver desde el nombre, 1998 fue el año de publicación oficial. Desde entonces, se han lanzado una gran cantidad de adiciones y extensiones para POSIX, que se convierte gradualmente en una familia de estándares, conocida formalmente como IEEE 1003, reconocida como una internacional, con la designación de SO / IEC 9945, simplemente llamada POSIX Estándar familiar.

El sistema operativo no es necesario ser compatible con POSIX o incluso más que tener un certificado POSIX, sin embargo, permite a los desarrolladores crear aplicaciones, herramientas y plataformas, sin reescribir el código una vez por tiempo, pero solo complementan y se conectan a listo para -terminar. Tampoco es necesario escribir un código compatible con POSIX, pero esto mejora significativamente la portabilidad de los proyectos entre los sistemas operativos. Esto significa que la capacidad de escribir un código que es compatible con el estándar POSIX es valioso en sí mismo, y ciertamente es muy útil para una carrera. Proyectos grandes, como GNOME o KDE, se adhieren a la norma POSIX, que garantiza su trabajo en diferentes sistemas operativos. El subsistema POSIX se implementa incluso en cuestiones recientes Windows. Linux, como usted sabe, es compatible con la mayoría de las llamadas del sistema relacionadas con el estándar POSIX, así como una extensión grande, llamada "Base de Linux estándar", que está diseñada para combinar las distribuciones de Linux en términos de soporte de código fuente y datos binarios .

Espero que arrojemos la luz a la pregunta "¿Qué es POSIX"? ¿Tienes información interesante sobre el tema? Por favor, comparte en los comentarios.

POSIX y OS RV: intento de sistematización

Sergey Zolotarev, Nikolai Gorbunov

El propósito de este artículo es intentar tomar cierta claridad en el historial de desarrollo de la norma POSIX en relación con los sistemas operativos en tiempo real (OS RV).

Como introducción: ¿Por qué necesita una estandarización de la interfaz de programación?

reutilizar código de proyectos pasados \u200b\u200by paralelos;
transferencia de código de otro sistema operativo;
atraer a los desarrolladores de otros proyectos (incluido el uso de otro sistema operativo).

Por lo tanto, utilizando un sistema operativo compatible con POSIX como plataforma para sus proyectos, el desarrollador puede transferir el código terminado en el nivel del código fuente a partir de sus proyectos pasados \u200b\u200bo paralelos y de proyectos de terceros. Esto no solo reduce significativamente el momento del desarrollo del software, sino que también mejora su calidad, ya que el código probado siempre contiene menos errores.

Quién es quien en el desarrollo de POSIX.

Y comencemos con el Posix Muy estándar, pero al ordenar el papel de las organizaciones involucradas en trabajar en él.

El primer participante es IEEE. Instituto de Ingenieros Eléctricos y Electrones, Instituto de Ingenieros de Electricistas y Electrónica), Asociación Pública de Profesionales sin fines de lucro. IEEE lidera su historia desde 1884 (formalmente, desde 1963), combina a 380,000 miembros individuales de 150 países, publica la tercera parte de la literatura técnica relativa al uso de computadoras, gestión, tecnologías eléctricas e informativas, así como más de 100 revistas, popular en el medio ambiente de los profesionales; Además, la asociación es por año más de 300 conferencias importantes. IEEE participó en el desarrollo de más de 900 estándares existentes (www.ieee.ru/ieeee.htm). Hoy en día, este Instituto está involucrado en la preparación, aprobación, aprobación, las normas de publicación, pero en su estado formal no tiene la autoridad para aceptar dichos documentos como estándares internacionales o nacionales. Por lo tanto, el término "estándar" en la comprensión de IEEE debe entenderse como "especificación", que es más responsable del estado de los documentos tomados por la Asociación. De acuerdo con IEEE, participa en los programas de una serie de organizaciones internacionales y regionales: IEC, ISO, UIT (Instituto Europeo de Normas de Telecomunicaciones para la Handartización electrotécnica) y en programas nacionales, como el programa de una organización como ANSI.

IEEE incluye PASC (Comité de Normas de Aplicaciones Portátiles) - Comisión de Asociación, que está desarrollando una familia de estándares POSIX (www.pasc.org/). Anteriormente, PASCC fue conocido como el Comité Técnico de Operaciones.

El segundo participante del trabajo. ANSI. (American National Standards Institute, American National Standards Institute): una organización privada sin fines de lucro que administra y coordinan en los Estados Unidos sobre temas de normalización. Solo emplea a 75 personas, pero los miembros de ANSI son más de 1,000 empresas, organizaciones, agencias gubernamentales e instituciones (www.ansi.org). ANSI representa a los Estados Unidos en dos principales organizaciones internacionales para la estandarización: ISO y IEC.

Tercer participante - YO ASI. Organización internacional para la estandarización, organización internacional para la estandarización). Se creó en 1946 por decisión del Comité de Coordinación de las Normas y la Asamblea General de las Naciones Unidas y comenzaron oficialmente el 23 de febrero de 1947 (www.iso.org). ISO es una red de instituciones nacionales de normalización de 146 países (un país es un miembro ISO) con la Secretaría Central en Ginebra (Suiza). Las normas ISO se desarrollan en los comités técnicos, el primer resultado de los cuales es un proyecto de documento estándar internacional (DIS), convirtiéndose después de varias coincidencias en el estándar final del Draft Internacional (FDIS). Después de eso, la cuestión de la aprobación de este documento se hace a votación; Con un resultado positivo, se convierte en un estándar internacional.

Finalmente, - IEC. Comisión Electrotécnica Internacional, Comisión Electrotécnica Internacional - IEC), fundada en 1906, IEC prepara y publica estándares internacionales para todas las tecnologías eléctricas, electrónicas y relacionadas (www.iec.ch/). A partir del 1 de noviembre de 2004, los comités nacionales de 64 países fueron los miembros válidos de esta comisión. IEC también publica recomendaciones que salen en inglés y francés y realizan el estado de las normas internacionales. Se basan en estándares regionales y nacionales. Los comités técnicos (TC) son responsables de la preparación de estándares en diversas áreas de las actividades de IEC, y también participan los comités nacionales interesados \u200b\u200ben las actividades de un TC.

IEC es una organización clave en la preparación de estándares internacionales para la tecnología de la información. Esta área tiene un comité técnico conjunto de tecnología de la información - JTC 1 formada en 1987 de conformidad con el acuerdo entre IEC e ISO. JTC1 tiene 17 subcomités que supervisan todo el desarrollo, desde el software hasta las lenguas de programación, los gráficos de computadora y las imágenes de edición, interconexiones de equipos y métodos de seguridad.

Algunas organizaciones más están relacionadas con el desarrollo y la adopción de los estándares POSIX.

Grupo abierto. - Organización internacional para la estandarización de software, que reúne a casi 200 fabricantes y comunidades de usuarios que trabajan en el campo de la tecnología de la información (www.opengroup.org/). El grupo abierto se creó en 1995 al fusionar a los dos predecesores: Fundación X / Open y Open Software (OSF). El grupo abierto se especializa en el desarrollo de metodologías de certificación de software y pruebas para el cumplimiento de ciertos requisitos. En particular, Open Group está certificado por áreas como la plataforma COE, CORBA, LDAP, Base estándar de Linux, Marco de Interoperabilidad de las escuelas (SIF), Gateway S / MIME, Especificaciones de un solo Unix, Especificaciones de protocolo de aplicación inalámbrica (WAP) y Finalmente Familia de POSIX Normas (www.opengroup.org/certification/).

Grupo de revisión de estándares comunes de Austin (CSRG) - El Grupo de Trabajo Técnico Unido se formó en 2002 ISO, IEC y grupo abierto para crear y mantener las últimas versiones de la norma 1003.1, que se formará según ISO / IEC 9945-1-1996, ISE / IEC 9945-2-1993 , IEEE STD 1003.1-1996, IEEE STD 1003.2-1992 y una especificación única UNIX (www.opengroup.org/press/14nov02.htm).

Instituto Nacional de Normas y Tecnología (NIST) - La Agencia Federal cumplió con la Administración de Tecnología del Departamento de Comercio (www.nist.gov/public_affairs/general2.htm), fundada en los Estados Unidos en 1901. La tarea de NIST es el desarrollo y la propaganda de las normas y tecnologías para mejorar la calidad del producto. NIST incluye un laboratorio de tecnología de la información (ITL), uno de los resultados de las actividades de procesamiento de información federal (estándares federales de procesamiento de información: FIPS, www.opengroup.org/testing/fips/general_info.html). NIST / ITL ofrecido en 1991 el conjunto inicial de pruebas para la certificación POSIX bajo FIPS PUB 151-1 1990.

¿Qué es POSIX?

Término formal POSIX. propuesto por Richard Stallman (Richard Stallman) como una abreviatura de pag.ortable. O.privador S.interfaz de ystem para la ONU Ix. (Interfaz portátil de sistemas operativos para UNIX). POSIX se desarrolló para sistemas operativos similares a Unix (sus primeras versiones cuentan con el comienzo de los años 70) para garantizar la portabilidad de las aplicaciones a nivel de código fuente.

La descripción inicial de la interfaz se publicó en 1986, luego se le llamó la versión IEEE-IX (IEEE "de UNIX). Sin embargo, el nombre ha cambiado rápidamente, convirtiéndose en POSIX, y esta nueva versión se ha utilizado en la siguiente publicación. (de vuelta en 1986). Durante algún tiempo bajo POSIX, la referencia (o sinónimo) se entendió como un grupo de documentos relacionados con IEEE 1003.1-1988 y parte de ISE / IEC 9945, y como estándar internacional y aprobado ISO / IEC estándar 9945.1: 1990 Se adoptó POSIX en 1990. Las especificaciones POSIX definen el mecanismo estándar para la interacción entre el programa de aplicación y el sistema operativo y actualmente incluyen más de 30 estándares bajo los auspicios de IEEE, ISO, IEC y ANSI.

Historial de desarrollo estándar POSIX

La primera versión de la especificación IEEE STD 1003.1 se publicó en 1988. Posteriormente, se adoptaron numerosas ediciones de IEEE STD 1003.1 como estándares internacionales.

Etapas de desarrollo POSIX:

1990

La Oficina Editorial emitida en 1988 se recicló y se convirtió en la base para otros editores y adiciones. Fue aprobado como una norma internacional ISO / IEC 9945-1: 1990.

1993

Viene la Oficina Editorial de 1003.1B-1993.

1996

IEEE STD 1003.1B-1993, se hicieron IEEE STD 1003.1C-1995 y 1003.1i-1995, pero la parte principal del documento se mantuvo sin cambios. En 1996, la edición de IEEE STD 1003.1 también fue aprobada como una norma internacional ISO / IEC 9945-1: 1996.

1998

Hay un primer estándar para "tiempo real" - IEEE STD 1003.13-1998. Esta es la expansión del estándar POSIX para aplicaciones en tiempo real incorporadas.

1999

Se decidió hacer cambios significativos en el texto principal de la norma durante los últimos 10 años, incluida la Unión con el estándar 1003.2 (Shell y Utilities), ya que en el momento en que era estándares separados. PASC decidió terminar de cambiar el texto básico después de la finalización de los estándares de IEEE 1003.1A, 1003.1D, 1003.1G, 1003.1j, 1003.1q y 1003.2b.

2004

Hoy en día, la placa editorial de 1003.1 fue publicada el 30 de abril y fue liberado bajo los auspicios de Austin Common Standards Revisión Group. Hizo cambios con respecto al Consejo Editorial de 2001. Formalmente, la Oficina Editorial de 2004 se conoce como IEEE STD 1003.1, Edición 2004, las especificaciones de la base de la Norma Técnica del Grupo Abierto, el número 6 e incluye IEEE STD 1003.1-2001, IEEE STD 1003.1-2001 / COR 1-2002 e IEEE STD 1003.1-2001 / COR 2-2004.

Los estándares más importantes de POSIX para RV OS

Para los sistemas operativos en tiempo real, siete especificaciones estándar son las más importantes (1003.1a, 1003.1j, 1003.1c, 1003.1d, 1003.1j, 1003.21), pero solo tres fueron ampliamente apoyadas en el sistema operativo comercial:

1003.1A (Definición OS) Especifica las interfaces básicas del sistema operativo, administración de trabajos, señales, funciones y dispositivos del sistema de archivos, grupos de usuarios, transportadores, buffers de FIFO;
1003.1b (extensiones en tiempo real) Describe extensiones en tiempo real, como la señalización en tiempo real, el despachador prioritario, los temporizadores, la entrada síncrona y asíncrona, semáforos, memoria compartida, mensajes. Inicialmente (hasta 1993), esta norma fue designada como POSIX.4.
1003.1c (hilos) Define las funciones de soporte de la corriente (hilos): control de flujo, atributos de flujo, mutexes, envío. Originalmente designado como POSIX.4A.

Además de estas normas, las siguientes normas son importantes para el RV, que se implementaron como parte del Proyecto STD 1003.1-2001:

IEEE 1003.1D-1999. Expansiones adicionales de tiempo real. Inicialmente designado como POSIX.4B;
IEEE 1003.1J-2000. Expansión mejorada (avanzada) en tiempo real;
IEEE 1003.1q-2000. Rastreo.

Procedimiento de certificación

En 1991, NIST ha desarrollado un programa de prueba POSIX dentro de FIPS 151-1 (http://sandards.ieee.org/regauth/POSIX/POSIX-A.FM5.PDF). Esta opción de prueba se basó en el estándar IEEE 1003.3 "para los métodos de prueba para medir la conformidad con el POSIX" Draft 10, mayo 3, 1989. En 1993, NIST se graduó del programa de prueba para FIPS 151-1 y comenzó un programa para FIPS 151 -2 (www.itl.nist.gov/fipspubs/fip151-2.htm). FIPS 151-2 Adaptada "Tecnología de la información - Interfaz del sistema operativo portátil (POSIX) - Parte 1: Interfaz del programa de aplicación del sistema (API)," ISO / IEC 9945-1: 1990 estándar. Los conjuntos de pruebas para FIPS 151-2 se basaron en el estándar IEEE 2003.1-1992 "para los métodos de prueba para medir la conformidad con POSIX".

En 2003, IEEE-SA y Open Group anunció el comienzo de un nuevo programa conjunto para la certificación de las últimas versiones de POSIX, comenzando con IEEE 1003.1 ™ 2001. Ahora, el grupo abierto tiene varias pruebas que cubren IEEE STD 1003.1-1996, IEEE STD 1003.2-1992, IEEE STD 1003.1-2003 e IEEE STD 1003.13-1998 (www.opengroup.org/testing/testsuites/POSIX.HTML). El producto se considera certificado por POSIX si aprobó el procedimiento de certificación completo, de acuerdo con los resultados de las pruebas, satisface todos los requisitos presentados y se enumeran en el Registro Oficial de Productos Certificados.

Los conjuntos de pruebas incluyen:

VSX-PCTS1990 (www.opengroup.org/testing/testsuites/vsxpcts1990.htm): un conjunto de pruebas de conformidad para las interfaces del sistema IEEE STD 1003.1-1990;
Vspse54 (www.opengroup.org/testing/testsuites/vspse54.htm) - Un conjunto de pruebas de conformidad para IEEE STD 1003.13-1998 PERFIL PSE54 (tiempo real multiuso);
VSX-PCTS2003 (www.opengroup.org/testing/testsuites/vsxpcts2003.htm): un conjunto de pruebas de conformidad para las interfaces del sistema IEEE STD 1003.1-2003 (solo partes obligatorias);
VSC-PCTS2003 (www.opengroup.org/testing/testsuites/vscpppts2003.htm): un conjunto de pruebas de conformidad para IEEE STD 1003.1-2003 (Shell y Utilidades, solo partes obligatorias).

IEEE POSIX 1003.1B-1993/113.1I-1995 Extensión en tiempo real e IEEE POSIX 1003.1,2003 Edición;
IEEE STD POSIX 1003.1C-1995 Hilos (PTHEADS) Extensión e IEEE POSIX 1003.1,2003 Edición;
IEEE POSIX 1003.1D-1999 Extensión en tiempo real adicional y IEEE POSIX 1003.1,2003 Edición;
IEEE POSIX 1003.1j-2000 Extensión avanzada de RealTim y IEEE POSIX 1003.1,2003 Edición;
IEEE POSIX 1003.1q-2000 Trace y IEEE POSIX 1003.1,2003 Edición y IEEE POSIX 1003.1,2003 Edición;

Conjunto de pruebas de perfiles de estándares POSIX EMBEDDED (www.opengroup.org/testing/testsuites/EMBEDDED.HTML) Incluye las siguientes pruebas:

IEEE POSIX 1003.1-1990 (5310 pruebas);
IEEE POSIX 1003.1B-1993/113.1I-1995 Extensión en tiempo real (1430 pruebas);
IEEE STD POSIX 1003.1C-1995 extensión hilos (PTHEADS) (1232 prueba);
IEEE POSIX 1003.13-1998 Perfil 52.

Un poco de confusión en la terminología.

compatibilidad (compatibilidad literalmente ");
cumplimiento (literalmente "Cumplimiento");
sonformance (literalmente "consistencia").

El primer término aplicado a POSIX no se define formalmente. El segundo significa que la organización es un productor de software declara de manera independiente que este producto (total o parcialmente) cumple con los siguientes estándares de NIST-PCTS. El tercer término implica que el producto de software ha pasado el sistema de prueba establecido o utilizando un laboratorio acreditado o dentro del grupo abierto y esto tiene una confirmación documental (la denominada declaración de conformidad). Además, en el texto del artículo en todas partes, habrá originales de los términos para excluir la ambigüedad.

OS RV certificado.

Si se adhiere a reglas estrictas que requieren que los datos sobre el OS RV certificados se publiquen en el Registro Oficial y se realizaron pruebas en términos de conformidad, ahora solo hay dos operaciones operativos certificados (los datos se dan en orden cronológico):

Lynxos v.3. (El producto de la compañía Lynx Systems en tiempo real, que ahora se llama Lynuxworks, Inc., www.lynuxworks.com) está diseñado para el desarrollo de sistemas incorporados que operan en fabricantes difíciles en tiempo real, fabricantes de equipos completos y de telecomunicaciones, En particular los fabricantes de sistemas a bordo de uso militar. El desarrollo se puede realizar tanto en el sistema de destino (auto-alojado) como en la computadora de la herramienta (host), listo para diseñar para trabajar en el sistema de destino (objetivo). Lynxos V.3 está certificado por el estándar de consistencia (conformance) POSIX en la plataforma Intel y PowerPC. Esta información se puede encontrar en el sitio web de IEEE http://sandards.ieeee.org/regauth/POSIX/POSIX2.HTML. Lynxos está certificado por POSIX 1003.1-1996 por MINDCRAFT, que es el laboratorio de pruebas de POSIX acreditado por IEEE POSIX para la prueba de suite de prueba de conformidad FIPS 151-2. Certificación de confirmación del número de documento: archivo de referencia: IP-2LYX002, archivo de referencia: IP-2LYX001.

Integridad v.5 (El producto de la empresa Green Hills Software, www.ghs.com) está certificado por la consistencia (conformidad) por POSIX 1003.1-2003, interfaces del sistema para la arquitectura PowerPC en julio de 2004 (http://get.posixcertified.ieee.org/ select_product. TPL). Conjunto de pruebas VSX-PCTS 2003.

Sistema operativo POSIX y QNX

QNX V.4.20 (Desarrollador - Sistemas de software de QNX Firma, www.qnx.com) Certificado para el cumplimiento (Cumplimiento) por POSIX 1003.1-1988 para la plataforma Intel por DataFocus Incorporated. La prueba se realizó el 13 de septiembre de 1993, la fecha de emisión del documento: 1 de noviembre de 1993. Conjunto de pruebas NIST PCTS 151-1, versión 1.1.

QNX Neutrino (versión 6.3) cumple (cumple a) Siguientes Normas de la Familia POSIX (www.qnx.com/download/download/8660/portability.pdf):

POSIX.1 (IEEE 1003.1);
POSIX.1A (IEEE 1003.1A);
Posix.2 (IEEE 1003.2);
Posix.4 (IEEE 1003.1B);
Posix.4a (IEEE 1003.1c);
POSIX.1B (IEEE 1003.1D), IEEE 1003.1J;
Posix.12 (IEEE 1003.1G).

Literatura

Manual de operación de la Asociación de Estándares de IEEE. IEEE, octubre de 2004.
Kevin M. Oonseland. POSIX en tiempo real, programación de sistemas incorporados, 2001.
Estándar IEEE / ANSI 1003.1: Tecnología de la información - (POSIX) - Part1: Aplicación del sistema: Interfaz de programa (API).
Gallmeister, B. O. Programación para el mundo real, POSIX.4. Sebastopol, CA: O'Reilly & Associates, 1995.
Instituto Nacional de Normas y Tecnología, PCT: 151-2, POSIX Test Suite.
POSIX: Certificado por IEEE y el grupo abierto. Política certificada. El grupo abierto, 21 de octubre de 2003, revisión 1.1.

Normalización de los sistemas operativos y POSIX UNIX. Estándares de sistemas operativos en tiempo real.

Sobre las normas en general

Nombramiento y "Superbate" de la POSIX estándar

Sobre semántica

Cumplimiento de la norma. La semántica de la palabra "corresponde".

Objetos de estandarización y estructura estándar.

Conclusión

Sobre autentico

Literatura

Las ideas principales de la POSIX estándar.

¿Qué es POSIX?

POSIX y OS RV: intento de sistematización

Como introducción: ¿Por qué necesita una estandarización de la interfaz de programación?

Quién es quien en el desarrollo de POSIX.

¿Qué es POSIX?

Historial de desarrollo estándar POSIX

Los estándares más importantes de POSIX para RV OS

Procedimiento de certificación

Un poco de confusión en la terminología.

OS RV certificado.

Sistema operativo POSIX y QNX

Recuperación de contraseña