ES2303105T3 - Procedimiento y dispositivo para ejecutar un sistema operativo secundario junto a un sistema operativo primario. - Google Patents
Procedimiento y dispositivo para ejecutar un sistema operativo secundario junto a un sistema operativo primario. Download PDFInfo
- Publication number
- ES2303105T3 ES2303105T3 ES04790389T ES04790389T ES2303105T3 ES 2303105 T3 ES2303105 T3 ES 2303105T3 ES 04790389 T ES04790389 T ES 04790389T ES 04790389 T ES04790389 T ES 04790389T ES 2303105 T3 ES2303105 T3 ES 2303105T3
- Authority
- ES
- Spain
- Prior art keywords
- operating system
- interrupt
- secondary operating
- primary
- request
- 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.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 43
- 230000008859 change Effects 0.000 claims abstract description 36
- 230000015654 memory Effects 0.000 claims description 29
- 230000000694 effects Effects 0.000 claims description 6
- 230000006870 function Effects 0.000 claims description 5
- 230000004044 response Effects 0.000 claims 2
- 201000007651 Brooke-Spiegler syndrome Diseases 0.000 description 51
- 230000008569 process Effects 0.000 description 9
- 230000006872 improvement Effects 0.000 description 3
- 230000000284 resting effect Effects 0.000 description 3
- 230000006978 adaptation Effects 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 238000005192 partition Methods 0.000 description 2
- 230000015572 biosynthetic process Effects 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 230000009977 dual effect Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 230000002035 prolonged effect Effects 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
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/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/45537—Provision of facilities of other operating environments, e.g. WINE
-
- 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/4401—Bootstrapping
- G06F9/4406—Loading of operating system
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Stored Programmes (AREA)
- Hardware Redundancy (AREA)
- Multi Processors (AREA)
- Control Of Eletrric Generators (AREA)
- Radiation-Therapy Devices (AREA)
- Control And Safety Of Cranes (AREA)
Abstract
Procedimiento para ejecutar (implementar) un sistema operativo secundario en un procesador junto a un sistema operativo primario, con un cambio de sistema operativo primario a sistema operativo secundario causado por una solicitud de interrupción (Interrupt), caracterizado porque para cargar y controlar el sistema operativo secundario se carga y activa un driver del sistema operativo secundario (driver SBS) del sistema operativo primario, porque con una solicitud de interrupción se produce un cambio de las tablas de interrupción de los sistemas operativos y porque el driver del sistema operativo secundario determina mediante una rutina de tratamiento de la solicitud de interrupción la información almacenada en la tabla de interrupciones del sistema operativo secundario, en el lugar en el que tiene que producirse en el sistema operativo secundario la ejecución de la solicitud de interrupción.
Description
Procedimiento y dispositivo para ejecutar un
sistema operativo secundario junto a un sistema operativo
primario.
La invención se refiere a un procedimiento y a
un dispositivo para hacer funcionar un sistema operativo secundario
en un ordenador junto a un sistema operativo primario según la
definición de la reivindicación 1 o de la reivindicación 19.
Se conoce el funcionamiento de dos sistemas
operativos en un ordenador, más exactamente en la memoria de acceso
aleatorio de un ordenador, no sólo de manera alternativa sino
opcionalmente sin reiniciar el ordenador.
Así, WO 98/09225 muestra un sistema operativo de
ampliación en tiempo real para los sistemas Windows de Microsoft
convencionales -incapaces por sí mismo del tiempo real- mediante
micronúcleos especiales (microkernel).
DE 44 06 094 C2 muestra igualmente una
ampliación de tiempo real de los sistemas Windows de Microsoft
convencionales por medio de un sistema operativo de tiempo real que
puede funcionar en un ordenador por separado, es decir,
independientemente de Windows. El sistema operativo de tiempo real
secundario tiene acceso directo sólo a un subconjunto del registro
del procesador y de los componentes de hardware del ordenador.
Se sabe, además, emular bajo un sistema
operativo un ordenador virtual (virtual machine) sobre el que puede
ejecutarse entonces un segundo sistema operativo. El sistema
operativo secundario se ejecuta aquí bajo el control del programa
monitor que emula el ordenador virtual. El sistema operativo
secundario no puede acceder directamente a todo el registro del
procesador, sino sólo bajo el control del programa monitor. Según el
estado actual de la técnica es fundamentalmente problemático que
deba conocerse el código fuente de cómo mínimo uno de los sistemas
operativos, ya que al ejecutarlo se interviene en partes del mismo,
por lo general no reveladas por el proveedor del sistema, o incluso
hay que hacer modificaciones de tales partes, en especial las
mismas, en como mínimo uno de los sistemas operativos. Además,
resulta desventajoso si un sistema operativo debe ejecutarse
"bajo" otro, es decir, estar alojado en este último
(embedded).
La publicación "Dual System Operation" en
IBM Technical Disclosure Bulletin tomo 11, No. 12, abril 1990,
páginas 1899-1900 (D1) describe un procedimiento de
este tipo, donde el sistema operativo primario (p. ej. IBM
System/360 Disk Operating System, DOS) está alojado en una partición
inferior y el sistema operativo secundario (p. ej. IBM System/360
Remote Access Computing System, RAX) en una partición superior de la
memoria del sistema. Ambos sistemas operativos funcionan
independientemente entre sí y por medio de una rutina Dispatcher
que recurre a ambos sistemas operativos y constituye de esta manera
el único punto de unión entre los sistemas operativos. El
Dispatcher asume el almacenamiento en la memoria o el
restablecimiento del estado del correspondiente sistema operativo
antes o después del cambio de sistema operativo. Un cambio del
sistema operativo primario al sistema operativo secundario es
provocado por una solicitud de interrupción (interrupt) que es
recogida por el Dispatcher, que primero establece si la
correspondiente solicitud de interrupción está asignada a una
cambio de sistema operativo antes de introducir éste eventualmente.
Una vez finalizado el tratamiento del correspondiente proceso del
sistema operativo secundario, mediante una solicitud de interrupción
asignada el Dispatcher es inducido a introducir un cambio inverso
del sistema operativo secundario al sistema operativo primario.
Sin embargo, la implementación de un
procedimiento de este tipo presupone una adaptación del código
fuente de los sistemas operativos, en especial del núcleo de los
sistemas operativos, que en la mayoría de los casos no es
abierto.
US 5,483,647 A se refiere a un procedimiento
para ejecutar (implementar) un sistema operativo secundario en un
procesador junto a un sistema operativo primario. Se trata, por el
contrario, de dos sistemas operativos cada uno de los cuales se
ejecuta sobre un procesador, o sea, sobre dos procesadores
distintos.
La publicación "Jaluna-2
Preview Release 1 Description", diciembre 2002, describe
únicamente un paquete de software para ejecutar (implementar) un
sistema operativo secundario (Linux) en un procesador, alojado
(embedded) en un sistema operativo primario (micronúcleo de tiempo
real C5), que puede configurarse por medio del correspondiente
núcleo del sistema operativo y/o del correspondiente BSP. No se
describe el procedimiento para cambiar del sistema operativo
primario al sistema operativo secundario.
En el objeto de EP 1 054 322 A2 se usa un
manipulador de interrupción común junto con una tabla de gestión de
interrupción sobre una unidad común de cambio de sistema operativo
de ambos sistemas operativos. La publicación no revela ningún
procedimiento ni ningún dispositivo para un cambio del sistema
operativo primario al sistema operativo secundario provocado por
una solicitud de interrupción (interrupt).
La invención tiene como objetivo crear un
procedimiento y un dispositivo mediante los cuales se puedan
ejecutar en un ordenador como mínimo dos sistemas operativos sin
reducción de su rendimiento, en especial manteniendo las
capacidades de tiempo real sin intervenir en el sistema operativo
secundario, sino como máximo interviniendo en su Board Support
Packet, si bien cuando el sistema operativo secundario está activo
funciona en la unidad central del procesador (CPU) de tal manera
que está cargado como -único- sistema operativo y por consiguiente
puede acceder a todo el procesador y a su área de memoria virtual
sin ningún tipo de limitación.
Según la invención, el citado objetivo se
consigue mediante un procedimiento con las características de la
reivindicación 1 y mediante un dispositivo con las características
de la reivindicación 19.
Según la invención, el acceso del sistema
operativo secundario se produce sin la ayuda del sistema operativo
primario.
La configuración en la que los dos sistemas
operativos están implementados juntos en un ordenador significa que
ambos sistemas operativos funcionan en éste de manera totalmente
independiente uno del otro, en especial los sistemas operativos no
se presuponen uno y otro - o sea, que tampoco el sistema operativo
secundario presupone la presencia funcional del sistema operativo
primario. El driver del sistema se usa exclusivamente para cambiar
los sistemas operativos. Por lo tanto, se podría sobreescribir todo
el área de seguridad del PBS, incl. el driver, en el SBS sin
menoscabar su funcionamiento, aunque naturalmente ya no es posible
retroceder al PBS. Esto incluye en especial que un sistema
operativo (especialmente el sistema operativo secundario) no se
asienta sobre el otro (especialmente el sistema operativo primario)
ni tampoco que accede a éste. Durante el funcionamiento de un
sistema operativo no se realiza ninguna parte del código del otro.
En especial, el sistema operativo secundario no accede durante su
funcionamiento al driver del sistema. Por lo tanto, según la
invención ningún sistema operativo está alojado en el otro, por lo
tanto no presupone éste de manera permanente. Esto es válido en
especial también para el sistema operativo secundario con respecto
al sistema operativo primario. Para abrir y ejecutar un sistema
operativo, en especial el sistema operativo secundario, no se
necesita ninguna información del otro sistema operativo, el sistema
operativo primario, incluido el driver del sistema en el sistema
operativo citado en primer lugar (sistema operativo secundario).
Ambos sistemas operativos, en especial el sistema operativo
secundario, pueden ejecutarse de manera totalmente autónoma.
Mediante la previsión según la invención de un
driver del sistema operativo primario para controlar y cargar el
sistema operativo secundario a través de su
Board-Support-Package, o
paquete-de-apoyo-a-las-placas,
se evita que el núcleo del sistema operativo secundario deba
modificarse para la ejecución del mismo incluso como sistema
operativo secundario junto a un sistema operativo primario.
El
Board-Support-Package es el software
que crea la conexión entre un hardware (el Board) y un sistema
operativo (Support). Los sistemas operativos que se utilizan sobre
varias plataformas (entorno de hardware incl. procesador, memoria,
etc.) tienen siempre un BSP que es por consiguiente un componente
fijo del sistema operativo. Los sistemas operativos alojados, tales
como Windows CE, constan de un núcleo de sistema operativo y el
BSP, mediante cuya modificación puede adaptarse el sistema operativo
a una plataforma de hardware especial y debe hacerlo sin tener que
conocer el núcleo del sistema operativo.
El
Board-Support-Package de un sistema
operativo es revelado regularmente por el proveedor del sistema
operativo en el código fuente ya que contiene en especial los
denominados servicios básicos de hardware, a través de los cuales
se establecen las interfaces necesarias para el sistema operativo en
cuestión, como por ejemplo controlador de interrupciones, reloj del
sistema, y se desarrollan con ello para el uso en distintos
sistemas de hardware, es decir, distintas plataformas de CPU, tal
como el hardware específico del fabricante, en especial el que
varía del cuasi-estándar. Con ello, mediante la solución
según la invención se usan como sistema operativo secundario todos
los sistemas operativos que pueden adaptarse y configurarse con
ayuda de un Board-Support-Package
sin que pierdan su rendimiento al usarlos como sistema operativo
secundario y, siempre que se trate de sistemas operativos de tiempo
real, sin que pierdan su capacidad de ejecución a tiempo real.
Cambiando las tablas de interrupción en la
memoria volátil, debido a las informaciones de las entradas en la
tabla de interrupciones del sistema operativo secundario, al
producirse una interrupción en el sistema operativo secundario se
inicia la rutina de servicio de interrupción correcta del sistema
operativo secundario de tal manera que desde el punto de vista del
mismo se produce el mismo proceso como si no existiera ningún
sistema primario. De este modo es posible ejecutar juntos o en
paralelo dos sistemas operativos sin conocer el código fuente. Así,
según la invención, ningún tipo de información del sistema operativo
primario se guarda en la zona de memoria del sistema operativo
secundario. Ningún sistema operativo posee información acerca del
otro.
En otra configuración preferida del
procedimiento según la invención está previsto que el driver del
sistema operativo secundario cargado con el sistema operativo
primario (driver-SBS) cargue el sistema operativo
secundario y en concreto en una zona de memoria de la memoria de
acceso aleatorio física no utilizada por el sistema operativo
primario, preferentemente su zona superior.
En una configuración preferida está previsto
crear en la unidad central del ordenador (CPU) contextos de memoria
(espacios de trabajo virtuales), pudiendo montar en especial el
driver-SBS en la unidad central (CPU) un contexto
de túnel a través del cual se gestione el cambio de ejecución de los
sistemas operativos. El espacio de trabajo virtual designado como
contexto consta de bloques discrecionales de la memoria física. Una
Memory-Management-Unit (MMU)
administra los contextos de este tipo en una tabla de asignación de
memoria designada como tabla MMU con la que se describe el
contexto. En la técnica de programación se mueve uno en el espacio
de trabajo virtual, que mediante el modo de trabajo de la MMU remite
a la memoria física.
En un perfeccionamiento está previsto que
después de la carga del sistema operativo secundario, se produce un
salto en el mismo, y en concreto más exactamente en el
Board-Support-Package, que provoca
la formación de un nuevo contexto para arrancar el sistema
operativo secundario en el procesador.
En otra configuración está previsto que en el
contexto túnel se cargue, entre otras cosas, una página de memoria
túnel contenida en el driver en la cual se ramifica el desarrollo
del programa, después de lo cual a través de este código de
programa del sistema operativo secundario se carga en el nuevo
contexto de memoria y se continúa el proceso de arranque completo
del sistema operativo secundario.
Para la realización de los pasos de
procedimiento antes citados, en una configuración preferida del
dispositivo según la invención está previsto que el driver SBS
presente una sección de carga del SBS y una zona túnel que contiene
la página de memoria túnel.
En un perfeccionamiento preferido del
procedimiento según la invención, después de la carga o de cualquier
ejecución del sistema operativo secundario se produce un cambio
desde éste al sistema operativo primario ya sea estando en reposo
el sistema operativo secundario (entrando el mismo en su bucle de
marcha en vacío - Idle-Loop) o mediante un comando
correspondiente de retorno en el desarrollo del programa del sistema
operativo secundario para saltar al sistema operativo primario.
Para la realización de este paso del
procedimiento, el dispositivo según la invención prevé además que
el Board-Support-Package presente
una sección correspondiente de retorno.
Para el cambio del sistema operativo primario al
sistema operativo secundario a través de una exigencia de
interrupción SBS determinada para el sistema operativo secundario,
el driver SBS presenta una sección de tabla de interrupción
mediante la cual genera en el sistema operativo primario una tabla
de solicitud de interrupción (tabla de interrupción) que, entre
otras cosas, contiene una solicitud de una rutina de tratamiento de
interrupción para abrir el sistema operativo secundario.
En un perfeccionamiento preferido del
procedimiento según la invención está previsto por lo tanto que una
rutina de tratamiento de interrupción en el driver SBS lea la tabla
de solicitud de interrupción del sistema operativo secundario y se
produce o continúa el tratamiento del último lugar afectado por la
solicitud de interrupción.
Si se produce una solicitud de interrupción que
no está determinada para el sistema operativo primario, el driver
del sistema SBS inicia éste y a través del
Board-Support-Package lo deriva al
sistema operativo secundario, de tal manera que según la invención
se produce un cambio entre los sistemas operativos mediante el
driver-SBS del sistema operativo primario y del
Board-Support-Package del sistema
operativo secundario.
En especial, siempre que el procesador no
soporte el cambio directo de contextos, hay previsto según la
invención en otra configuración que el cambio de la actividad de los
sistemas operativos mediante una zona túnel se produzca en el
contexto de túnel superpuesto adicionalmente al sistema operativo
primario y al contexto de sistema operativo secundario.
En otra configuración preferida del
procedimiento según la invención está previsto que al cambiar de un
sistema operativo a otro sistema operativo se almacenan todos los
estados del sistema (en memoria de acceso aleatorio), en especial
todo el registro de la CPU, y preferentemente además se vacía todo
el caché interno del procesador. En un perfeccionamiento
correspondiente está previsto que al cambiar de un sistema operativo
a otro sistema operativo se cargan en el procesador los nuevos
estados del sistema del otro sistema operativo, en especial los
contenidos del registro de la CPU y las (tablas MMU) de gestión de
memoria.
Por último, en otra configuración la invención
prevé que la generación de impulsos de reloj para el sistema
operativo secundario se produce mediante el reloj principal del
hardware (Timer), es decir, que sólo tiene acceso a él el sistema
operativo secundario, mientras que la generación de impulsos de
reloj para el sistema operativo primario se produce mediante un
driver del sistema de impulsos de reloj. En especial esto está
previsto y es ventajoso cuando el sistema operativo secundario es un
sistema operativo de tiempo real para controlar una máquina o
instalación industrial, mientras que el sistema operativo primario
sirve para el manejo por parte de un operador y ofrece a éste en
especial una superficie gráfica ergonómica para el manejo.
Más ventajas y características de la invención
resultan de las reivindicaciones y de la descripción siguiente, en
la que se explica un ejemplo de realización de la invención tomando
como referencia los dibujos individualmente. Allí se muestra:
Fig. 1 la asignación del sistema operativo
primario y del sistema operativo secundario a los distintos recursos
de un ordenador, así como la estructura de un sistema operativo en
el ejemplo del sistema operativo secundario;
Fig. 2 un diagrama del proceso de carga del
sistema operativo secundario así como en reposo del sistema
operativo secundario de retorno al sistema operativo primario;
Fig. 3 un cambio del sistema operativo primario
al sistema operativo secundario; y
Fig. 4 una representación para la sincronización
del reloj del sistema operativo primario.
\newpage
La Fig. 1 muestra la asignación de los recursos
(de hardware) HR de un ordenador al sistema operativo primario PBS
y al sistema operativo secundario SBS dentro del marco de la
invención. Muestra además la estructura de principio de un sistema
operativo en el ejemplo del sistema operativo secundario SBS.
Un sistema operativo presenta primero un núcleo
o Kernel K como núcleo central del mismo. Presenta además un
Board-Support-Package BSP o
paquete-de-apoyo-a-las-placas
en el que se implementan los servicios básicos del hardware BHD.
Estos constituyen las interfaces al hardware necesarias para el
sistema operativo tales como controlador de interrupciones, reloj
del sistema, etc. Los BHD permiten usar el sistema operativo en
diferentes sistemas de hardware. El BSP lo facilita por lo general
el fabricante en forma de fuente para que el fabricante del
hardware pueda adaptar el sistema operativo a su hardware.
El sistema operativo presenta además servicios
de arquitectura AD que forman las interfaces a los servicios
específicos del ordenador central necesarias para el sistema
operativo, tales como tratamiento de excepciones e interrupciones,
administración de la MMU. Los AD permiten al sistema operativo
funcionar en distintas plataformas de unidades centrales del
procesador (plataforma CPU).
El sistema operativo presenta además servicios
de sistema operativo (BSD) genéricos que facilitan valiosos
servicios de software de aplicación AS (AS1, AS2) tales como
administración de memoria, servicios de red, servicios de tareas
múltiples, etc. Por lo general, en un sistema operativo únicamente
el BSP está disponible en forma de fuente, mientras que no son
posibles las adaptaciones de los servicios de arquitectura y los
servicios de sistema operativo genéricos. Se representan además las
memorias físicas PS1 y PS2 asignadas a los dos sistemas operativos
así como partes de los controles de interrupción IC1 e IC2, que
controlan las interrupciones para el PBS o el SBS.
Tal como se ve de la Fig. 1, los recursos
importantes del ordenador para el sistema operativo se asignan del
modo siguiente:
Ambos sistemas operativos utilizan en el momento
de su actividad toda la memoria virtual VS y todo el registro de
CPU CPU-R, como en especial el registro estándar, el
registro de coma flotante, el registro de control. Ambos sistemas
operativos se distribuyen primero la memoria de acceso aleatorio
RAM, poseyendo cada sistema operativo una parte de esta memoria y
estando cargado el sistema operativo secundario SBS preferentemente
en la parte superior de la memoria de acceso aleatorio RAM. Se
distribuyen además el controlador de interrupciones IRC,
asignándose a cada sistema operativo interrupciones unívocas.
El sistema operativo secundario tiene en
especial acceso exclusivo al reloj del sistema SZG, mientras que el
sistema operativo primario PBS tiene acceso exclusivo al disco duro
FP. A cada uno de los sistemas operativos hay asignados el driver
T1 (al sistema operativo primario) o T2 (al sistema operativo
secundario), entre otras cosas para gestionar el hardware adicional
del correspondiente sistema operativo, ZHP para el sistema
operativo primario y ZHS para el sistema operativo secundario.
Uno de los driver del sistema operativo primario
es el driver SBS-T para cargar el sistema operativo
secundario.
En la Fig. 2 se representa la carga del sistema
operativo secundario SBS.
Se presupone aquí en primer lugar que el sistema
operativo primario PBS está cargado en la memoria del ordenador de
manera habitual por medio de un cargador de arranque y que con ello
también se carga al mismo tiempo el driver del sistema
SBS-T para el sistema operativo secundario SBS.
Después de cargar el sistema operativo primario
PBS, el SBS-T carga el sistema operativo secundario
en una zona distinta de la memoria RAM no utilizada por el sistema
operativo primario PBS, preferentemente la zona superior de la RAM
física, de tal manera que el driver del sistema operativo secundario
SBS-T forma el cargador de arranque para el sistema
operativo secundario SBS.
Junto al contexto de memoria superpuesto del
modo habitual para el sistema operativo primario PBS, superpuesto
por el mismo, para usar el sistema operativo secundario se superpone
en el driver del sistema un contexto BK para arrancar el sistema
operativo secundario y un contexto túnel TK en la CPU para cambiar
entre los contextos PK del sistema operativo primario y el BK.
El salto desde el driver del sistema
SBS-T al sistema operativo secundario se produce
después del proceso de carga en el
Board-Support-Package del sistema
operativo secundario (pasos 1 a 2 de la Fig. 2). El driver del
sistema SBS-T, tal como indica la flecha, se
necesita exclusivamente para el cambio desde el sistema operativo
primario al secundario. A continuación se continúa el tratamiento
del programa en el
Board-Support-Package del sistema
operativo secundario. El
Board-Support-Package superpone
entonces el contexto BK necesario para arrancar el SBS. Después, el
desarrollo del programa se ramifica en la zona túnel TB del contexto
túnel TK (paso 3), se carga el contexto de arranque BK (paso 4) y
se continúa el proceso de arranque del sistema operativo secundario
(paso 5). Para ello, el SBS superpone su propio contexto en el que
se ramifica para cada cambio futuro del PBS en el SBS.
La zona túnel contiene para ello el "código de
conmutación" entre el contexto de cargador de arranque o
contexto secundario y el contexto túnel. La zona túnel consta
exactamente de un lado de la memoria en el que está depositado el
código de conmutación. Este código de conmutación se encuentra en
todos los contextos (contexto túnel y contexto cargador de arranque
o contexto secundario) en la misma dirección virtual.
Después del cambio al sistema operativo
secundario SBS y en su ejecución, el sistema operativo secundario
ya no necesitará el driver del sistema SBS-T, no
accede a éste o a otras partes cualesquiera del sistema operativo
primario PBS y tampoco las usa. De este modo el sistema operativo
secundario funciona de manera totalmente autónoma.
Si el sistema operativo secundario SBS llega a
un estado de reposo IL (Idle-Loop), se produce
automáticamente un retorno al sistema operativo primario (pasos 6,
7, 8). Mientras que el sistema operativo secundario está activo,
las solicitudes de interrupción que aparezcan son tratadas
exclusivamente por el sistema operativo secundario SBS.
Antes de la carga del sistema operativo
secundario SBS -y con cualquier cambio de éste- se almacenan todos
los registros de la CPU del sistema operativo primario y se vacían
los cachés internos de la CPU.
Al cargar el sistema operativo secundario -y al
cambiar el mismo- se cargan todos los registros de la CPU del
sistema operativo secundario SBS y sus tablas de MMU.
Al cambiar del sistema operativo secundario SBS
al sistema operativo primario PBS se producen de manera
correspondiente el aseguramiento de los estados del sistema del
sistema operativo secundario y la carga de los estados del sistema
para el sistema operativo primario.
Si la unidad central del ordenador (CPU) soporta
un cambio directo de contextos, como es el caso por ejemplo en la
arquitectura Intel-X86 a través de segmentos
Task-Safe, también puede prescindirse del contexto
túnel, de tal manera que el cambio entre los sistemas operativos
puede realizarse directamente a través del contexto primario PK y
el contexto secundario SK.
Un cambio de la actividad del sistema operativo
primario PBS para abrir y activar el sistema operativo secundario
SBS se produce exclusivamente en una solicitud de interrupción
(Interrupt) determinada para el último. Al aparecer una de este
tipo, el driver del sistema ST y el BSP del sistema operativo
secundario se ramifican en el contexto de memoria SK del sistema
operativo secundario SBS y tratan allí la correspondiente rutina de
servicio de interrupción asignada.
Estando en actividad el sistema operativo
primario, para cambiar al sistema operativo secundario se realizan
entonces los pasos representados en la Fig. 3.
Cuando el sistema operativo primario está activo
y se produce un desarrollo de interrupción (Interrupt), la unidad
central del ordenador ramifica debido a la exigencia de interrupción
directamente en el driver del sistema (paso A) - la interrupción
será iniciada por el driver del sistema. El driver del sistema ST
asegura todos los registros del procesador y cambia al contexto
túnel TK (Fig. 2). El driver del sistema ramifica directamente en
el tratamiento de interrupción genérico del BSP del sistema
operativo secundario. Directamente basándose o accediendo a la
tabla de interrupción del sistema operativo secundario, se calcula
aquí dónde está la rutina del servicio de interrupción ISR del
sistema operativo secundario, hacia donde ramificarse el
tratamiento (paso B).
El tratamiento de interrupción genérico,
ramificado por el driver del sistema a través de la función de
túnel, que activa el contexto de sistema operativo secundario SK
(paso C), pasa entonces directamente a la función de tratamiento de
interrupción ISR en el sistema operativo secundario SBS (paso D) - y
no a través de cualquier código especial del sistema operativo
secundario, que según la invención ya no es necesario y ya no está
presente.
A continuación se trata el sistema operativo
secundario SBS hasta que todos los procesos ceden su tiempo de
cálculo y con ello se ramifica en el bucle de reposo
(Idle-Loop) del sistema operativo secundario
SBS.
Si el sistema operativo secundario SBS está
activo y aparece una interrupción para este mismo, se produce
automáticamente la solicitud de la rutina de servicio de
interrupción ISR sin más intervenciones. El propio procesador salta
allí ya que al cambiar desde el sistema operativo primario de manera
habitual al sistema operativo secundario en el procesador se
intercambia la tabla de interrupciones, y por lo tanto con este
cambio se aplica la tabla de interrupciones del sistema operativo
secundario SBS. Por lo tanto en la Fig. 3 se muestra exclusivamente
el paso D. Por ese motivo también es posible borrar el sistema
operativo primario PBS y su driver del sistema sin padecer
limitaciones para el sistema operativo secundario SBS.
Desde el bucle de reposo se cambia entonces a
través de la zona túnel al contexto túnel TK (pasos 6, 7 en la Fig.
2). La función túnel regresa entonces de nuevo al driver del sistema
del sistema operativo primario PBS (paso 8), desde donde éste activa
de nuevo el contexto primario PK y continúa la ejecución del sistema
operativo primario PBS:
Alternativamente al uso del bucle de reposo IL
del sistema operativo secundario SBS como punto de salto para
cambiar al sistema operativo primario, existe la posibilidad de
producir este cambio a través de un proceso regular en el sistema
operativo secundario SBS. Para ello existe en el SBS una función del
sistema operativo secundario SBS que puede ser abierta desde
procesos. La solicitud vuelve entonces a ramificar hacia el sistema
operativo primario (pasos 6 a 8) hasta que aparece la siguiente
interrupción para el sistema operativo secundario SBS.
Tal como se ha dicho ya anteriormente, el
sistema operativo secundario SBS controla el reloj principal del
sistema HSZG. Para ello se modifica el sistema operativo primario,
por ejemplo mediante Patches, para que todos los accesos al reloj
principal del sistema HSZG sean recogidos por el driver del sistema
ST. Éste almacena informaciones sobre con qué velocidad de impulso
de reloj debe ejecutarse el sistema operativo primario PBS. Las
velocidades de impulso de reloj en el sistema operativo secundario
deben ser superiores a las del sistema operativo primario. Para la
sincronización del reloj del sistema operativo primario, además del
reloj principal HZG en el driver del sistema marcha, tal como se
muestra en la Figura 4, un reloj virtual VZ con menor velocidad de
impulso de reloj, que siempre se implementa entonces alrededor de la
velocidad de impulso de reloj del sistema operativo primario PBS en
cuanto que discurre de manera real el tiempo correspondiente. Si el
sistema operativo secundario no indica durante un período prolongado
el tiempo de cálculo, el reloj para el sistema operativo primario
acaba marchando a mayor velocidad hasta que se recupera la
diferencia de tiempo y concretamente en el impulso de reloj del
sistema operativo secundario. Con ello se consigue que el reloj del
sistema operativo primario no vaya retrasado.
\vskip1.000000\baselineskip
- AD
- servicios de arquitectura
- BHD
- servicios básicos del hardware
- BSD
- servicios del sistema operativo
- BSP
- Board-Support-Package
- CPU
- unidad central del procesador
- CPU-R
- registro de la CPU
- FP
- disco duro
- HR
- recursos del hardware
- IC1
- parte del controlador de interrupciones que controla las interrupciones para el PBS
- IC2
- parte del controlador de interrupciones que controla las interrupciones para el SBS
- IL
- Idle-Loop
- IRC
- controlador de interrupciones
- K
- núcleo
- PBS
- sistema operativo primario
- PK
- contexto del sistema operativo primario
- PS1
- memoria física que se asigna al PBS
- PS2
- memoria física que se asigna al SBS
- RAM
- memoria de acceso aleatorio
- SBS
- sistema operativo secundario
- SBS-T
- driver para cargar el sistema operativo secundario
- SK
- contexto del sistema operativo secundario
- SK
- contexto de memoria
- ST-T
- zona del driver del sistema
- SZG
- reloj del sistema
- T1
- driver del sistema operativo primario
- T2
- driver del sistema operativo secundario
- TB
- zona túnel
- TK
- contexto túnel
- ZHP
- hardware adicional del sistema operativo primario
- ZHS
- hardware adicional del sistema operativo secundario.
Claims (24)
1. Procedimiento para ejecutar (implementar) un
sistema operativo secundario en un procesador junto a un sistema
operativo primario, con un cambio de sistema operativo primario a
sistema operativo secundario causado por una solicitud de
interrupción (Interrupt), caracterizado porque para cargar y
controlar el sistema operativo secundario se carga y activa un
driver del sistema operativo secundario (driver SBS) del sistema
operativo primario, porque con una solicitud de interrupción se
produce un cambio de las tablas de interrupción de los sistemas
operativos y porque el driver del sistema operativo secundario
determina mediante una rutina de tratamiento de la solicitud de
interrupción la información almacenada en la tabla de interrupciones
del sistema operativo secundario, en el lugar en el que tiene que
producirse en el sistema operativo secundario la ejecución de la
solicitud de interrupción.
2. Procedimiento según la reivindicación 1,
caracterizado porque en la unidad central del ordenador (CPU)
se crean contextos de memoria (espacios de trabajo virtuales).
3. Procedimiento según una cualquiera de las
reivindicaciones 1 ó 2, caracterizado porque un cambio entre
los sistemas operativos se produce por medio del driver SBS del
sistema operativo primario y del paquete de apoyo a las placas
(BSP).
4. Procedimiento según una cualquiera de las
reivindicaciones 1 a 3, caracterizado porque el sistema
operativo secundario controla un cambio al sistema operativo
primario.
5. Procedimiento según la reivindicación 4,
caracterizado porque un cambio del sistema operativo
secundario al sistema operativo primario se produce estando en
reposo el sistema operativo secundario (entrada en el
Idle-Loop).
6. Procedimiento según la reivindicación 5,
caracterizado porque un cambio del sistema operativo
secundario al sistema operativo primario se produce mediante un
comando en el desarrollo del programa del sistema operativo
secundario.
7. Procedimiento según una cualquiera de las
anteriores reivindicaciones, caracterizado porque el cambio
entre los sistemas operativos se produce por medio de un código de
programa depositado en una zona túnel de la memo-
ria.
ria.
8. Procedimiento según una cualquiera de las
anteriores reivindicaciones, caracterizado porque durante la
ejecución del sistema operativo secundario se bloquean las
solicitudes de interrupción del sistema operativo
prima-
rio.
rio.
9. Procedimiento según una cualquiera de las
anteriores reivindicaciones, caracterizado porque una rutina
de tratamiento de interrupciones en el driver SBS lee la tabla de
solicitud de interrupción del sistema operativo secundario y sigue
o continúa el tratamiento de este último en el lugar afectado por la
solicitud de interrupción.
10. Procedimiento según una cualquiera de las
anteriores reivindicaciones, caracterizado porque para cada
interrupción asignada al sistema operativo secundario (que por lo
tanto debe desencadenar una solicitud de interrupción en el sistema
operativo secundario) el driver del sistema genera una entrada en la
tabla de interrupciones del sistema operativo primario, que
entonces desencadena a su vez una solicitud de la correspondiente
rutina de tratamiento de interrupciones en el sistema operativo
secundario.
11. Procedimiento según una cualquiera de las
anteriores reivindicaciones, caracterizado porque en caso de
actividad del sistema operativo secundario (SBS), en respuesta a una
solicitud de interrupción por parte de la información almacenada en
la tabla de interrupciones del sistema operativo secundario en el
lugar del sistema operativo secundario en el que debe ejecutarse la
solicitud de interrupción (Interrupt), la rutina de tratamiento de
la solicitud de interrupción del sistema operativo secundario (SBS)
es solicitada directamente por el sistema operativo secundario sin
pasar a través del driver del sistema.
12. Procedimiento según una cualquiera de las
reivindicaciones 9 a 11, caracterizado porque después de
producirse una solicitud de interrupción correspondiente y la
determinación del lugar del sistema operativo secundario en el que
debe producirse el tratamiento de la interrupción, se continúa el
tratamiento de la misma en el lugar afectado por la solicitud de
interrupción en el sistema operativo secundario.
13. Procedimiento según una cualquiera de las
anteriores reivindicaciones, caracterizado porque al cambiar
de un sistema operativo al otro, se almacenan todos los estados del
sistema de uno de los sistemas operativos.
14. Procedimiento según una cualquiera de las
anteriores reivindicaciones, caracterizado porque al cambiar
de un sistema operativo al otro sistema operativo se cargan todos
los estados del sistema del otro sistema operativo.
15. Procedimiento según una cualquiera de las
anteriores reivindicaciones, caracterizado porque la
generación de impulsos de reloj para el sistema operativo
secundario se produce a través del reloj principal del hardware
(Timer).
16. Procedimiento según una cualquiera de las
anteriores reivindicaciones, caracterizado porque la
generación de impulsos de reloj para el sistema operativo primario
se produce por medio de un driver del sistema de impulsos de
reloj.
17. Dispositivo para ejecutar un sistema
operativo secundario en un procesador junto a un sistema operativo
primario con un cambio del sistema operativo primario al sistema
operativo secundario provocado por una solicitud de interrupción
(Interrupt), caracterizado por un driver del sistema
operativo secundario (driver SBS) del sistema operativo primario
para cargar y controlar el sistema operativo secundario, estando
prevista para el tratamiento de la solicitud de interrupción una
función de intercambio de las tablas de interrupciones de los
sistemas operativos y formándose en el driver SBS una rutina de
tratamiento de las solicitudes de interrupción para determinar la
información almacenada en la tabla de interrupciones del sistema
operativo secundario acerca del lugar del sistema operativo
secundario en el que debe producirse el tratamiento de la solicitud
de interrupción.
18. Dispositivo según la reivindicación 17,
caracterizado porque el driver SBS presenta una rutina de
superposición de contexto de túnel para superponer un contexto de
túnel en la unidad central (CPU).
19. Dispositivo, en particular según las
reivindicaciones 17 ó 18, caracterizado porque está
configurado para intercambiar las tablas de interrupciones en caso
de un cambio de la actividad de los sistemas operativos.
20. Dispositivo según las reivindicaciones 17 ó
19, caracterizado porque el driver SBS presenta una rutina
de modificación de las tablas de solicitud de interrupciones para
generar entradas en la tabla de solicitud de interrupciones del
sistema operativo primario, que realiza como mínimo entradas para
las solicitudes de interrupción para el sistema operativo
secundario.
21. Dispositivo según una de las
reivindicaciones 17 a 20, caracterizado porque el
Board-Support-Package (BSP)
presenta una sección para el retorno al sistema operativo primario
(PBS).
22. Dispositivo según una cualquiera de las
reivindicaciones 17 a 21, caracterizado porque el driver del
sistema operativo secundario (driver SBS) presenta una sección de
tablas de interrupción, mediante la cual genera en el sistema
operativo primario una tabla de solicitudes de interrupción (tabla
Interrupt) que contiene una solicitud de una rutina de tratamiento
de interrupciones para la solicitud del sistema operativo
secundario.
23. Dispositivo según una cualquiera de las
reivindicaciones 17 a 22, caracterizado porque el driver del
sistema está configurado para generar una entrada en la tabla de
interrupciones del sistema operativo primario (PBS) para cada
interrupción asignada al sistema operativo secundario (SBS) (que
también debe desencadenar una solicitud de interrupción en el
sistema operativo secundario (SBS)) y porque la tabla de solicitudes
de interrupción está configurada para solicitar la correspondiente
rutina de tratamiento de interrupciones en el sistema operativo
secundario (SBS).
24. Dispositivo según una cualquiera de las
reivindicaciones 18 a 23, caracterizado porque está
configurado para que en el caso de actividad del sistema operativo
secundario (SBS), en respuesta a una solicitud de interrupción por
parte de la información almacenada en la tabla de interrupciones del
sistema operativo secundario en el lugar del sistema operativo
secundario en el que debe ejecutarse la solicitud de interrupción
(Interrupt), la rutina de tratamiento de la solicitud de
interrupción del sistema operativo secundario (SBS) es solicitada
directamente por el sistema operativo secundario sin pasar a través
del driver del sistema.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| DE10348113 | 2003-10-16 | ||
| DE10348113A DE10348113A1 (de) | 2003-10-16 | 2003-10-16 | Verfahren und Einrichtung zum Betreiben eines Sekundärbetriebssystems neben einem Primärbetriebssystem |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2303105T3 true ES2303105T3 (es) | 2008-08-01 |
Family
ID=34442006
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES04790389T Active ES2303105T3 (es) | 2003-10-16 | 2004-10-14 | Procedimiento y dispositivo para ejecutar un sistema operativo secundario junto a un sistema operativo primario. |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US8719836B2 (es) |
| EP (1) | EP1673696B1 (es) |
| JP (1) | JP2007537498A (es) |
| CN (1) | CN1867895B (es) |
| AT (1) | ATE387660T1 (es) |
| DE (2) | DE10348113A1 (es) |
| ES (1) | ES2303105T3 (es) |
| WO (1) | WO2005038651A1 (es) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN100382452C (zh) * | 2005-11-15 | 2008-04-16 | 中兴通讯股份有限公司 | 一种实现主备倒换的装置和方法 |
| CN101470675B (zh) * | 2007-12-29 | 2011-03-30 | 联想(北京)有限公司 | 一种数据输出方法和装置 |
| US9804857B2 (en) * | 2010-12-17 | 2017-10-31 | Intel Corporation | Method and apparatus for multi-mode mobile computing devices and peripherals |
| US9178981B2 (en) * | 2010-12-22 | 2015-11-03 | Lg Electronics Inc. | Mobile terminal and method of sharing information therein |
| CN102968342B (zh) * | 2012-11-12 | 2015-03-11 | 华中科技大学 | 嵌入式平台下半虚拟化的快速切换客户操作系统的方法 |
| JP5756144B2 (ja) * | 2013-04-22 | 2015-07-29 | レノボ・シンガポール・プライベート・リミテッド | オペレーティング・システムの管理方法、コンピュータ・プログラムおよびコンピュータ |
| CN107436810A (zh) * | 2017-07-03 | 2017-12-05 | 北京东土科技股份有限公司 | 一种计算机系统资源调度方法及装置 |
| US10977095B2 (en) | 2018-11-30 | 2021-04-13 | Microsoft Technology Licensing, Llc | Side-by-side execution of same-type subsystems having a shared base operating system |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS644838A (en) * | 1987-06-29 | 1989-01-10 | Yokogawa Electric Corp | Method for switching os (operating system) |
| US5483647A (en) | 1992-12-17 | 1996-01-09 | Bull Hn Information Systems Inc. | System for switching between two different operating systems by invoking the server to determine physical conditions to initiate a physical connection transparent to the user |
| DE4406094C2 (de) | 1994-02-25 | 2000-04-13 | Lp Elektronik Gmbh | Vorrichtung zum Betrieb einer Steuerungsanwendung |
| AU4145797A (en) | 1996-08-29 | 1998-03-19 | Nematron Corporation | Real time software system |
| AU4353297A (en) * | 1996-09-17 | 1998-04-14 | Radisys Corporation | Method and apparatus for encapsulating a protected-mode operating system within a real-time, protected-mode operating system |
| US6996828B1 (en) * | 1997-09-12 | 2006-02-07 | Hitachi, Ltd. | Multi-OS configuration method |
| JP2001216172A (ja) * | 1997-09-12 | 2001-08-10 | Hitachi Ltd | マルチｏｓ構成方法 |
| JP3659062B2 (ja) * | 1999-05-21 | 2005-06-15 | 株式会社日立製作所 | 計算機システム |
| EP1162536A1 (en) * | 2000-06-09 | 2001-12-12 | Hitachi, Ltd. | Multiple operating system control method |
| JP2003248593A (ja) * | 2002-02-25 | 2003-09-05 | Matsushita Electric Ind Co Ltd | マルチオペレーティングシステム制御装置 |
| ES2315469T3 (es) * | 2003-04-09 | 2009-04-01 | Virtuallogix Sa | Sistemas operativos. |
-
2003
- 2003-10-16 DE DE10348113A patent/DE10348113A1/de not_active Withdrawn
-
2004
- 2004-10-14 AT AT04790389T patent/ATE387660T1/de not_active IP Right Cessation
- 2004-10-14 ES ES04790389T patent/ES2303105T3/es active Active
- 2004-10-14 US US10/595,348 patent/US8719836B2/en not_active Expired - Fee Related
- 2004-10-14 EP EP04790389A patent/EP1673696B1/de not_active Not-in-force
- 2004-10-14 CN CN200480029966.2A patent/CN1867895B/zh not_active Expired - Fee Related
- 2004-10-14 WO PCT/EP2004/011526 patent/WO2005038651A1/de active IP Right Grant
- 2004-10-14 JP JP2006534680A patent/JP2007537498A/ja active Pending
- 2004-10-14 DE DE502004006343T patent/DE502004006343D1/de active Active
Also Published As
| Publication number | Publication date |
|---|---|
| US20060282698A1 (en) | 2006-12-14 |
| DE10348113A1 (de) | 2005-05-19 |
| EP1673696B1 (de) | 2008-02-27 |
| CN1867895A (zh) | 2006-11-22 |
| CN1867895B (zh) | 2011-05-25 |
| US8719836B2 (en) | 2014-05-06 |
| ATE387660T1 (de) | 2008-03-15 |
| JP2007537498A (ja) | 2007-12-20 |
| DE502004006343D1 (de) | 2008-04-10 |
| WO2005038651A1 (de) | 2005-04-28 |
| EP1673696A1 (de) | 2006-06-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2315469T3 (es) | Sistemas operativos. | |
| JP4979880B2 (ja) | グラフィックス処理ユニットのマルチスレッド式カーネル | |
| JP4322232B2 (ja) | 情報処理装置、プロセス制御方法、並びにコンピュータ・プログラム | |
| US7617381B2 (en) | Demand paging apparatus and method for embedded system | |
| KR20150033695A (ko) | 메모리 보호 | |
| US7529916B2 (en) | Data processing apparatus and method for controlling access to registers | |
| US20170206175A1 (en) | Hypervisor-enforced self encrypting memory in computing fabric | |
| JP2010020803A (ja) | コプロセッサの性能を強化するシステムおよび方法 | |
| US11163597B2 (en) | Persistent guest and software-defined storage in computing fabric | |
| KR20070083569A (ko) | 운영체제 | |
| US20100332722A1 (en) | Virtual machine system and control method thereof | |
| ES2303105T3 (es) | Procedimiento y dispositivo para ejecutar un sistema operativo secundario junto a un sistema operativo primario. | |
| US20130297924A1 (en) | Method of running multiple operating systems on an x86-based computer | |
| US9891908B2 (en) | Updatable integrated-circuit radio | |
| CN102693191A (zh) | 半导体器件和存储器保护方法 | |
| JP4785142B2 (ja) | データ処理装置 | |
| JP2009009232A (ja) | コンピュータとカーネル保護方法並びにコンピュータソフトウエア | |
| JP6679419B2 (ja) | メモリ保護ユニット、メモリ管理ユニット、及びマイクロコントローラ | |
| US9910677B2 (en) | Operating environment switching between a primary and a secondary operating system | |
| JP6326047B2 (ja) | 集積回路型無線 | |
| US6295603B1 (en) | Program controlled unit including a segment pointer selecting a bootstrap loader to be booted from a plurality of stored bootstrap loaders | |
| US20210132978A1 (en) | Virtualization system and operation management method | |
| US20190012179A1 (en) | Supporting soft reboot in multi-processor systems without hardware or firmware control of processor state | |
| JP2006079230A (ja) | 半導体回路装置及び暴走検出方法 | |
| US20190317902A1 (en) | Circuit and Method For Managing Access to Memory |