ES2315469T3 - Sistemas operativos. - Google Patents
Sistemas operativos. Download PDFInfo
- Publication number
- ES2315469T3 ES2315469T3 ES03290894T ES03290894T ES2315469T3 ES 2315469 T3 ES2315469 T3 ES 2315469T3 ES 03290894 T ES03290894 T ES 03290894T ES 03290894 T ES03290894 T ES 03290894T ES 2315469 T3 ES2315469 T3 ES 2315469T3
- Authority
- ES
- Spain
- Prior art keywords
- operating system
- operating
- systems
- operating systems
- computer
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/4555—Para-virtualisation, i.e. guest operating system has to be modified
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
- H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- Medical Informatics (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Computing Systems (AREA)
- Stored Programmes (AREA)
- Debugging And Monitoring (AREA)
- Hardware Redundancy (AREA)
- Vehicle Body Suspensions (AREA)
- Massaging Devices (AREA)
- Eye Examination Apparatus (AREA)
Abstract
Un procedimiento para habilitar múltiples sistemas operativos diferentes para que se ejecuten de manera concurrente en el mismo ordenador (100), comprendiendo el procedimiento: seleccionar un primer sistema operativo (201) para que tenga una prioridad alta; seleccionar al menos un segundo sistema operativo (202) para que tenga una prioridad más baja que la prioridad del primer sistema operativo (201); proporcionar un programa común (400) configurado para conmutar entre y para controlar los mencionados primera y segundo sistemas operativos, caracterizado porque el programa común (400) está organizado para pasar interrupciones concebidas para el primer y para el segundo sistemas operativos al primer sistema operativo (201), y porque el primer sistema operativo (201) está organizado para procesar las interrupciones destinadas para el primer sistema operativo (201), y para pasar las interrupciones concebidas para el segundo sistema operativo (202) de nuevo al programa común (400) para su reenvío al segundo sistema operativo (202).
Description
Sistemas operativos.
Esta invención se refiere a sistemas operativos.
De manera más particular, esta invención se refiere a sistemas,
procedimientos y programas de ordenador para la ejecución de
múltiples sistemas operativos de manera concurrente.
Para algunos programas de ordenador, es crítico
que las etapas del programa sean realizadas dentro de períodos de
tiempo definidos, o en instantes de tiempo definidos. Ejemplos de
dichos programas son los programas de control para hacer funcionar
teléfonos móviles, o para hacer funcionar centralitas telefónicas
privadas (PBX) o estaciones base celulares. De manera típica, el
programa debe responder a eventos externos o a cambios de estado de
una manera consistente, en o dentro de un cierto tiempo después de
la ocurrencia del evento. Se hace referencia a esto como
funcionamiento en "tiempo real".
Para muchos otros programas, sin embargo, el
tiempo que se tarda en ejecutar el programa no es crítico. Esto se
aplica a los programas de ordenador más comunes, incluyendo los
programas de hojas de cálculo, programas de procesado de texto,
paquetes de pago de nóminas, y programas de informes generales o de
análisis. Por otra parte, mientras que el tiempo exacto que se
tarda por parte de estos programas no es crítico, en la mayoría de
los casos, los usuarios preferirían una ejecución más rápida cuando
ésta fuera posible.
Los programas de aplicaciones interactúan con
los ordenadores sobre los que se ejecutan a través de sistemas
operativos. Por medio de la utilización de la interfaz de
programación de aplicaciones (API) del sistema operativo, el
programa de aplicaciones se puede escribir de una manera portátil,
de forma que se pueda ejecutar en diferentes ordenadores con
diferentes recursos hardware. De manera adicional, los sistemas
operativos comunes tales como Linux o Windows proporcionan
multitarea; en otras palabras, permiten que varios programas estén
funcionando de una manera concurrente. Para hacer esto,
proporcionan programación; en otras palabras, comparten el uso de
los recursos del ordenador entre los diferentes programas, asignando
tiempo a cada uno de ellos de acuerdo con un algoritmo de
programación. Los sistemas operativos de esta clase son ampliamente
usados, pero por lo general no hacen provisión para la ejecución de
aplicaciones en tiempo real, y por lo tanto son inadecuados para
muchas tareas de control o tareas de comunicaciones.
Para dichas tareas, por lo tanto, se han
desarrollado los sistemas operativos en tiempo real; un ejemplo es
ChorusOS (también conocido como Chorus) y sus derivados. Chorus se
encuentra disponible como software de fuente abierta en: Sun
Microsystems en el sitio web
\underbar{http://www.experimentalstuff.com/\_Technologies/\_ChorusOS/index.html}
y Jaluna en el sitio web \underbar{http://www.jaluna.com/}.
Se describe en "ChorusOS Features and
Architecture overview", de Francois Armand, Sun Technical
Report, de agosto de 2001, 222 páginas, disponible en el sitio web:
http://www.jaluna.com/developer/papers/COSDESPERF.pdf.
Estos sistemas operativos se podrían usar
también para la ejecución de otros tipos de programas. Sin embargo,
los usuarios de manera comprensible desean poder ejecutar el vasto
número de programas "legados" que están escritos para sistemas
operativos de propósito general tales como Windows o como Linux, sin
tener que reescribirlos para ejecutarlos sobre un sistema operativo
en tiempo real.
En el documento de los Estados Unidos número
5903752 y en el documento de los Estados Unidos número 5721922, se
hace un intento para incorporar un entorno en tiempo real dentro de
un sistema operativo que no es en tiempo real por medio de
proporcionar un núcleo multitarea en tiempo real en el entorno de
gestión de interrupciones del sistema operativo en tiempo no real
(tal como Windows).
Debería ser posible proporcionar un sistema de
"doble arranque", que permita al usuario ejecutar un sistema
operativo o el otro, pero existen muchos casos en los que sería
deseable poder ejecutar un programa "legado" en el mismo
tiempo en el que se ejecuta un programa en tiempo real. Por ejemplo,
el equipo de infraestructura de red de telecomunicaciones, los
teléfonos móviles de tercera generación y otros teléfonos avanzados,
y el equipo de juegos electrónicos avanzado pueden requerir tanto
aplicaciones en tiempo real (por ejemplo, juego que ejecute
gráficos) y aplicaciones que no sean en tiempo real (descarga de
juegos).
Una aproximación que se ha usado de manera
amplia es la "emulación". De manera típica, un programa
emulador está escrito para ejecutarse bajo el sistema operativo en
tiempo real, que interpreta cada una de las instrucciones de un
programa escrito para un sistema operativo de propósito general, y
realiza una serie correspondiente de instrucciones bajo el sistema
operativo en tiempo real.
Sin embargo, como una instrucción siempre es
sustituida por muchas, la emulación coloca una carga más pesada en
el ordenador, y da como resultado un rendimiento más lento.
Problemas similares surgen de la aproximación basada en
proporcionar una máquina virtual (por ejemplo, una máquina virtual
Java^{TM}).
En el documento de los Estados Unidos 5995745
(de Yodaiken) se describe una técnica adicional similar. Yodaiken
describe un sistema en el que un sistema operativo en tiempo real
multitarea ejecuta un sistema operativo de propósito general como
una de sus tareas, dándole una preferencia lo necesario para
realizar las tareas en tiempo real.
Una aproximación más similar es la de ADEOS
(Entorno de Dominio Adaptativo para Sistemas Operativos), descrita
en un Papel en Blanco en el sitio web
\underbar{http://opersys.com/ftp/pub/Adeos/\_adeos.pdf}.
ADEOS proporciona un nanonúcleo que está
destinado, entre otras cosas, para la ejecución de múltiples
sistemas operativos aunque aparece solamente que ha sido
implementado con Linux. Un uso propuesto de ADEOS fue permitir
ADEOS para distribuir las interrupciones para RTAI (Interfaz de
Aplicación en Tiempo Real para Linux) para lo cual, véase el sitio
web: http://www.aero.polimi.it/\simrtai/applications/.
El documento
EP-A-1162536 y el documento
EP-A-1054322 describen múltiples
procedimientos de control de sistema operativo pertenecientes a las
características del preámbulo de las reivindicaciones
independientes.
Un objeto de la presente invención es
proporcionar un sistema, un procedimiento y un programa de ordenador
mejorados para ejecutar múltiples sistemas operativos de manera
simultánea, incluso cuando los sistemas estén diseñados para
propósitos diferentes. En particular, la presente invención busca
permitir a uno de los sistemas operativos (por ejemplo, un sistema
operativo en tiempo real) ejecutarse sin interferencias, y al otro
(por ejemplo, un sistema operativo de propósito general) ejecutarse
así como la posible utilización de los recursos restantes del
ordenador.
De acuerdo con esto, en un aspecto, la presente
invención proporciona un procedimiento de acuerdo con la
reivindicación 1. En otro aspecto, la presente invención
proporciona un sistema de acuerdo con la reivindicación 14 o con la
reivindicación 15. En otro aspecto, la presente invención
proporciona un producto de programa de acuerdo con la reivindicación
12.
A diferencia de la configuración de ADEOS, la
presente invención favorece a uno de los sistemas operativos (el
sistema operativo "primario" o "crítico") sobre el otro
(el sistema operativo "secundario" o no crítico); da al
sistema operativo crítico un tratamiento preferencial, asigna
hardware de manera preferencial al mismo, y deniega al sistema o a
los sistemas operativos secundarios el acceso que pudiese interferir
con el del sistema operativo crítico. De manera preferible, la
presente invención usa uses los controladores del sistema operativo
crítico para acceder a los recursos compartidos, incluso si el
acceso es solicitado por el sistema operativo secundario. Sin
embargo, en ningún sentido está el sistema operativo crítico
"ejecutando" el sistema operativo secundario, como en el
documento de los Estados Unidos 5995745; cada uno de los sistemas
ignora a los otros que se están ejecutando conjuntamente al mismo y
solamente comunica con un programa común operativo como despachador
de recursos hardware (correspondiente a un nanonúcleo de la técnica
anterior) que rompe el acceso a los controladores del sistema
operativo crítico.
Otros aspectos, realizaciones y características
preferidas, con las ventajas correspondientes, serán más aparentes
a partir de la descripción, de las reivindicaciones y de los dibujos
siguientes.
Las realizaciones de la invención se describirán
ahora, a modo de ejemplo solamente, con referencia a los dibujos
que se acompañan, en los que:
La figura 1 es un diagrama de bloques que
muestra los elementos de un sistema de ordenador sobre el que se
puede ejecutar la presente invención;
La figura 2a es un diagrama que ilustra la
organización de software de la técnica anterior; y
La figura 2b es el diagrama correspondiente que
ilustra la organización del software de acuerdo con la presente
invención;
La figura 3 es un diagrama de flujo que muestra
las etapas en la creación del software de la figura 2b para el
ordenador de la figura 1;
La figura 4 muestra los componentes de un
despachador de recursos hardware que forma parte de la figura
2b;
La figura 5 ilustra el programa usado en una
secuencia de arranque e inicialización;
La figura 6 ilustra la imagen de memoria del
sistema usada en el proceso de arranque o de inicialización;
La figura 7 ilustra la transición desde un
sistema operativo primario a un sistema operativo secundario;
La figura 8 ilustra la transición desde un
sistema operativo secundario a un sistema operativo primario;
La figura 9a ilustra la comunicación entre
aplicaciones que se ejecutan sobre sistemas operativos diferentes
de acuerdo con la invención; y
La figura 9b ilustra la comunicación entre
aplicaciones que se ejecutan sobre sistemas operativos diferentes
sobre ordenadores diferentes de acuerdo con la invención;
Un sistema de ordenador 100 al que es aplicable
el sistema comprende una unidad central de proceso (CPU) 102, tal
como una CPU Pentium 4^{TM} disponible de la marca Intel
Corporation, o una CPU PowerPC disponible de la marca Motorola (la
realización se ha llevado a la práctica sobre ambas CPU), acoplada a
través de un bus del sistema 104 (que comprende los buses de
control, de datos y de direcciones) a un circuito integrado de
memoria de sólo lectura (ROM) 106; uno o más bancos de circuitos
integrados de memoria de acceso aleatorio (RAM) (108); dispositivos
controladores de disco 110 (por ejemplo, controladores IDE o SCSI,
conectados a una unidad de disco flexible, una unidad de disco
duro, y unidades de medios extraíbles adicionales tales como
unidades de DVD); uno o más puertos de entrada/salida (112) (por
ejemplo, uno o más controladores de puertos USB, y/o controladores
de puerto paralelo para la conexión a impresora, etc.); un bus de
expansión 114 para la conexión por bus a dispositivos periféricos
externos o internos (por ejemplo, el bus PCI); y otros circuitos
integrados del sistema 116 (por ejemplo, dispositivos de gráficos y
de sonido). Ejemplos de ordenadores de este tipo son los
ordenadores personales (PC) y las estaciones de trabajo. Sin
embargo, también se describe en este documento la aplicación de la
invención a otros dispositivos de ordenador tales como
macroordenadores, microordenadores incorporados en sistemas de
control y PDA (en cuyo caso alguno de los dispositivos indicados
tales como los controladores de unidad de disco pueden estar
ausentes).
Con referencia a la figura 2a, en utilización,
el ordenador 100 de la figura 1 ejecuta programas residentes que
comprenden el núcleo del sistema operativo 202 (que proporciona las
rutinas de salida que permiten el acceso a la CPU a los otros
dispositivos mostrados en la figura 1); una interfaz de usuario del
sistema operativo o capa de presentación 204 (tal como X Windows);
una capa de software intermedio (middleware) 206 (que
proporciona software de funcionamiento en red y protocolos tales
como por ejemplo, una pila TCP/IP) y aplicaciones 208a, 208b, que
se ejecutan haciendo llamadas a las rutinas API que forman el núcleo
del sistema operativo 202.
El núcleo del sistema operativo tiene un número
de tareas, en particular:
- \sqbullet
- programación (es decir, la compartición de la CPU y de los recursos asociados entre las diferentes aplicaciones que se están ejecutando);
- \sqbullet
- gestión de la memoria (es decir, la asignación de memoria a cada una de las tareas, y, cuando sea necesario, la permuta de datos y programas fuera de la memoria añadidos a las unidades de disco);
- \sqbullet
- proporcionar un sistema de ficheros;
- \sqbullet
- proporcionar el acceso a dispositivos (de manera típica, a través de controladores);
- \sqbullet
- gestión de interrupciones;
- \sqbullet
- proporcionar una interfaz de programación de aplicaciones que haga posible que las aplicaciones interactúen con los recursos del sistema y con los usuarios.
\vskip1.000000\baselineskip
El núcleo puede ser un denominado "núcleo
monolítico" como para Unix, en cuyo caso los controladores del
dispositivo forman parte del mismo núcleo. De manera alternativa,
puede ser un "micronúcleo" como para Chorus, en cuyo caso los
controladores del dispositivo están separados del núcleo.
En uso, entonces, cuando se inicie el ordenador
100, un programa de rutina de arranque almacenado en la ROM 106
accede a los controladores de disco 110 para leer el fichero que
gestiona parte del sistema operativo desde el almacenamiento
permanente en disco dentro de la RAM 108, después carga el resto del
sistema operativo dentro de un área de RAM 108. El sistema
operativo lee después cualquiera de las aplicaciones desde las
unidades de disco a través de los controladores de disco 110,
asigna espacio en la RAM 108 para cada una de ellas y almacena cada
una de las aplicaciones en su espacio de memoria asignado.
Durante el funcionamiento de las aplicaciones,
la parte de programador del sistema operativo divide el uso de la
CPU entre las diferentes aplicaciones, permitiendo a cada una de
ellas una compartición del tiempo en el procesador de acuerdo con
una política de programación. También gestiona el uso de los
recursos de memoria, por medio de la "permutación" de
aplicaciones o de datos usados de manera infrecuente (es decir,
eliminándolos de la RAM 108 para liberar espacio y para
almacenarlos en disco).
Finalmente, las rutinas que conforman la
interfaz de programación de aplicaciones (API) son llamadas desde
las aplicaciones, para ejecutar funciones tales como la entrada y la
salida, y las rutinas de gestión de interrupciones del sistema
operativo responden a las interrupciones y a los eventos.
En la realización preferida, cada sistema
operativo 201, 202 para ser usado en el ordenador 100 es ligeramente
reescrito, y se crea un nuevo programa de bajo nivel 400
(denominado aquí el "despachador de recursos hardware", y a
menudo conocido como un "nanonúcleo" aunque no es el núcleo de
un sistema operativo). El despachador de recursos hardware 400 es
específico para el tipo particular de CPU 102, ya que interactúa con
el procesador. Las versiones de los sistemas operativos que son
modificados 201, 202 son también aquéllas que son específicas para
el hardware, por razones que serán obvias.
El despachador de recursos hardware 400 no es de
por sí un sistema operativo. No interactúa con los programas de
aplicaciones para nada, y tiene una funcionalidad muy limitada. Ni
es una máquina virtual o un emulador; requiere que los sistemas
operativos sean modificados con el fin de cooperar, incluso aunque
deje la mayoría del procesado a los sistemas operativos mismos,
ejecutando su código nativo en el procesador. Realiza las
siguientes funciones básicas:
- \sqbullet
- cargar e iniciar cada uno de los múltiples sistemas operativos;
- \sqbullet
- asignar memoria y otros recursos del sistema a cada uno de los sistemas operativos;
- \sqbullet
- programar el funcionamiento de los diferentes sistemas operativos (es decir, dividir el tiempo de CPU entre ellos, y gestionar el cambio entre ellos);
- \sqbullet
- proporcionar un procedimiento de "dispositivo virtualizado" de acceso indirecto a aquellos dispositivos de sistema que necesiten ser compartidos por los sistemas operativos ("virtualizar" los dispositivos);
- \sqbullet
- proporcionar un enlace de comunicaciones entre los sistemas operativos, para permitir que las aplicaciones se ejecuten sobre sistemas operativos diferentes para comunicar unos con otros.
\vskip1.000000\baselineskip
Los sistemas operativos no son tratados
igualmente por la realización. En lugar de esto, uno de los sistemas
operativos se selecciona como el sistema operativo "crítico"
(éste será el sistema operativo en tiempo real), y el sistema o
cada uno de los otros sistemas operativos serán tratados como
sistemas operativos "no críticos" o "secundarios" (éste
será el sistema o cada uno de los sistemas operativos de propósito
general tal como Linux).
Cuando está designado el despachador de recursos
hardware, se proporciona con una estructura de datos (por ejemplo,
una tabla) que lista los recursos disponibles del sistema (es decir,
los dispositivos y la memoria), para hacer posible que tantos
dispositivos de sistema como sea posible sean estáticamente
asignados de manera exclusiva a uno o a otro de los sistemas
operativos.
Por ejemplo, a un puerto de impresora paralelo
podría estar asignado de manera estática al sistema operativo de
propósito general 202, que a menudo ejecutará aplicaciones que
necesitarán producir la salida por impresora. Por otra parte, un
puerto adaptador de línea digital RDSI puede estar asignado de
manera permanente al sistema operativo en tiempo real 201 para las
comunicaciones. Esta asignación estática de dispositivos siempre que
sea posible significa que cada uno de los sistemas operativos puede
usar sus controladores existentes para acceder a los dispositivos
asignados de manera estática sin necesidad de hacer una llamada al
despachador de recursos hardware. De esta manera, no existe una
pérdida en la velocidad de ejecución en el acceso a dichos
dispositivos (como sería si actuara como una máquina virtual o un
emulador).
En el caso de dispositivos de sistema que deban
ser compartidos, el despachador de recursos del sistema hace una
virtualización de los usos de los dispositivos por parte de los
sistemas operativos no críticos, y hace uso de los controladores
suministrados con el sistema operativo crítico para realizar el
acceso. Igualmente, para la gestión de interrupciones, el
despachador de recursos hardware pasa las interrupciones a las
rutinas de gestión de interrupciones del sistema operativo crítico,
que se ocupan de la interrupción (si estaba destinada para el
sistema operativo crítico) o la devuelven a través del despachador
de recursos hardware para reenviarla a un sistema operativo no
crítico (si era a donde estaba destinada).
En el arranque, el despachador de recursos
hardware se carga primero, y después carga cada uno de los sistemas
operativos en una secuencia predeterminada, comenzando con el
sistema operativo crítico, después siguiendo con el sistema
operativo o con cada uno de los otros sistemas operativos
secundarios uno a uno. Al sistema operativo crítico se le asignan
los recursos que requiera de la tabla, y tiene un espacio en memoria
fijo en el que operar. Después, a cada uno de los sistemas
operativos secundarios uno a uno se les asigna los recursos y el
espacio en memoria que requiere de los restantes recursos
disponibles.
De esta manera, de acuerdo con la realización,
los recursos usados por los sistemas operativos están separados
tanto como sea físicamente posible, por medio de la asignación a
cada uno de ellos de su propio espacio en memoria, y por medio de
proporcionar una asignación estática de dispositivos exclusivamente
para los sistemas operativos; solamente los dispositivos para los
que sea esencial la compartición serán compartidos.
\newpage
En funcionamiento, el programador del
despachador de recursos hardware permite al sistema operativo
crítico funcionar hasta que haya concluido sus tareas, y después
devuelve el control a cada uno de los sistemas operativos no
críticos uno a uno, hasta que ocurra la siguiente interrupción o el
siguiente evento.
La realización permite de esta manera un entorno
de multisistema operativo en el que el funcionamiento del sistema
operativo crítico es virtualmente no cambiado (ya que usa sus
controladores originales, y tiene un primer acceso a cualquier
gestión de interrupción o gestión de evento). Los sistemas
operativos secundarios son capaces de funcionar de manera
eficiente, dentro del tiempo de procesador restante, ya que en la
mayoría de los casos estarán usando sus propios controladores
nativos, y tendrán acceso exclusivo a muchos de los dispositivos
del sistema. Finalmente, el propio despachador de recursos hardware
puede ser un pequeño programa, ya que solamente gestiona funciones
limitadas, de forma que se conservan los recursos del sistema.
La realización preferida también es económica de
crear y de mantener, porque implica solamente cambios limitados
para los sistemas operativos comerciales estándar que ya habrán sido
adaptados al ordenador en particular 100. Además, como los cambios
en los sistemas operativos están confinados a cuestiones de gestión
de ficheros específicos de arquitectura tales como la gestión de
interrupciones y el tiempo de configuración y de inicialización,
que hacen de interfaz con el tipo particular de ordenador 100, y que
es improbable que cambien tan frecuentemente que el resto los
sistemas operativos, puede que haya un poco de trabajo o nada de
trabajo que hacer en la adaptación de las nuevas versiones del
mismo sistema operativo para que funcione de una manera de sistema
operativo múltiple.
\vskip1.000000\baselineskip
En esta realización, el ordenador 100 era un
procesador de la familia Intel 386 (por ejemplo, un procesador
Pentium) y un ordenador Motorola PowerPC 750 (Ordenador de Conjunto
Reducido de Instrucciones o "RISC") (paso 302). El sistema
operativo crítico 201 era el sistema operativo C5 (paso 304) (el
micronúcleo en tiempo real de Jaluna-1, una versión
de fuente abierta de la quinta generación del sistema ChorusOS,
disponible para fuente abierta, de descarga libre en el sitio web
http://www.jaluna.com).
En el paso 306, el núcleo del sistema operativo
ChorusOS 201 es modificado para el funcionamiento en modo de
sistema operativo múltiple, que es tratado de la misma manera que
portar a una nueva plataforma (es decir, escribir un nuevo Paquete
de Soporte de Placa para permitir la ejecución sobre un nuevo
ordenador con la misma CPU pero con dispositivos de sistema
diferentes). Las secuencias de arranque y las secuencias de
inicialización son modificadas para permitir al sistema operativo
en tiempo real ser iniciado por el despachador de recursos
hardware, en su espacio de memoria asignado, en lugar de iniciarse
por sí solo. La etapa de sondeo de hardware de la secuencia de
inicialización se modifica para evitar que el sistema operativo
crítico acceda a los recursos hardware que están asignados a otros
sistemas secundarios. Lee la tabla de asignación hardware estática
del despachador de recursos hardware para detectar los dispositivos
que le están disponibles.
Las llamadas de interrupción son añadidas al
sistema operativo crítico para detectar los estados y para solicitar
algunas acciones como respuesta. Por ejemplo, cuando el sistema
operativo en tiempo real 201 alcance un punto final (y cese en
requerir recursos del procesador) el control se puede devolver al
despachador de recursos hardware, emitiendo la interrupción
"desocupado", para iniciar el sistema operativo secundario.
Algunos controladores del paquete de soporte de
placa están espacialmente adaptados para ayudar al despachador de
recursos hardware en la virtualización de los dispositivos
compartidos para los sistemas operativos secundarios.
Controladores "virtuales" adicionales son
añadidos, al sistema operativo, que aparecen para proporcionar
acceso a un bus de entrada/salida (E/S), permitiendo que los datos
sean escritos en el bus. De hecho, el controlador virtual de bus
usa memoria como un medio de comunicaciones; exporta alguna memoria
privada (para los datos de entrada) e importa la memoria exportada
por otros sistemas (para los datos de salida). De esta manera, el
sistema operativo 201 (o una aplicación que se esté ejecutando en el
sistema operativo) puede pasar datos a otro sistema operativo (o a
otra aplicación que se esté ejecutando en él) como si fuesen dos
sistemas operativos ejecutándose en máquinas separadas conectadas
por un bus de E/S real.
El sistema operativo secundario 202 se
seleccionó (paso 308) como Linux, teniendo una versión del núcleo
2.4.18.
En el paso 310, el núcleo del sistema operativo
secundario 202 está modificado para permitir que funcione en un
entorno de sistema operativo múltiple, que es tratado como una nueva
arquitectura hardware. Como en el paso 306, las secuencias de
arranque y de inicialización están modificadas para permitir que el
sistema operativo secundario sea iniciado por el despachador de
recursos hardware, y para evitar que acceda a los recursos hardware
asignados a los otros sistemas, como se especifica en la tabla de
despachador de recursos hardware. Como en el paso 306, se añaden
las llamadas a interrupción, para pasar el control al despachador de
recursos hardware.
Los controladores nativos para los dispositivos
de sistema compartidos son sustituidos por nuevos controladores que
traten con los dispositivos que han sido virtualizados por el
despachador de recursos hardware (controlador de interrupciones,
puentes de bus de E/S, el temporizador del sistema y el reloj de
tiempo real). Estos controladores ejecutan una llamada a gestores
de dispositivo virtual 416 del despachador de recursos hardware con
el fin de realizar algunas operaciones sobre un dispositivo
respectivo del ordenador 100. cada uno de tales gestores de
dispositivo virtual 416 del despachador de recursos hardware está
emparejado con una rutina de controlador "par" en el sistema
operativo crítico, que está configurado para interactuar
directamente con el dispositivo del sistema. De esta manera, una
llamada a un gestor de dispositivo virtual es reenviada a un
controlador par en el sistema operativo crítico para ese
dispositivo virtualizado, con el fin de hacer un acceso real al
dispositivo. Como en el paso 306, se proporcionan los controladores
de lectura y de escritura para el bus de E/S virtual para permitir
comunicaciones entre sistemas operativos.
Las rutinas de servicio de interrupciones del
sistema operativo secundario están modificadas para proporcionar
rutinas de servicio de interrupciones virtuales cada una de las
cuales responde a una interrupción virtual respectiva (en forma de
una llamada emitida por una rutina de gestor de interrupciones 412
del despachador de recursos hardware), y no responder a
interrupciones o eventos reales. De esa manera, se evita que los
sistemas operativos secundarios
202, ... enmascaren las interrupciones hardware y por lo tanto tengan preferencia por el sistema operativo crítico 201; en otras palabras, la respuesta del sistema operativo secundario a una interrupción virtual puede ser interrumpida por el propio sistema operativo secundario por una interrupción real para el sistema operativo crítico 201. Esto incluye de manera típica:
202, ... enmascaren las interrupciones hardware y por lo tanto tengan preferencia por el sistema operativo crítico 201; en otras palabras, la respuesta del sistema operativo secundario a una interrupción virtual puede ser interrumpida por el propio sistema operativo secundario por una interrupción real para el sistema operativo crítico 201. Esto incluye de manera típica:
- \sqbullet
- enmascarar/desenmascarar eventos (interrupciones a nivel de procesador);
- \sqbullet
- salvar/restaurar estado de máscara de eventos;
- \sqbullet
- identificar la fuente de la interrupción (dispositivos controladores de interrupciones);
- \sqbullet
- enmascarar/desenmascarar interrupciones a nivel de fuente (dispositivos controladores de interrupciones).
\vskip1.000000\baselineskip
Se añaden nuevos controladores de dispositivo
virtual para acceder a los dispositivos hardware compartidos (los
puentes del bus de E/S, la consola del sistema, el temporizador del
sistema y el reloj en tiempo real). Estos controladores ejecutan
una llamada a gestores de dispositivo virtuales 416 del despachador
de recursos hardware con el fin de escribir datos en, o leer datos
de, un dispositivo respectivo del ordenador 100.
Para efectuar esto, el núcleo de Linux 202 se
modifica en esta realización por medio de la adición de nuevos
subárboles de la arquitectura de despachador de recursos hardware
virtuales (nk-i386 y nk-ppc para las
variantes 1-386 y PowerPC) con un pequeño número de
ficheros modificados. Los ficheros sin cambios fueron reutilizados
en su formato existente. Los subárboles originales fueron retenidos,
pero no se usaron.
En el paso 312, se escribe el despachador de
recursos hardware 400. El despachador de recursos hardware comprende
código que proporciona rutinas para las siguientes funciones como
(como se muestra en la figura 4):
- \sqbullet
- arrancar e inicializarse a sí mismo (402);
- \sqbullet
- almacenar una tabla (404) que almacene una lista de recursos hardware (dispositivos tales como puertos) y una entrada de asignación que indica a qué sistema operativo está asignado de manera única cada uno de los recursos;
- \sqbullet
- arrancar e inicializar el sistema operativo crítico que completa las tablas de asignación del despachador de recursos hardware (404);
- \sqbullet
- arrancar e inicializar los sistemas operativos secundarios (406);
- \sqbullet
- conmutar entre sistemas operativos (408);
- \sqbullet
- programar entre sistemas operativos (410);
- \sqbullet
- manejar las interrupciones (usando las rutinas de servicio de interrupciones del sistema operativo en tiempo real, y suministrar datos donde fuere necesario a las rutinas de servicio de interrupciones virtual de los sistemas operativos secundarios) (412);
- \sqbullet
- manejar las llamadas a interrupciones provenientes de cada uno de los sistemas operativos (414);
- \sqbullet
- manejar el acceso a dispositivos compartidos desde los sistemas operativos secundarios (416);
- \sqbullet
- manejar las comunicaciones entre sistemas operativos sobre el bus de E/S virtual (418).
\vskip1.000000\baselineskip
En realizaciones adicionales (que se describen a
continuación), también se puede proporcionar una estructura de
depuración de sistema.
Con el fin de conmutar desde un sistema
operativo a otro, el conmutador de sistema operativo 408 está
configurado para ahorrar el "contexto" - los valores actuales
del conjunto de variables de estado, tales como los valores de
registro - del sistema operativo que se esté ejecutando en ese
momento; la restauración del contexto almacenado de otro sistema
operativo; y hacer una llamada a otro sistema operativo para
recomenzar la ejecución donde se dejó. En detalles, comprende:
- \bullet
- conmutar de manera explícita desde la ejecución actual a los siguientes sistemas operativos programados, cuando el actual pase a estar desocupado; y
- \bullet
- conmutar de manera implícita desde un sistema operativo secundario al sistema operativo crítico, cuando ocurra una interrupción hardware.
\vskip1.000000\baselineskip
Las conmutaciones pueden ocurrir al hacer una
llamada a una interrupción o con una interrupción real o virtual,
como se describe más adelante.
El programador 410 asigna a cada sistema
operativo algo del tiempo de procesado disponible, por medio de la
selección de a cuál sistema operativo secundario (si hay más de uno
presentes) se conmutará el siguiente, después de salir de otro
sistema operativo. En esta realización, cada uno se selecciona en
base a una programación de prioridad fija). Otras realizaciones que
permiten la especificación en base a compartición del tiempo, o el
porcentaje mínimo del tiempo de procesador garantizado, también
están contempladas en este documento. En cada uno de los casos, sin
embargo, el sistema operativo crítico tiene la prioridad solamente
cuando está en estado desocupado.
En realizaciones adicionales, el sistema
operativo crítico 201 puede informar de manera explícita al
programador 410 cuándo puede tener la prioridad, para permitir a
todos los sistemas operativos secundarios algún acceso a la CPU
para realizar tareas con una prioridad más alta entonces las tareas
aún se ejecutarán en el sistema crítico. De esta manera, en un
ejemplo, las rutinas de servicio de interrupción del sistema
operativo crítico no pueden ser priorizadas, de forma que el
sistema operativo crítico siempre puede responder a eventos externos
o a señales de temporización provenientes del reloj de tiempo real,
manteniendo el funcionamiento en tiempo real.
El despachador de recursos hardware está
configurado para proporcionar mecanismos para gestionar las
excepciones del procesador (por ejemplo, las interrupciones de CPU
o las interrupciones de coprocesador) de la siguiente manera:
- \bullet
- en primer lugar, interceptar las excepciones del procesador a través del sistema operativo crítico;
- \bullet
- en segundo lugar, fijar una excepción virtual correspondiente para uno o más sistemas operativos secundarios; almacenar esos datos y, cuando el programador llame la siguiente vez a ese sistema operativo secundario, llame a la correspondiente rutina de servicio de interrupción virtual en el sistema operativo secundario;
- \bullet
- en tercer lugar, enmascarar o desenmascarar cualquier excepción virtual pendiente proveniente de dentro de los sistemas operativos secundarios.
\vskip1.000000\baselineskip
Las excepciones virtualizadas se usan de manera
típica para dos propósitos diferentes:
- \bullet
- En primer lugar, para reenviar interrupciones de dispositivo hardware (que son entregadas como excepciones de procesador asíncronas) a sistemas operativos secundarios;
- \bullet
- En segundo lugar, para implementar las interrupciones cruzadas entre sistemas operativos - es decir, interrupciones generadas por un sistema para otras interrupciones (que son entregadas como excepciones asíncronas).
\vskip1.000000\baselineskip
El funcionamiento del gestor de llamada a
interrupciones será obvio a partir de la siguiente descripción. Es
el propósito primario permitir al programador y al conmutador
cambiar a otro sistema operativo cuando un primer sistema operativo
se detenga (y así no requiera de recursos de CPU). Un papel
adicional es hacer una llamada a los servicios de despachador de
recursos hardware tal como una consola del sistema para su uso en
la depuración como se trata en relación a realizaciones
posteriores.
Como se ha indicado con anterioridad, para cada
uno de los dispositivos compartidos (por ejemplo, el controlador de
interrupciones, los puentes de bus, el temporizador del sistema, el
reloj en tiempo real) cada uno de los sistemas operativos
proporciona un controlador de dispositivo, formando un conjunto de
controladores a nivel de pares para ese dispositivo. El sistema
operativo en tiempo real proporciona el controlador usado para
acceder realmente al dispositivo, y los otros proporcionan
controladores de dispositivo virtuales.
El gestor de dispositivos compartidos 416 del
despachador de recursos hardware proporciona una estructura de
datos almacenados para cada uno de los dispositivos, para el acceso
por parte de todos los controladores de dispositivo pares a ese
dispositivo. Cuando se vaya a acceder al dispositivo, o cuando se
haya accedido al dispositivo, los controladores de dispositivo
actualizan los datos almacenados en la estructura de datos
correspondiente con los detalles del acceso. Los controladores pares
usan interrupciones cruzadas (como se ha tratado con anterioridad)
para señalizar un evento para notificar a otros controladores pares
que acaba de actualizarse esa estructura de datos.
Los controladores que sean para acceder a los
dispositivos controladores de interrupciones usan los mecanismos de
excepción virtualizados tratados con anterioridad para gestionar las
interrupciones hardware de la siguiente manera:
- \bullet
- El controlador del dispositivo del sistema operativo crítico gestiona las interrupciones hardware y las reenvía como excepciones virtualizadas a los controladores pares secundarios;
- \bullet
- El sistema operativo secundario habilita e inhabilita las interrupciones por medio de la utilización de la excepción virtualizada enmascarando y desenmascarando las rutinas tratadas con anterioridad.
\vskip1.000000\baselineskip
Los buses de E/S y sus puentes solamente tienen
que ser compartidos si los dispositivos que se conectan a ellos no
están asignados todos al mismo sistema operativo. De esta manera, al
asignar dispositivos, hasta el grado que sea posible, los
dispositivos conectados al mismo bus de E/S se les asigna el mismo
sistema operativo. Cuando sea necesaria la compartición, la tabla
de asignación de recursos 404 almacena datos de descriptor que
indican la asignación de los recursos sobre el bus (espacios de
direcciones, líneas de interrupción y puertos de E/S) para indicar
qué sistema operativo tiene qué recursos.
Finalmente, en el paso 314, el código para el
despachador de recursos hardware y los sistemas operativos se
compila como un producto de programa de ordenador binario que puede
ser distribuido para su suministro con el ordenador 100.
Un producto que se puede suministrar de acuerdo
con un aspecto de la invención es un producto de entorno de
desarrollo, que comprende un programa de ordenador que hace posible
al usuario seleccionar diferentes sistemas operativos que se vayan
a usar, construir y seleccionar diferentes aplicaciones para cada
uno de los sistemas operativos, incorporar la aplicación y los
sistemas operativos en un producto para su entrega, y proporcionar
el arranque del sistema operativo y el lanzamiento de binarios
ejecutables de las aplicaciones. Esto se basa en y es similar al
entorno de desarrollo C5, disponible en el sitio web
www.jaluna.com.
En una realización preferida, se hace disponible
el código fuente para la invención a través de Internet, para su
acceso y uso libre y sin restricciones.
Con referencia a la figura 5, los procesos de
arranque y de inicialización de acuerdo con esta realización se
realizan de la siguiente manera.
Se ejecuta un programa de arranque
("trampolín") 4022 almacenado en la ROM 106 cuando se
suministra la alimentación por vez primera, lo que inicia un
programa 4024 que instala el resto del programa despachador de
recursos hardware 400 en memoria, y lo inicia, pasando como un
argumento una estructura de datos (como se describe a continuación)
que describe la configuración de la imagen del sistema.
El despachador de recursos hardware inicializa
una línea serie que se puede usar para una consola del sistema.
Después asigna espacio en memoria (un entorno de sistema operativo)
para cada sistema operativo uno a uno, comenzando con el sistema
operativo crítico. El despachador de recursos hardware por lo tanto
actúa como un cargador de arranque del núcleo del sistema de
segundo nivel.
Cada núcleo de sistema operativo pasa entonces a
través de su propia fase de inicialización, seleccionando los
recursos que sean exclusivos para ese sistema operativo dentro de
aquéllos que permanezcan en la tabla de asignación de recursos 404,
e iniciando sus servicios y aplicaciones iniciales.
\newpage
La figura 6 ilustra un ejemplo de una asignación
de dirección de memoria que forma la imagen del sistema. Se asigna
una posición dentro de la memoria cuando el despachador de recursos
hardware y los sistemas operativos se compilen. El conjunto de
estas posiciones en memoria define la imagen del sistema, que se
muestra en la figura 6. La imagen del sistema comprende un primer
banco de memoria 602 en el que está localizado el despachador de
recursos hardware; un segundo banco de memoria 604 en el que está
localizado el sistema operativo en tiempo real; un tercer banco de
memoria 606 en el que está localizado el sistema operativo
secundario; y, en esta realización, un cuarto banco de memoria 608
en el que está localizado el disco RAM que contiene un sistema de
ficheros raíz del sistema operativo secundario (Linux).
Esta imagen del sistema se almacena en un
almacenamiento permanente (por ejemplo, en una memoria de sólo
lectura para un dispositivo típico en tiempo real tal como un
teléfono móvil o PBX). Los restantes bancos de memoria se
encuentran disponibles para que sean asignados a cada uno de los
sistemas operativos según su entorno, dentro del que pueden cargar
y ejecutar aplicaciones.
Mientras está siendo arrancado, cada sistema
operativo asigna entonces un trozo de memoria complementario con el
fin de cumplir con el tamaño total requerido por su propia
configuración. Una vez asignado a un sistema operativo, los bancos
de memoria son gestionados usando el esquema de gestión de memoria
física del propio sistema operativo. Toda la demás memoria es
ignorada por el sistema operativo.
A cada sistema operativo se le asignan espacios
independientes de memoria virtual, para asegurarse de que los
sistemas operativos no pueden interferir unos con los otros o con el
despachador de recursos hardware. A los espacios de dirección de
usuario (es decir, los intervalos) y al espacio de dirección del
Supervisor (es decir, el intervalo) de cada uno de los sistemas
operativos se les asigna a cada uno de ellos un identificador de
contexto (ID) de unidad de gestión de memoria (MMU) diferente, que
permite la diferenciación de diferentes espacios de memoria virtual
que tengan direcciones que se solapen. Las ID de contexto de las MMU
son asignadas a cada sistema operativo en el instante de tiempo en
que se compila (paso 314 de la figura 3).
Esta solución evita la necesidad de nivelar
casos de traducción (TLB) cuando el despachador de recursos hardware
conmute entre diferentes sistemas operativos, lo que podría durar
un tiempo adicional. En lugar de esto, la conmutación entre
diferentes sistemas operativos se lleva a cabo almacenando las ID de
contexto de las MMU del sistema operativo que esté en ese momento
funcionando, y haciendo una rellamada a las ID de contexto de las
MMU almacenadas de los dos sistemas operativos conmutados.
Como se ha indicado con anterioridad, la tabla
de asignación de recursos 404 indica qué dispositivos son asignados
de manera única a cada sistema operativo. Además, la tabla 404
indica qué recursos de entrada/salida (dispositivos de Acceso
Directo a Memoria (DMA), puertos de entrada/salida, interrupciones,
etc.) están asignados de manera exclusiva a dichos dispositivos,
permitiendo de esta manera un uso directo de estos recursos sin
ningún conflicto. De manera típica, muchos dispositivos pueden
estar duplicados, así que es posible reducir los conflictos
potenciales de manera sustancial de esta manera.
La distribución se basa en el esquema de
configuración de sistema operativo (por ejemplo, en el caso de C5,
los dispositivos especificados en el árbol de dispositivos). Son
asignados a sistemas operativos en el instante de arranque, y con
el fin de arrancar, de forma que el sistema operativo crítico tenga
la primera elección de los dispositivos disponibles en la tabla 404
y los sistemas operativos secundarios a su vez reciban su
asignación en lo que quede. Cuando se inicializa cada uno de los
sistemas operativos, se detecta la presencia de estos dispositivos
y se usan sus controladores nativos para ellos sin interacción del
despachador de recursos hardware.
A continuación se describirán con mayor detalle
el funcionamiento de la realización tras la instalación y el
arranque.
Habiendo sido arrancado e inicializado, el
sistema operativo en tiempo real está ejecutando una o más
aplicaciones 207 (por ejemplo, una pila UDP/IP - UDP/IP significa
Protocolo de Datagramas Universal/Protocolo de Internet) y el
sistema operativo secundario está ejecutando varias aplicaciones
208a, 208b (por ejemplo, un procesador de texto y una hoja de
cálculo). El micronúcleo del sistema operativo en tiempo real 201 y
el núcleo del sistema operativo secundario 202 comunican con el
despachador de recursos hardware a través de la interfaz del
despachador de recursos hardware que comprende:
- \bullet
- una estructura de datos que representa el contexto del sistema operativo (es decir, el conjunto de variables de estado que necesitan ser salvadas y restauradas con el fin de conmutar al sistema operativo), y el depósito hardware;
- \bullet
- el conjunto de funciones que se ejecutan en el entorno del sistema operativo; y
- \bullet
- el conjunto de rutinas de llamada a interrupción que se ejecutan en el entorno del despachador de recursos hardware.
Si ningún sistema operativo requiere tiempo de
procesador (por ejemplo, ambos han alcanzado los estados de
"espera") entonces el despachador de recursos hardware 400
conmuta al proceso de desocupado del sistema operativo crítico, en
el que espera una interrupción o un evento. De esta forma, las
interrupciones se pueden procesar de manera inmediata por medio de
las rutinas de servicio del sistema operativo crítico, sin necesidad
de conmutar al primer sistema operativo crítico.
En algún punto, ocurrirá una interrupción o un
evento. Por ejemplo, se puede recibir un paquete en un puerto de
datos, provocando una interrupción para permitir que sea procesado
por el sistema operativo en tiempo real ejecutando la pila UDP/IP.
De manera alternativa, un usuario puede manipular un teclado o un
ratón, provocando una interrupción para hacer funcionar la GUI del
segundo sistema operativo 202 para la interacción con la aplicación
de procesado de texto 208. De manera alternativa, el reloj del
sistema puede indicar que ha transcurrido un tiempo predeterminado,
y que una aplicación debería comenzar la reejecución, o se debería
ejecutar una función de sistema operativo.
La rutina de servicio del sistema operativo
crítico da servicio entonces a la interrupción, como se describe a
continuación.
Si no se está ya en el sistema operativo
crítico, el gestor de interrupciones del despachador de recursos
hardware 412 hace una llamada al conmutador de sistema operativo 408
para conmutar al sistema operativo crítico, y después a la rutina
del gestor de interrupciones 412 para hacer una llamada a una rutina
de servicio de interrupción (ISR) en el sistema operativo crítico
201. Si la interrupción está destinada para el sistema operativo
crítico, o porque proviene de un dispositivo asignado de manera
única al sistema operativo crítico o porque proviene de un
dispositivo compartido y tiene un cierto valor predeterminado, la
ISR del sistema operativo crítico toma las acciones necesarias para
gestionar la interrupción. Si no, el control pasa de nuevo al
despachador de recursos hardware.
Con referencia a la figura 7, para este ejemplo,
el sistema está ejecutando un proceso 702 de una aplicación 207a
que se está ejecutando en el sistema operativo crítico 201.
Si ocurre una interrupción, una rutina de
servicio a la interrupción del sistema operativo crítico 704 realiza
el servicio a la interrupción. Al terminar, el control pasa de
nuevo al proceso 702 y a cualquier otro proceso que sea ejecutado
por el programador del sistema operativo crítico 201. Cuando se ha
completado el procesado de todos los procesos, el sistema operativo
crítico ha acabado la ejecución, programa su proceso
"desocupado". De acuerdo con esto, la rutina de interrupción
de "desocupado" en el sistema operativo crítico emite una
llamada de interrupción "desocupado" al despachador de
recursos hardware 400. El despachador de recursos hardware ejecuta
entonces una rutina que hace lo siguiente:
- \bullet
- Si el gestor de interrupciones 412 actualmente tiene alguna interrupción virtual almacenada, éstas son reenviadas por parte del gestor de interrupciones 412 al sistema operativo secundario.
- \bullet
- El programador del sistema operativo del despachador de recursos hardware 410 selecciona el sistema operativo secundario 202 para su ejecución. El conmutador del SO 408 salva entonces el contexto actual (de manera típica, la MMU del procesador y los registros de estado, los punteros de instrucción y de pila) en el área de almacenamiento del contexto del SO crítico 706. Entonces, recupera el contexto de ejecución almacenado 708 para el sistema operativo secundario 202, y los escribe en los registros de interés.
- \bullet
- si hay interrupciones virtuales para el sistema operativo secundario de interés, el gestor de interrupciones 412 hace una llamada a la rutina de servicio de interrupciones pertinente 710 dentro del sistema operativo secundario, que da servicio a la interrupción y después, al completarse, vuelve a la ejecución de un proceso 712 del sistema operativo secundario en donde se quedó.
Si el gestor de interrupciones 412 no tiene
interrupciones pendientes en el momento actual, entonces el
conmutador de sistema operativo de despachador de recursos hardware
408 provoca que el sistema operativo secundario recomience la
ejecución en donde se quedó, usando el valor de contador de programa
almacenado dentro del contexto de sistema operativo restaurado, en
este caso en el proceso 712.
De esta manera, después de que el sistema
operativo crítico 201 haya realizado alguna función (o dar servicio
a sus propias aplicaciones o servicios, o dar servicio a una
interrupción destinada a otro sistema operativo), el despachador de
recursos hardware pasa el control de vuelta al siguiente sistema
operativo secundario 202, según determine el programador 410.
Con referencia a la figura 8, se describirá
ahora el proceso de transferir desde el sistema operativo secundario
al sistema operativo crítico. En este caso, el sistema está
ejecutando un proceso 712 de una aplicación 208a que se está
ejecutando en el sistema operativo crítico 202.
Cuando ocurre una interrupción hardware, el
despachador de recursos hardware inicia el conmutador de SO, para
salvar el contexto del sistema operativo secundario en el área de
almacenamiento de contextos 708. Después conmuta al sistema
operativo primario 201, restableciendo los valores de las variables
de estado provenientes del área de almacenamiento de contextos 706,
y hace una llamada a la rutina de servicio de interrupción 704 del
sistema operativo primario 201. Después de dar servicio a la
interrupción, el programador del sistema operativo primario 201
puede pasar el control de vuelta desde la ISR 704 a cualquier
proceso 704 que se estuviese ejecutando con anterioridad (o proceso
que se vaya a ejecutar).
Cuando la ISR y todos los procesos están
procesados, el sistema operativo primario 201 pasa el control de
vuelta al despachador de recursos hardware, que conmuta desde el
sistema operativo primario 201 (salvando las variables de estado en
el almacenamiento de contextos 706) y conmuta a un sistema operativo
secundario seleccionado 201 (recuperando las variables de estado
del almacenamiento de contextos 708), de la manera que se trata con
referencia a la figura 7 dada en lo anterior.
Será obvio a partir de lo anterior que las
realizaciones descritas en lo antecedente son solamente ejemplos, y
que son posibles muchas otras realizaciones. Los sistemas
operativos, las plataformas y las técnicas de programación
mencionadas pueden todos ellos ser variados libremente. Cualquier
otra modificación, sustitución y variante que serán obvias para una
persona experta se considerarán como que están dentro del ámbito de
la invención. Para evitar dudas, se busca la protección para
cualquiera y para cada una de las cuestiones objetivo novedosas y
para las combinaciones de las mismas descritas en este
documento.
Claims (15)
-
\global\parskip0.930000\baselineskip
1. Un procedimiento para habilitar múltiples sistemas operativos diferentes para que se ejecuten de manera concurrente en el mismo ordenador (100), comprendiendo el procedimiento:- seleccionar un primer sistema operativo (201) para que tenga una prioridad alta;
- seleccionar al menos un segundo sistema operativo (202) para que tenga una prioridad más baja que la prioridad del primer sistema operativo (201);
- proporcionar un programa común (400) configurado para conmutar entre y para controlar los mencionados primera y segundo sistemas operativos,
caracterizado porque el programa común (400) está organizado para pasar interrupciones concebidas para el primer y para el segundo sistemas operativos al primer sistema operativo (201),y porque el primer sistema operativo (201) está organizado para procesar las interrupciones destinadas para el primer sistema operativo (201), y para pasar las interrupciones concebidas para el segundo sistema operativo (202) de nuevo al programa común (400) para su reenvío al segundo sistema operativo (202). - 2. El procedimiento de la reivindicación 1, en el que el primer sistema operativo (201) es un sistema operativo en tiempo real.
- 3. El procedimiento de la reivindicación 1, en el que el segundo sistema operativo (202) es un sistema operativo de propósito general no en tiempo real.
- 4. El procedimiento de la reivindicación 1, en el que el programa común (400) está organizado para salvar y para restaurar a partir de una versión salvada, el estado del procesador requerido para conmutar entre los sistemas operativos.
- 5. El procedimiento de la reivindicación 1, comprendiendo de manera adicional el proporcionar a cada uno de los mencionados sistemas operativos espacios de memoria separados en los que cada uno de ellos pueda funcionar de manera exclusiva.
- 6. El procedimiento de la reivindicación 1, comprendiendo de manera adicional el proporcionar a cada uno de los mencionados sistemas operativos unos primeros dispositivos de entrada y/o salida del mencionado ordenador (100) al cual cada uno de ellos tiene un acceso exclusivo.
- 7. El procedimiento de la reivindicación 1, comprendiendo de manera adicional el proporcionar a cada uno de los mencionados sistemas operativos el acceso a segundos dispositivos de entrada y/o salida del mencionado ordenador (100) al que cada uno de ellos tiene acceso compartido.
- 8. El procedimiento de la reivindicación 7, en el que todos los sistemas operativos acceden a los mencionados segundos dispositivos de entrada y/o salida usando las rutinas del primer sistema operativo (201).
- 9. El procedimiento de la reivindicación 1, comprendiendo de manera adicional la combinación de los mencionados sistemas operativos y el programa común (400) dentro de un único producto de código.
- 10. El procedimiento de la reivindicación 1, comprendiendo de manera adicional la incorporación de los mencionados sistemas operativos y el programa común (400) en memoria permanente en un producto de ordenador.
- 11. Un producto de programa de ordenador de equipo de desarrollo que comprende un código para realizar los pasos de la reivindicación 1.
- 12. Un producto de programa de ordenador que comprende un código combinado de acuerdo con la reivindica-
ción 9. - 13. Un sistema de ordenador incorporado que comprende una CPU, dispositivos de memoria y dispositivos de entrada/salida, habiendo almacenado en memoria permanente en los mismos los programas incorporados de acuerdo con la reivindicación 10.
- 14. Un sistema de ordenador que comprende una CPU, dispositivos de memoria y dispositivos de entrada/salida, teniendo que ejecutar en los mismos un código de ordenador, comprendiendo del sistema de ordenador:
- un primer sistema operativo (201) que tiene una prioridad alta;
- un segundo sistema operativo (202) que tiene una prioridad inferior a la prioridad del primer sistema operativo (201); y
\global\parskip1.000000\baselineskip
- un programa común (400) organizado para ejecutar los mencionados sistemas operativos de manera concurrente por medio de la conmutación entre los mencionados sistemas operativos
- caracterizado porque el programa común (400) está organizado para pasar interrupciones concebidas para el primer y para el segundo sistemas operativos al primer sistema operativo (201),
- y porque el primer sistema operativo (201) está organizado para procesar las interrupciones destinadas para el primer sistema operativo (201), y para pasar las interrupciones concebidas para el segundo sistema operativo (202) de nuevo al programa común (400) para su envío al segundo sistema operativo (202).
- 15. Un sistema de ordenador de acuerdo con la reivindicación 14, organizado para ejecutar los mencionados primer y segundo sistemas operativos de manera concurrente usando el procedimiento de cualquiera de las reivindicaciones 1 a la 8.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP03290894A EP1467282B1 (en) | 2003-04-09 | 2003-04-09 | Operating systems |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2315469T3 true ES2315469T3 (es) | 2009-04-01 |
Family
ID=32865085
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES03290894T Expired - Lifetime ES2315469T3 (es) | 2003-04-09 | 2003-04-09 | Sistemas operativos. |
Country Status (6)
| Country | Link |
|---|---|
| US (2) | US7434224B2 (es) |
| EP (2) | EP1467282B1 (es) |
| CN (2) | CN101349976A (es) |
| AT (1) | ATE409904T1 (es) |
| DE (1) | DE60323811D1 (es) |
| ES (1) | ES2315469T3 (es) |
Families Citing this family (124)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2004034184A2 (en) | 2002-08-23 | 2004-04-22 | Exit-Cube, Inc. | Encrypting operating system |
| US7975117B2 (en) * | 2003-03-24 | 2011-07-05 | Microsoft Corporation | Enforcing isolation among plural operating systems |
| EP1467282B1 (en) * | 2003-04-09 | 2008-10-01 | Jaluna SA | Operating systems |
| US8612992B2 (en) * | 2003-04-09 | 2013-12-17 | Jaluna Sa | Operating systems |
| US7647583B2 (en) * | 2003-05-20 | 2010-01-12 | Robert M Zeidman | Method and apparatus for emulating a hardware/software system using a computer |
| JP3952992B2 (ja) * | 2003-06-03 | 2007-08-01 | ソニー株式会社 | 情報処理装置、プロセス制御方法、並びにコンピュータ・プログラム |
| EP1503286B1 (en) * | 2003-07-30 | 2014-09-03 | Jaluna SA | Multiple operating system networking |
| US7836450B2 (en) * | 2003-08-28 | 2010-11-16 | Mips Technologies, Inc. | Symmetric multiprocessor operating system for execution on non-independent lightweight thread contexts |
| US7849297B2 (en) * | 2003-08-28 | 2010-12-07 | Mips Technologies, Inc. | Software emulation of directed exceptions in a multithreading processor |
| US7870553B2 (en) | 2003-08-28 | 2011-01-11 | Mips Technologies, Inc. | Symmetric multiprocessor operating system for execution on non-independent lightweight thread contexts |
| US7424599B2 (en) * | 2003-08-28 | 2008-09-09 | Mips Technologies, Inc. | Apparatus, method, and instruction for software management of multiple computational contexts in a multithreaded microprocessor |
| US9032404B2 (en) | 2003-08-28 | 2015-05-12 | Mips Technologies, Inc. | Preemptive multitasking employing software emulation of directed exceptions in a multithreading processor |
| CN1922576A (zh) * | 2003-09-30 | 2007-02-28 | 扎鲁纳股份有限公司 | 操作系统 |
| DE10348113A1 (de) * | 2003-10-16 | 2005-05-19 | Kuka Roboter Gmbh | Verfahren und Einrichtung zum Betreiben eines Sekundärbetriebssystems neben einem Primärbetriebssystem |
| US7587723B2 (en) * | 2003-11-13 | 2009-09-08 | International Business Machines Corporation | Restarting a shared virtual resource |
| CN1658185A (zh) * | 2004-02-18 | 2005-08-24 | 国际商业机器公司 | 相互独立地共存多个操作系统的计算机系统与其切换方法 |
| US20050216895A1 (en) * | 2004-03-23 | 2005-09-29 | Tran Hieu T | Method and apparatus for remote debugging of kernel and application software |
| US20050251806A1 (en) * | 2004-05-10 | 2005-11-10 | Auslander Marc A | Enhancement of real-time operating system functionality using a hypervisor |
| JP4233492B2 (ja) * | 2004-06-02 | 2009-03-04 | 富士通マイクロエレクトロニクス株式会社 | アドレス変換装置 |
| US7827558B2 (en) * | 2004-06-30 | 2010-11-02 | Devicevm, Inc. | Mechanism for enabling a program to be executed while the execution of an operating system is suspended |
| US20060010446A1 (en) * | 2004-07-06 | 2006-01-12 | Desai Rajiv S | Method and system for concurrent execution of multiple kernels |
| US7424601B2 (en) * | 2004-07-07 | 2008-09-09 | Yongyong Xu | Methods and systems for running multiple operating systems in a single mobile device |
| GB0423094D0 (en) * | 2004-10-18 | 2004-11-17 | Ttp Communications Ltd | Interrupt control |
| JP2006146758A (ja) * | 2004-11-24 | 2006-06-08 | Matsushita Electric Ind Co Ltd | コンピュータシステム |
| FI119664B (fi) | 2004-12-08 | 2009-01-30 | Open Invention Network Llc | Menetelmä elektronisissa laitteissa oleviin tiedostoihin pääsemiseksi |
| US7793288B2 (en) * | 2004-12-09 | 2010-09-07 | International Business Machines Corporation | Automatic resource management of a guest operating system using information in data set indicating minimum system requirement |
| US7748003B2 (en) * | 2004-12-20 | 2010-06-29 | International Business Machines Corporation | Hard real-time response |
| TW200627277A (en) * | 2005-01-24 | 2006-08-01 | Lite On Technology Corp | OS selection method and computer system utilizing same |
| US20060179326A1 (en) * | 2005-02-10 | 2006-08-10 | Kwok-Yan Leung | Security device using multiple operating system for enforcing security domain |
| US8219823B2 (en) | 2005-03-04 | 2012-07-10 | Carter Ernst B | System for and method of managing access to a system using combinations of user information |
| US7437546B2 (en) | 2005-08-03 | 2008-10-14 | Intel Corporation | Multiple, cooperating operating systems (OS) platform system and method |
| US7752436B2 (en) * | 2005-08-09 | 2010-07-06 | Intel Corporation | Exclusive access for secure audio program |
| TWI279678B (en) | 2005-09-07 | 2007-04-21 | Mitac Technology Corp | Method for fast switching between different operating systems in computer device with multiple operating systems |
| US7719132B2 (en) | 2005-09-28 | 2010-05-18 | L3 Communications Corporation | Ruggedized mobile computing device |
| US20070104340A1 (en) * | 2005-09-28 | 2007-05-10 | Knowles Electronics, Llc | System and Method for Manufacturing a Transducer Module |
| JP4597032B2 (ja) * | 2005-10-24 | 2010-12-15 | 株式会社ソニー・コンピュータエンタテインメント | コンピュータシステム、それにおける基本プログラムの起動方法、及びローダプログラム |
| FI20051114A0 (fi) * | 2005-11-03 | 2005-11-03 | Nokia Corp | Automaattinen monen tietokoneen käynnistys |
| US9189291B2 (en) * | 2005-12-12 | 2015-11-17 | International Business Machines Corporation | Sharing a kernel of an operating system among logical partitions |
| JP2007220086A (ja) * | 2006-01-17 | 2007-08-30 | Ntt Docomo Inc | 入出力制御装置、入出力制御システム及び入出力制御方法 |
| JP2007213494A (ja) | 2006-02-13 | 2007-08-23 | Ntt Docomo Inc | 更新起動装置及び更新起動制御方法 |
| US7950020B2 (en) * | 2006-03-16 | 2011-05-24 | Ntt Docomo, Inc. | Secure operating system switching |
| US7814307B2 (en) * | 2006-03-16 | 2010-10-12 | Microsoft Corporation | Fast booting a computing device to a specialized experience |
| US8042109B2 (en) * | 2006-03-21 | 2011-10-18 | Intel Corporation | Framework for domain-specific run-time environment acceleration using virtualization technology |
| US9201703B2 (en) | 2006-06-07 | 2015-12-01 | International Business Machines Corporation | Sharing kernel services among kernels |
| JP2008033392A (ja) * | 2006-07-26 | 2008-02-14 | Nec Corp | 仮想計算機システム及びその動作方法 |
| JP5028904B2 (ja) * | 2006-08-10 | 2012-09-19 | ソニー株式会社 | 電子機器、および起動方法 |
| US7689820B2 (en) * | 2006-09-27 | 2010-03-30 | L3 Communications Corporation | Rapid-boot computing device with dual operating systems |
| US8819483B2 (en) * | 2006-09-27 | 2014-08-26 | L-3 Communications Corporation | Computing device with redundant, dissimilar operating systems |
| US8082431B2 (en) * | 2006-09-29 | 2011-12-20 | Intel Corporation | System and method for increasing platform boot efficiency |
| US8424013B1 (en) * | 2006-09-29 | 2013-04-16 | Emc Corporation | Methods and systems for handling interrupts across software instances and context switching between instances having interrupt service routine registered to handle the interrupt |
| US8707337B2 (en) * | 2006-10-31 | 2014-04-22 | Motorola Mobility Llc | Dispatch API that permits midlets to initiate dispatch calls |
| US7689566B1 (en) * | 2006-12-12 | 2010-03-30 | Sun Microsystems, Inc. | Method for defining non-native operating environments |
| JP2008152462A (ja) * | 2006-12-15 | 2008-07-03 | Ntt Docomo Inc | 遠隔起動システム、遠隔起動サーバ及び通信端末 |
| JP2010514028A (ja) * | 2006-12-22 | 2010-04-30 | バーチャルロジックス エスエイ | 単一データ処理を共有するために複数の実行環境を有効化するシステム |
| JP2008305070A (ja) * | 2007-06-06 | 2008-12-18 | Hitachi Communication Technologies Ltd | 情報処理装置および情報処理装置システム |
| US8269756B2 (en) * | 2007-06-15 | 2012-09-18 | The Boeing Company | Controllable voltage device drivers and methods of operation therefor |
| US9454384B2 (en) * | 2007-07-05 | 2016-09-27 | Microsoft Technology Licensing, Llc | Custom operating system via a web-service |
| US8146107B2 (en) * | 2007-07-10 | 2012-03-27 | Mitel Networks Corporation | Virtual machine environment for interfacing a real time operating system environment with a native host operating system |
| TWI393114B (zh) * | 2007-09-05 | 2013-04-11 | Htc Corp | 在作業系統切換時逐步調整螢幕亮度的方法 |
| US8312476B2 (en) | 2007-09-05 | 2012-11-13 | Htc Corporation | Method for synchronizing information of dual operating systems |
| US20090083829A1 (en) * | 2007-09-20 | 2009-03-26 | C & S Operations, Inc. | Computer system |
| US20090158299A1 (en) * | 2007-10-31 | 2009-06-18 | Carter Ernst B | System for and method of uniform synchronization between multiple kernels running on single computer systems with multiple CPUs installed |
| US8230446B2 (en) * | 2007-11-28 | 2012-07-24 | International Business Machines Corporation | Providing a computing system with real-time capabilities |
| DE102007062114A1 (de) * | 2007-12-21 | 2009-07-23 | Opensynergy Gmbh | Kraftfahrzeug-Steuervorrichtung |
| EP2083525A1 (en) * | 2008-01-28 | 2009-07-29 | Merging Technologies S.A. | System to process a plurality of audio sources |
| FR2927438B1 (fr) * | 2008-02-08 | 2010-03-05 | Commissariat Energie Atomique | Methode de prechargement dans une hierarchie de memoires des configurations d'un systeme heterogene reconfigurable de traitement de l'information |
| US8364943B2 (en) * | 2008-02-29 | 2013-01-29 | Lenovo (Singapore) Pte. Ltd. | S3 BIOS operating system switch |
| US11385758B2 (en) | 2008-10-09 | 2022-07-12 | Aristocrat Technologies Australia Pty Limited | Gaming system and gaming system processor module |
| US11287939B2 (en) | 2008-10-09 | 2022-03-29 | Aristocrat Technologies Australia Pty Limited | Gaming system and gaming system processor module |
| AU2009222627B2 (en) | 2008-10-09 | 2011-07-21 | Aristocrat Technologies Australia Pty Limited | Gaming system and gaming system processor module |
| US20100180276A1 (en) * | 2009-01-15 | 2010-07-15 | Jiva Azeem S | Application partitioning across a virtualized environment |
| US20100265938A1 (en) * | 2009-04-16 | 2010-10-21 | Mitel Networks Corporation | Enhanced system operation by virtualization |
| US9348633B2 (en) | 2009-07-20 | 2016-05-24 | Google Technology Holdings LLC | Multi-environment operating system |
| US9389877B2 (en) | 2009-07-20 | 2016-07-12 | Google Technology Holdings LLC | Multi-environment operating system |
| US9372711B2 (en) | 2009-07-20 | 2016-06-21 | Google Technology Holdings LLC | System and method for initiating a multi-environment operating system |
| US9367331B2 (en) | 2009-07-20 | 2016-06-14 | Google Technology Holdings LLC | Multi-environment operating system |
| KR101610828B1 (ko) * | 2009-09-23 | 2016-04-08 | 삼성전자주식회사 | 멀티코어 프로세서의 인터럽트 온/오프 관리 장치와 방법 |
| US9110568B2 (en) * | 2009-10-13 | 2015-08-18 | Google Inc. | Browser tab management |
| GB0919253D0 (en) * | 2009-11-03 | 2009-12-16 | Cullimore Ian | Atto 1 |
| KR20110072922A (ko) * | 2009-12-23 | 2011-06-29 | 삼성전자주식회사 | 화상형성장치의 추가 확장기능을 실행하는 방법 및 이를 수행하는 화상형성장치 |
| CN101782861A (zh) * | 2009-12-24 | 2010-07-21 | 华为终端有限公司 | 在嵌入式系统中操作系统的管理方法及装置 |
| US20110219373A1 (en) * | 2010-03-02 | 2011-09-08 | Electronics And Telecommunications Research Institute | Virtual machine management apparatus and virtualization method for virtualization-supporting terminal platform |
| US8433889B2 (en) | 2010-04-28 | 2013-04-30 | Acer Cloud Technology, Inc. | Operating system context switching |
| US8819321B2 (en) | 2010-06-03 | 2014-08-26 | Dell Products L.P. | Systems and methods for providing instant-on functionality on an embedded controller |
| CN103180829B (zh) * | 2010-10-22 | 2016-08-03 | 三菱电机株式会社 | 中断信号接收装置及计算机装置 |
| US8983536B2 (en) * | 2010-10-22 | 2015-03-17 | Google Technology Holdings LLC | Resource management in a multi-operating environment |
| KR101761615B1 (ko) | 2010-10-29 | 2017-08-04 | 엘지전자 주식회사 | 이동 단말기 및 그 제어 방법 |
| KR101727041B1 (ko) * | 2010-10-29 | 2017-04-14 | 엘지전자 주식회사 | 이동 단말기 및 그 제어 방법 |
| US8875276B2 (en) | 2011-09-02 | 2014-10-28 | Iota Computing, Inc. | Ultra-low power single-chip firewall security device, system and method |
| US9178981B2 (en) * | 2010-12-22 | 2015-11-03 | Lg Electronics Inc. | Mobile terminal and method of sharing information therein |
| US9354900B2 (en) * | 2011-04-28 | 2016-05-31 | Google Technology Holdings LLC | Method and apparatus for presenting a window in a system having two operating system environments |
| US20120278747A1 (en) * | 2011-04-28 | 2012-11-01 | Motorola Mobility, Inc. | Method and apparatus for user interface in a system having two operating system environments |
| US8904216B2 (en) | 2011-09-02 | 2014-12-02 | Iota Computing, Inc. | Massively multicore processor and operating system to manage strands in hardware |
| JP5729266B2 (ja) * | 2011-11-15 | 2015-06-03 | 富士通株式会社 | 情報処理装置、情報処理装置の制御方法、及び情報処理装置の制御プログラム |
| CN103136052A (zh) * | 2011-11-25 | 2013-06-05 | 展讯通信（上海）有限公司 | 移动终端及安装有多个操作系统的移动终端的控制方法 |
| US8544082B2 (en) | 2012-01-05 | 2013-09-24 | Lenovo (Singapore) Pte. Ltd. | Security reuse in hybrid information handling device environments |
| US20130293573A1 (en) | 2012-05-02 | 2013-11-07 | Motorola Mobility, Inc. | Method and Apparatus for Displaying Active Operating System Environment Data with a Plurality of Concurrent Operating System Environments |
| US9342325B2 (en) | 2012-05-17 | 2016-05-17 | Google Technology Holdings LLC | Synchronizing launch-configuration information between first and second application environments that are operable on a multi-modal device |
| CN102819497B (zh) * | 2012-05-31 | 2015-09-30 | 华为技术有限公司 | 一种内存分配方法、装置及系统 |
| CN103839017B (zh) * | 2012-11-20 | 2019-07-26 | 联想(北京)有限公司 | 一种电子设备状态的切换方法及系统 |
| CN103870295B (zh) * | 2012-12-13 | 2017-03-29 | 联想(北京)有限公司 | 切换方法和电子设备 |
| WO2014100273A1 (en) * | 2012-12-18 | 2014-06-26 | Dynavisor, Inc. | Dynamic device virtualization |
| CN104050019A (zh) * | 2013-03-15 | 2014-09-17 | 宇宙互联有限公司 | 具有操作系统共享控制功能的电子装置、系统及方法 |
| US20140325041A1 (en) * | 2013-04-27 | 2014-10-30 | Tencent Technology (Shenzhen) Co., Ltd. | Method, apparatus, server and system for adapting a client to a hardware environment |
| CN105247491B (zh) * | 2013-06-07 | 2019-03-12 | 三菱电机株式会社 | 计算机系统和控制方法 |
| CN103744693B (zh) * | 2013-12-13 | 2017-12-08 | 乐视致新电子科技（天津）有限公司 | 一种多系统切换方法及电子设备 |
| CN104156270B (zh) * | 2014-07-28 | 2018-02-06 | 浪潮(北京)电子信息产业有限公司 | 一种单机同时运行多操作系统的方法及系统 |
| US10662295B2 (en) | 2014-08-12 | 2020-05-26 | The Regents Of The University Of California | Trehalose hydrogels for stabilization and delivery of proteins |
| US9928079B2 (en) * | 2014-09-23 | 2018-03-27 | Dialog Semiconductor (Uk) Limited | Conditional processor auto boot with no boot loader when coupled with a nonvolatile memory |
| CN104572287B (zh) * | 2015-01-30 | 2018-12-25 | 西安酷派软件科技有限公司 | 一种系统切换时保持应用状态的方法、装置及终端 |
| CN105068897A (zh) * | 2015-07-17 | 2015-11-18 | 东莞市健创电子有限公司 | 实现车载智能双系统的方法及其双系统和该双系统平台 |
| CN105159819B (zh) * | 2015-09-01 | 2018-03-13 | 汉柏科技有限公司 | 一种记录内核异常栈及调试信息的方法及系统 |
| TR201608894A3 (tr) * | 2016-06-27 | 2018-03-21 | Tusas Tuerk Havacilik Ve Uzay Sanayii Anonim Sirketi | Bir gerçek zamanlı çalışma yöntemi. |
| JP6615726B2 (ja) * | 2016-09-16 | 2019-12-04 | 株式会社東芝 | 情報処理装置、情報処理方法及びプログラム |
| CN106445702A (zh) * | 2016-09-21 | 2017-02-22 | 乐视控股（北京）有限公司 | 多系统通信方法及终端 |
| CN106681817B (zh) * | 2016-12-27 | 2021-01-15 | 宇龙计算机通信科技(深圳)有限公司 | 一种终端控制方法以及终端 |
| CN108829442B (zh) * | 2017-05-04 | 2021-12-14 | 杭州海康威视数字技术股份有限公司 | 程序启动方法及装置 |
| CN107436810A (zh) * | 2017-07-03 | 2017-12-05 | 北京东土科技股份有限公司 | 一种计算机系统资源调度方法及装置 |
| US10169030B1 (en) | 2017-09-13 | 2019-01-01 | International Business Machines Corporation | Refreshing a software component without interruption |
| CN110134491B (zh) * | 2018-02-09 | 2023-08-08 | 威纶科技股份有限公司 | 信息处理传输装置 |
| CN112136110A (zh) * | 2018-05-07 | 2020-12-25 | 三菱电机株式会社 | 信息处理装置、调整方法及调整程序 |
| CN109032029B (zh) * | 2018-08-14 | 2020-12-08 | 北京东土科技股份有限公司 | 工业服务器对外通信方法、系统、装置及工业服务器 |
| EP3611642B1 (en) * | 2018-08-17 | 2020-08-12 | Omron Corporation | Method for operating an industrial pc device and industrial pc device |
| CN115098402B (zh) * | 2022-07-25 | 2023-01-06 | 摩尔线程智能科技(北京)有限责任公司 | 调试方法以及调试装置 |
Family Cites Families (53)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4764864A (en) | 1985-04-04 | 1988-08-16 | Nec Corporation | Circuit arrangement capable of improving overhead of a control program on interrupting into a virtual machine |
| US4747040A (en) | 1985-10-09 | 1988-05-24 | American Telephone & Telegraph Company | Dual operating system computer |
| JP2629278B2 (ja) | 1988-06-30 | 1997-07-09 | 株式会社日立製作所 | 仮想計算機システム |
| DE3831048A1 (de) | 1988-09-12 | 1990-03-15 | Nixdorf Computer Ag | Betriebsprogramm fuer eine datenverarbeitungsanlage |
| US5144692A (en) * | 1989-05-17 | 1992-09-01 | International Business Machines Corporation | System for controlling access by first system to portion of main memory dedicated exclusively to second system to facilitate input/output processing via first system |
| US5355490A (en) | 1991-06-14 | 1994-10-11 | Toshiba America Information Systems, Inc. | System and method for saving the state for advanced microprocessor operating modes |
| US5596755A (en) | 1992-11-03 | 1997-01-21 | Microsoft Corporation | Mechanism for using common code to handle hardware interrupts in multiple processor modes |
| US5530858A (en) * | 1993-04-01 | 1996-06-25 | Intel Corporation | Method and apparatus for background processing for PCMCIA card services |
| US5379432A (en) * | 1993-07-19 | 1995-01-03 | Taligent, Inc. | Object-oriented interface for a procedural operating system |
| US6684261B1 (en) * | 1993-07-19 | 2004-01-27 | Object Technology Licensing Corporation | Object-oriented operating system |
| US6116768A (en) * | 1993-11-30 | 2000-09-12 | Texas Instruments Incorporated | Three input arithmetic logic unit with barrel rotator |
| US5884077A (en) | 1994-08-31 | 1999-03-16 | Canon Kabushiki Kaisha | Information processing system and method in which computer with high load borrows processor of computer with low load to execute process |
| US5721922A (en) | 1994-10-13 | 1998-02-24 | Intel Corporation | Embedding a real-time multi-tasking kernel in a non-real-time operating system |
| US5903752A (en) | 1994-10-13 | 1999-05-11 | Intel Corporation | Method and apparatus for embedding a real-time multi-tasking kernel in a non-real-time operating system |
| US5740438A (en) | 1995-03-31 | 1998-04-14 | International Business Machines Corporation | Methods and system for network communications of multiple partitions |
| US5812823A (en) | 1996-01-02 | 1998-09-22 | International Business Machines Corporation | Method and system for performing an emulation context save and restore that is transparent to the operating system |
| US6535929B1 (en) | 1996-07-02 | 2003-03-18 | Sun Microsystems, Inc. | Universal communication mechanism for applications running in a multitasking environment |
| US5995745A (en) | 1996-12-23 | 1999-11-30 | Yodaiken; Victor J. | Adding real-time support to general purpose operating systems |
| US6199096B1 (en) * | 1997-03-14 | 2001-03-06 | Efusion, Inc. | Method and apparatus for synchronizing information browsing among multiple systems |
| US6269409B1 (en) * | 1997-09-02 | 2001-07-31 | Lsi Logic Corporation | Method and apparatus for concurrent execution of operating systems |
| US6772419B1 (en) * | 1997-09-12 | 2004-08-03 | Hitachi, Ltd. | Multi OS configuration system having an interrupt process program executes independently of operation of the multi OS |
| FI108478B (fi) * | 1998-01-21 | 2002-01-31 | Nokia Corp | Sulautettu jõrjestelmõ |
| EP0944003A1 (en) * | 1998-03-18 | 1999-09-22 | SONY EUROPE GmbH | Notification subsystem |
| US6134653A (en) | 1998-04-22 | 2000-10-17 | Transwitch Corp. | RISC processor architecture with high performance context switching in which one context can be loaded by a co-processor while another context is being accessed by an arithmetic logic unit |
| US6496847B1 (en) | 1998-05-15 | 2002-12-17 | Vmware, Inc. | System and method for virtualizing computer systems |
| FR2793906B1 (fr) | 1999-05-19 | 2001-08-10 | Bull Sa | Systeme et procede de gestion d'attributs dans un environnement oriente objet |
| JP3659062B2 (ja) * | 1999-05-21 | 2005-06-15 | 株式会社日立製作所 | 計算機システム |
| US6760783B1 (en) * | 1999-05-21 | 2004-07-06 | Intel Corporation | Virtual interrupt mechanism |
| JP2000347883A (ja) | 1999-06-03 | 2000-12-15 | Matsushita Electric Ind Co Ltd | 仮想計算機装置 |
| US6920633B1 (en) * | 2000-01-14 | 2005-07-19 | Microsoft Corporation | Cross-process common system resource data sharing |
| US6763327B1 (en) | 2000-02-17 | 2004-07-13 | Tensilica, Inc. | Abstraction of configurable processor functionality for operating systems portability |
| US7036106B1 (en) | 2000-02-17 | 2006-04-25 | Tensilica, Inc. | Automated processor generation system for designing a configurable processor and method for the same |
| US6715016B1 (en) | 2000-06-01 | 2004-03-30 | Hitachi, Ltd. | Multiple operating system control method |
| EP1162536A1 (en) * | 2000-06-09 | 2001-12-12 | Hitachi, Ltd. | Multiple operating system control method |
| US6381524B1 (en) | 2000-06-20 | 2002-04-30 | Hitachi, Ltd. | Vehicle travel control apparatus |
| US6868507B1 (en) * | 2000-11-07 | 2005-03-15 | Intel Corporation | Operating system independent |
| US20020078339A1 (en) * | 2000-12-15 | 2002-06-20 | Shen Hung-Ju | Booting system and booting method for an assistant operation system |
| US20020161961A1 (en) * | 2001-01-17 | 2002-10-31 | Ajile Systems, Inc. | Multiple virtual machine environment management system |
| US7079531B2 (en) * | 2001-03-28 | 2006-07-18 | Siemens Communications, Inc. | Method and apparatus for providing a software adaption layer in a telecommunications system |
| US6789156B1 (en) | 2001-05-22 | 2004-09-07 | Vmware, Inc. | Content-based, transparent sharing of memory units |
| JP2003036174A (ja) * | 2001-07-25 | 2003-02-07 | Hitachi Ltd | 車載端末装置 |
| US7191440B2 (en) * | 2001-08-15 | 2007-03-13 | Intel Corporation | Tracking operating system process and thread execution and virtual machine execution in hardware or in a virtual machine monitor |
| US7356677B1 (en) * | 2001-10-19 | 2008-04-08 | Flash Vos, Inc. | Computer system capable of fast switching between multiple operating systems and applications |
| US6725289B1 (en) | 2002-04-17 | 2004-04-20 | Vmware, Inc. | Transparent address remapping for high-speed I/O |
| US6920587B2 (en) * | 2002-04-25 | 2005-07-19 | International Business Machines Corporation | Handling multiple operating system capabilities in a logical partition data processing system |
| KR100421144B1 (ko) | 2002-05-24 | 2004-03-04 | 삼성전자주식회사 | 미디어 게이트웨이 콘트롤 프로토콜방식의 보이스 오버인터넷 프로토콜 호 서비스를 위한 헤드 엔드 장치 |
| US7210144B2 (en) * | 2002-08-02 | 2007-04-24 | Microsoft Corporation | Method for monitoring and emulating privileged instructions of programs in a virtual machine |
| US6782424B2 (en) | 2002-08-23 | 2004-08-24 | Finite State Machine Labs, Inc. | System, method and computer program product for monitoring and controlling network connections from a supervisory operating system |
| US8214531B2 (en) | 2002-10-24 | 2012-07-03 | Emulex Design & Manufacturing Corporation | Network configuration synchronization for hardware accelerated network protocol |
| US8612992B2 (en) | 2003-04-09 | 2013-12-17 | Jaluna Sa | Operating systems |
| EP1467282B1 (en) | 2003-04-09 | 2008-10-01 | Jaluna SA | Operating systems |
| EP1503286B1 (en) | 2003-07-30 | 2014-09-03 | Jaluna SA | Multiple operating system networking |
| CN1922576A (zh) | 2003-09-30 | 2007-02-28 | 扎鲁纳股份有限公司 | 操作系统 |
-
2003
- 2003-04-09 EP EP03290894A patent/EP1467282B1/en not_active Expired - Lifetime
- 2003-04-09 DE DE60323811T patent/DE60323811D1/de not_active Expired - Lifetime
- 2003-04-09 AT AT03290894T patent/ATE409904T1/de not_active IP Right Cessation
- 2003-04-09 ES ES03290894T patent/ES2315469T3/es not_active Expired - Lifetime
- 2003-09-22 US US10/665,352 patent/US7434224B2/en active Active
-
2004
- 2004-04-07 EP EP07016570A patent/EP1879108A1/en not_active Withdrawn
- 2004-04-07 US US10/552,608 patent/US8201170B2/en active Active
- 2004-04-07 CN CNA2008100986316A patent/CN101349976A/zh active Pending
- 2004-04-07 CN CNB2004800135732A patent/CN100392598C/zh not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| US20040205755A1 (en) | 2004-10-14 |
| US8201170B2 (en) | 2012-06-12 |
| EP1467282A2 (en) | 2004-10-13 |
| DE60323811D1 (de) | 2008-11-13 |
| EP1467282A3 (en) | 2004-12-22 |
| EP1879108A1 (en) | 2008-01-16 |
| EP1467282B1 (en) | 2008-10-01 |
| CN1791862A (zh) | 2006-06-21 |
| US7434224B2 (en) | 2008-10-07 |
| CN101349976A (zh) | 2009-01-21 |
| ATE409904T1 (de) | 2008-10-15 |
| CN100392598C (zh) | 2008-06-04 |
| US20070022421A1 (en) | 2007-01-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2315469T3 (es) | Sistemas operativos. | |
| US9619279B2 (en) | Operating systems sharing supervisor address space with same virtual to physical mapping for supervisor address space using same translation formula with different translation tree | |
| JP6130617B1 (ja) | ハイパーバイザーを有するシステム | |
| US8612992B2 (en) | Operating systems | |
| JP4639233B2 (ja) | プロセッサ・リソースの仮想化のためのシステムおよび方法 | |
| US7552426B2 (en) | Systems and methods for using synthetic instructions in a virtual machine | |
| US20070078891A1 (en) | Operating systems | |
| JPH11149385A (ja) | マルチｏｓ構成方法 | |
| WO2014120113A1 (en) | Assigning processors to memory mapped configuration | |
| JP2007507779A (ja) | オペレーティングシステム | |
| JP5819350B2 (ja) | 計算機システム及び起動方法 | |
| JP6198858B2 (ja) | 計算機、及び、ハイパバイザによる資源スケジューリング方法 | |
| JP6679419B2 (ja) | メモリ保護ユニット、メモリ管理ユニット、及びマイクロコントローラ | |
| EP1616257B1 (en) | Operating systems | |
| JP2001216172A (ja) | マルチｏｓ構成方法 | |
| JP7196439B2 (ja) | 仮想化環境におけるデバイスへのアクセス方法 | |
| EP1673693B1 (en) | Operating systems |