BRPI1006211B1 - Método para operar um computador, meio não transitório lido por computador, e dispositivo eletrônico - Google Patents

Abstract

MÉTODO PARA OPERAR UM COMPUTADOR,PRODUTO PROGRAMA DE COMPUTADOR, MÉTODO E DISPOSITIVO ELETRÔNICO. Métodos,sistema,aparelhos e produtos programas são divulgados para gerenciar múltiplos OSS dentro de um único computador resimilares ,É feita provisão para trocar OSS com assistência do BIOS e se conformar com características de ACPI para gerenciamento do Estado do Sistema especialmente como relacionado com o Estado de Dormir de Sistema S3 de ACPI.

Description

Campo da invenção

A presente invenção relaciona geralmente com computadores pessoais e dispositivos compartilhando arquiteturas similares, e mais particularmente relaciona com soluções para administrar, ativar e controlar uma pluralidade de ambientes de sistema operacional e/ou similares dentro de um aparelho de comunicação ou dentro de uma sessão ou contexto único operacional de computador.

Antecedentes da invenção

Modernamente, o uso de PCs (computadores pessoais) incluindo os chamados computadores laptops e notebooks, está crescentemente comum e os próprios computadores são de potência e complexidade crescente enquanto diminuindo a potência térmica.

Uma vasta maioria de PCs têm um software controlador, por exemplo, um OS (Sistema Operacional) tal como Microsoft® Windows® Vista® ou produto similar comercial. Muitas variedades de OSs estão disponíveis grandemente devido à necessidade de produzir trocas de designs. Em particular, riqueza de características com complexidade subordinada e tamanho são trocados contra capacidades (relativamente) limitadas com velocidade aumentada (especialmente velocidade de operação e tempo de carregamento).

Portanto, uma necessidade tem existido em prover o uso de múltiplos OSS dentro de um computador e várias soluções, cada uma com suas próprias trocas, foram usadas.

Uma solução, a chamada solução de "boot duplo", envolve selecionar e carregar o OS desejado a partir de um estado relativamente frio. Isto tem uma desvantagem de lentidão mas tem a vantagem que recursos são dedicados, ao invés de compartilhados ou divididos.

Outras soluções podem envolver a virtualização, que tem a desvantagem de prover comutações rápidas entre ambientes OS, mas existe uma desvantagem em que os softwares de OS mais complexos e populares disponíveis não estão projetados para funcionar bem em ambientes virtualizados e adicionais trocas e impactos resultam. Além disso, a virtualização pode requerer caracter!sticas de hardware 5 endereçadas à mesma e portanto ser de aplicação universal relativamente menor. Infelizmente, os vendedores de software OS complexo têm poucos incentivos para fazerem seus produtos funcionarem bem em coexistência pacífica com produtos OSs mais simples através da virtualização.

Produtos OSs mais simples têm vantagens além da velocidade, por exemplo, onde tal OS é "Fonte Aberto" ["Open Source"], o código fonte é menor e portanto mais compreensível. Além disso, software menos complexo tende a ser menos vulnerável a ataque de malware [software 15 malicioso].

Existem alternativas adicionais para boot duplo e virtualização (com trocas novamente diferentes) e a presente invenção está relacionada com tais alternativas. Sumário da invenção

As configurações da invenção provêem, entre outras coisas, soluções para prover assistência de direcionamento (controle) de OS em busca de suporte para múltiplos OSs (Sistemas Operacionais).

A presente invenção provê um método para operar um 25 computador para comunicações de dados e também um aparelho que configura o método. Em adição, produtos de programas e outros meios para explorar a invenção são apresentados.

De acordo com um aspecto da presente invenção, uma 30 configuração da invenção pode prover um primeiro e segundo OSs (sistemas operacionais) em partições separadas de uma memória do sistema, executar um pedido de instrução para uma mudança de Estado de Sistema de ACPI (Interface de Energia e Configuração Avançada), 35 restaurando um estado de hardware guardado do computador, e transferindo controle entre OSs.

Uma vantagem e/ou característica provida por ou resultando de implementar a presente invenção é que o controle pode ser passado entre múltiplos OSs (tipicamente dois OSs mas opcionalmente três ou mais) sem necessidade de qualquer de um tempo de reboot prolongado 5 ou as desvantagens inerentes no uso de técnicas de virtualização. Consequentemente, existe uma aparência de comutação "instantânea" entre OSs, ou pelo menos uma comutação que é materialmente mais rápida que implementações providas anteriormente. Além disso, 10 incorporando a invenção em uma sequência de boot quente, um serviço de ligação instantânea pode ser provido ou aproximado.

Descrição resumida dos desenhos

As vantagens e características mencionadas anteriormente 15 e relacionadas de configurações tornar-se-ão mais bem compreendidas e apreciadas mediante o exame da descrição detalhada seguinte da invenção, tomada em conjunção com os desenhos seguintes, que são incorporados em e constituem uma parte da especificação, ilustram uma 20 configuração da invenção e onde numerais iguais representam elementos iguais, e nos quais:

A figura 1 é um diagrama de blocos esquemático de um dispositivo eletrônico configurado para implementar funcionalidade de acordo com uma configuração da 25 invenção;

A figura 2 é um diagrama de fluxo ilustrando uma visão geral das etapas executadas ao implementar uma configuração da invenção;

As figuras 3 e 4 tomadas juntas são um diagrama de fluxo 30 um pouco mais detalhado ilustrando uma visão geral de algumas das etapas executadas ao implementar uma configuração da invenção em detalhes adicionais;

A figura 5 é uma ilustração que mostra como uma configuração exemplar da invenção pode ser codificada em 35 um meio ou mídia de computador; e

A figura 6 é uma ilustração que mostra como uma configuração exemplar da invenção pode ser codificada, transmitida, recebida e decodificada usando ondas eletromagnéticas.

Descrição detalhada da invenção

Os numerosos componentes mostrados nos desenhos são 5 apresentados para fornecer a uma pessoa de experiência ordinária na técnica uma divulgação habilitante, completa, de configurações da presente invenção. A descrição de componentes bem conhecidos não é incluida dentro desta descrição de modo a não obscurecer a 10 divulgação ou remover ou de outra forma reduzir a novidade de configurações da presente invenção e os principais benefícios assim providos.

Uma configuração exemplar da presente invenção será agora descrita com referência às figuras. A figura 1 é um 15 diagrama de blocos esquemático de um dispositivo eletrônico configurado para implementar a funcionalidade de segurança de acordo com uma configuração da invenção.

Em uma configuração exemplar, o dispositivo eletrônico 10 pode ser implementado como um computador pessoal, por 20 exemplo, um computador desktop, um computador laptop, um PC tablet [prancheta] ou outro dispositivo adequado. Embora a descrição delineie a operação de um computador pessoal, será apreciado por aqueles de experiência ordinária na técnica, que o dispositivo eletrônico 10 25 pode ser implementado como um PDA, dispositivo de comunicação sem fio, por exemplo, um telefone celular, controladores ou dispositivos embutidos, por exemplo, decodificadores externos, dispositivos de impressão ou outros dispositivos adequados ou combinações dos mesmos e 30 adequados para operar ou interoperar com a invenção.

O dispositivo eletrônico 10 pode incluir pelo menos um processador ou CPU (Unidade de Processamento Central) 12, configurado para controlar a operação global do dispositivo eletrônico 10. Controladores similares ou 35 MPUs (Unidades de Microprocessadores) são lugares comuns.

O processador 12 pode tipicamente ser acoplado a um controlador de barramento 14 tal como um chip Northbridge por meio de um barramento 13 tal como um FSB (Front-Side Bus [Barramento Lateral-Frontal]) . 0 controlador de barramento 14 pode tipicamente prover uma interface para memória de sistema de leitura-escrita 16 tal como RAM 5 (memória de acesso randômico).

Em operação ordinária, a CPU 12 pode conseguir instruções de computador (também denominadas códigos de instruções de computador, não mostrados na figura 1) a partir do sistema de memória 16. A CPU pode então interpretar as 10 instruções de computador trazidas e operar para interpretar as instruções para desta forma controlar a operação do dispositivo eletrônico 10. Tais usos de CPU, memória do sistema e instruções de computador que tipicamente compreendem códigos de OS (Sistema Operacional) e outro software são bem conhecidos nas técnicas de computação.

O controlador de barramento 14 também pode ser acoplado a um barramento de sistema 18, por exemplo, uma DMI (Interface de Midia Direta) em configurações tipicas 20 estilo Intel®. Acoplado à DMI 18 pode estar um chamado chip Southbridge, tal com um chip Intel® ICH8 (Hub [Nó] Controlador de Entrada/Saida tipo 8) 24.

O chip Southbridge 24 pode tipicamente incorporar um primeiro NIC (Controlador de Interface de Rede) 32, tal 25 como do tipo 1000 BASE-T da interface IEEE 802.3 (número de norma 802.3 do Instituto de Engenheiros Elétricos e Eletrônicos) se conectando a um tipo 8PC831 (8 posições, 8 contatos) de conector de rede por fios. Um conector 8PC8 31 é coloquialmente conhecido como uma porta RJ45 e 30 IEEE802.3 é coloquialmente conhecida como Ethernet.

Em uma configuração tipica, o chip Southbridge 24 pode ser conectado a um barramento PCI (interconexão de componente periférico) 22, o qual pode, por sua vez, ser conectado a um segundo NIC 66 que aciona um Transceptor 35 Sem Fio 71. O Transceptor Sem Fio 71 pode operar em conformidade com a IEEE 802.11 ou outras normas adequadas. O Transceptor Sem Fio 71 pode tipicamente ser acoplado a alguma forma de antena de rádio 72. Também, tipicamente, o chip Southbridge 24 também pode ser acoplado a uma NVRAM (memória de acesso randômico não volátil) 33.

Qualquer um ou ambos os NICs 32 e 66 podem transportar sinais de comunicações que são usados para formar conexões lógicas de rede tais como um Serviço Internet. De fato, um computador tipico ou dispositivo eletrônico 10 similar pode ter outras interfaces, por exemplo, uma 10 interface USB (Barramento Serial Universal, que não é mostrada na figura 1) que pode por sua vez se conectar com (por exemplo) um transceptor Bluetooth® para outros modos de comunicação dentro do escopo geral da invenção.

A figura 2 é um diagrama de fluxo ilustrando uma visão 15 geral de algumas das etapas executadas ao implementar uma configuração da invenção. A solução descrita na figura 2 é uma simplificação e serve como uma visão geral útil de uma compreensão superficial de como uma simples configuração de uma parte importante da invenção pode 20 operar.

Na etapa 200, a execução da parte pertinente dos códigos de instruções de BIOS começa. Como parte desta etapa, o BIOS define as áreas de memória que são usáveis por um OS e aquelas áreas que são reservadas para uso do BIOS (por 25 exemplo, EBDA (área de dados estendida do BIOS), NVS (armazenagem não volátil) de ACPI ou SMRAM (RAM do Modo de Gerenciamento de Sistema)). Alternativamente, algumas áreas de memória podem ser usadas por não BIOS, mas, entretanto, serviços dirigidos de hardware, por exemplo, 30 memória de video compartilhada. O BIOS então invoca o OSM (Módulo de Direcionamento de OS) que inicializa a memória incluindo a criação de tabelas, economizando memória base, economizando NVS de ACPI, valores PIC (controlador de interrupção programável), ganchos em serviços E820 35 para prover mapas sob medida, e similares. Os serviços E820 são bem conhecidos na técnica. Em uma configuração da invenção, o OSM é derivado do bem conhecido GRUB (programa Grande Carregador Unificado de Boot) e incorpora uma seção de carregador de boot. Portanto, inter alia, um contexto de hardware restaurável é economizado.

Na etapa 210, a seção de carregador de boot do OSM carrega o primeiro OS (sistema operacional). O OS chama serviços E820 para determinar quais áreas de memória fisica principal ele pode usar e se carrega naquela memória. 0 serviço de BIOS está ciente de qual OS está 10 solicitando serviços E820 (por exemplo, baseado no endereço de memória do chamador, ou no qual o OS foi o mais recentemente carregado ainda que os usos daqueles critérios sejam meramente exemplos) e apresenta um mapa de memória sob medida responsivo ao mesmo. Tipicamente, o primeiro OS é carregado em uma partição de memória restrita (relativamente pequena) e então executa programas de aplicações. Na etapa 220, um inicio é feito em um procedimento levando a entrar em um estado de economia, usando o pedido por Estado S3 de ACPI (ou serviços de gravar na RAM ou alguma coisa similar) incluídos em cada OS.

Na etapa 230, o OS grava o estado de cada dispositivo para o qual o OS tem um programa de driver, por exemplo, o registro pode ser em um buffer de memória. O OS também 25 pode descartar dados pendentes, tipicamente para fora para o disco. 0 OS exemplar escreve um valor especifico para um registro PM1_CNT controlado pela ACPI, indicando desta forma que o OS e contexto da plataforma são solicitados a fazer a transição iminentemente para o 30 Estado S3 de Sistema de ACPI. Os Estados de Sistema de ACPI são bem conhecidos na técnica.

A escrita para o registro PM1_CNT descrito acima pode ser capturada pelo OSM (na etapa 240) o qual, tendo adquirido controle da execução da plataforma, então faz uma 35 determinação de que o pedido é para uma comutação de contexto (em contraste com um estado de dormência da plataforma). Em uma configuração da invenção, a determinação é tornada responsiva a um bit de controle nas tabelas de dados OSM. As técnicas desenvolvidas anteriormente são tipicamente suficientes para cuidar especificamente de aspectos de multiprocessador da 5 integridade da plataforma. Vetores para despertar são armazenados da maneira usual para entrar no Estado S3 de ACPI.

Neste ponto o comportamento do OSM diverge grandemente da ação similar (até agora) envolvida em entrar em um Estado 10 S3 de ACPI. Por ter tomado muitas das mesmas ações que precedem entrar no Estado S3 de ACPI, o OSM prossegue ao invés para criar e guardar um contexto de hardware restaurável adicional e conjunto de vetores para despertar em preparação para carregar um segundo OS como 15 descrito abaixo. O processo de criar um contexto de hardware restaurável e conjunto de vetores para despertar é similar àquele descrito na etapa 200, acima.

Na etapa 250, o contexto de hardware que foi guardado na etapa 200 é reinstalado. Isto traz a plataforma 20 substancialmente de volta para seu estado de hardware inicial em preparação para carregar um segundo OS. Entretanto, o mapa de memória principal não é recriado, pelo contrário, o OSM garante que quando serviços E820 forem invocados a seguir será sabido pelo BIOS que o 25 segundo OS está ativo. O segundo OS é então carregado e alimentado.

Na etapa 260, o segundo OS, como parte de sua inicialização normal, invoca o serviço de BIOS que está ciente de qual OS está solicitando serviços E820. O mapa 30 de memória E820 retornado exclui a partição de memória restrita que foi colocada de lado para o primeiro OS e pode tipicamente incluir o residuo de RAM fisica disponível. O segundo OS então completa sua própria inicialização e executa programas de aplicações. Na etapa 270, responsive a um estimulo que torna desejável um retorno para um contexto do primeiro OS (e aplicações sendo executadas sob ele) se tornar ativo, o segundo OS invoca uma função de ACPI, a função "mudar o estado para S3", tal como por escrever novamente para o registro ACPI PM1_CNT. Pode ser notado que o segundo OS pode solicitar entrar no Estado S3 também responsivo a um 5 pedido para comutar para o primeiro OS (tal como por uma combinação personalizada de chaves). Alternativamente, o segundo OS pode escolher solicitar entrada iminente de modo S3 por uma razão não relacionada (tal como responsivo a um timer de inatividade). Na etapa 275, e em 10 geral, não obstante ganchos para fazer o segundo OS entrar em S3 sejam o propósito geral, o meio para invocá-los também adota uma ação que permite o OSM fazer uma determinação que o pedido foi conforme um desejo expresso para mudar o contexto de OS; isto envolverá tipicamente 15 colocar um valor em um registro visivel para o BIOS, p.ex., um modo para fazer só isto é invocar um serviço do BIOS criado para aquele propósito expresso. A criação e uso de tais serviços simples do BIOS para designar modos de vários tipos são bem conhecidos na técnica.

Na etapa 280, de uma maneira similar ao comportamento na etapa 240, o OSM assume o controle (tipicamente capturando uma escrita para PM1_CNT) . Assim, o OSM cria um contexto de hardware guardado substancialmente completo e conjunto de vetores para despertar para o 25 contexto do segundo OS. Tipicamente, isto pode sobrescrever o contexto guardado na etapa 200 uma vez que este não é mais necessário.

Na etapa 290, um contexto de hardware para o primeiro OS (guardado como descrito na etapa 240, acima) é 30 recarregado. O primeiro OS é reativado usando Vetores para Despertar guardados. Uma vez que o mapa de memória visto pelo primeiro OS exclui a memória dedicada ao segundo OS, não há necessidade de recarregar e/ou reinicializar o primeiro OS porque ele ainda está 35 residente na memória. Esta evitação da necessidade de recarregar e reinicializar o OS oferece uma melhoria significativa em relação a muitas soluções desenvolvidas anteriormente.

Na etapa 299, o processo continua passando para o controle para e a partir de o primeiro e segundo OSs responsive a pedidos originados pelo usuário (ou outro, 5 programático, por exemplo) para transferência de controle.

As figuras 3 e 4, tomadas juntas são um diagrama de fluxo um tanto mais detalhado ilustrando uma visão geral de algumas das etapas executadas ao implementar uma 10 particular configuração da invenção em detalhes adicionais. Esta configuração deve ser vista como puramente exemplar e não uma descrição genérica que limita a invenção.

Na etapa 300, como descrito em conexão com a figura 2, 15 novamente a execução da parte pertinente dos códigos de instrução do BIOS começa. Como parte desta etapa, o BIOS define as áreas de memória que são usáveis por um OS e aquelas áreas que são reservadas para uso do BIOS (por exemplo, EBDA (área de dados de BIOS estendida), NVS ACPI 20 (armazenagem não volátil) ou SMRAM (RAM de Modo de Gerenciamento do Sistema)). Alternativamente, algumas áreas de memória podem ser usadas por serviços de hardware não-BIOS, por exemplo, memória de video compartilhada. O BIOS então invoca o OSM (Módulo de 25 Direcionamento de OS) por INT 19 (a interrupção 19 é bem conhecida na técnica para transferir controle do BIOS para o carregador da rotina de inicialização ["bootstrap"]).

Na etapa 320, o OSM inicializa a memória incluindo a 30 criação de tabelas, guardando memória base, guardando NVS de ACPI, valores PIC (controlador de interrupção programável) , ganchos em serviços E820 para prover mapas sob medida e similares. Portanto, inter alia, um contexto de hardware restaurável é guardado.

Na etapa 350, o OSM seleciona HS (HyperSpace®, um produto da Phoenix Technologies Ltd., que inclui programas de aplicação e um OS arquiteturalmente similar a Linux®).

Na etapa 370, o OSM carrega e então transfere o controle para o HS.

Na etapa 380, o HS descobre que o OSM está carregado, e em modo real (ou não real) invoca o bem conhecido serviço E820 do BIOS (também descrito como int 15h call, AX == E820h). Sabendo que o chamador é o HS, o BIOS reserva uma porção relativamente pequena de memória para o HS (256 Mebibytes em uma implementação exemplar) e marca o espaço ARR (Faixa de Endereço Reservada). Em uma implementação, o BIOS reterá aquele espaço na ARM (Memória de Faixa de Endereço) sempre que o primeiro chamador do serviço E820 seguindo o boot ou reboot não for o HS.

Na etapa 390, o HS adapta seu mapa de memória para usar o I espaço ARR (Faixa de Endereço Reservada) de 258 MBytes. O HS evita carregar na ARM ou criar a pilha dentro do ARM -cujo comportamento é contrário à prática normal do Linux®.

Na etapa 3100, o HS executa aplicações HyperSpace® em modo de usuário.

Na etapa 3110, responsive a estimulo do usuário (p.ex., apertando Tecla Quente) o HS se prepara para comutar contextos.

Na etapa 3120, o HDD (controlador e subsistema de drive de disco rigido) é trazido para um estado inerte e de 25 dados descartados em preparação para uma mudança de estado de sistema.

Na etapa 3130, o HS escreve para um registro ACPI (p.ex., PM1_CNT) que é usado em OSs desenvolvidos anteriormente para solicitar uma comutação para modo S3 de Sistema 30 ACPI. Os modos de ACPI são bem conhecidos na técnica.

Na etapa 3140, a escrita para PM1_CNT é interceptada pelo OSM tendo sido enganchada pelo OSM durante a inicialização.

Na etapa 3150, o HS guarda os Vetores para Despertar e registros e outras informações tais como PIC e definição do Timer para voltar mais tarde para o estado ativo (estado SO no contexto HS) . Estes são mantidos separadamente das definições de PIC etc. armazenadas antes do HS ser carregado.

Na etapa 3160, o serviço GetBootOS do OSM seleciona o próximo OS a ser carregado (isto é, um OS não HS). Em uma configuração da invenção, este OS não HS é o OS Microsoft® Vista®.

Na etapa 3170, o controle é retornado para o OSM via a Int 19 (Interrupção 19), a qual novamente invoca o serviço GetBootOS do OSM para selecionar um OS para carregamento.

Na etapa 3180, as definições, etc., que foram armazenadas antes do HS ser carregado são reinstaladas.

Na etapa 3190, o OSM lança a carga do segundo OS (Vista® na configuração exemplar). 0 segundo OS não está ciente do espaço especial reservado para o HS pela rotina de serviço E820 no BIOS então ele se confinará a áreas ARM e portanto não sobrescreverá o HS na memória fisica sendo carregado em uma porção inteiramente separada da memória fisica do sistema. Isto tipicamente não criará um problema de recursos uma vez que os requisitos de memória do HS são modestos (tipicamente 256 Mebibytes) se comparados com um segundo OS tipico (provavelmente excedendo 1,5 Gibitytes ou mais).

Isto completa o carregamento dos dois OSs e traz o sistema pronto para comutar entre eles responsivo a pedido do usuário (tal como pressionamentos de Tecla Quente) ou responsivo a outros estimulos programáticos. Será aparente para um programador de experiência ordinária na técnica como estender o procedimento acima para prover comutação para e a partir de entre OSs. Entretanto, distinção deve ser feita entre um desejo em deixar o segundo OS e retornar para o primeiro OS e um desejo em entrar no estado inerte uma vez que ambos envolvem capturar uma escrita enganchada para os registros ACPI. Geralmente, isto pode ser resolvido programaticamente com o OS com o OSM capturando qualquer critério que seja usado para distinguir os dois casos.

Com relação à figura 5, instruções de computador a serem incorporadas em um dispositivo eletrônico 10 podem ser distribuídas como firmware [programa residente de inicialização] fabricado e/ou produtos de computador de 5 software 510 usando uma variedade de possíveis midias 530 tendo as instruções gravadas nelas tais como usando um gravador de armazenagem 520. Frequentemente em produtos tão complexos como aqueles que instalam a invenção, mais que um meio podem ser usados, tanto na distribuição 10 quanto na fabricação de relevante produto. Somente um meio é mostrado na figura 5 para clareza mas mais que um meio podem ser usados e um único produto computador pode ser dividido entre uma pluralidade de midias.

A figura 6 mostra como uma configuração exemplar da 15 invenção pode ser codificada, transmitida, recebida e decodificada usando ondas eletromagnéticas.

Com relação à figura 6, adicionalmente, e especialmente desde o aumento da utilização da Internet, os produtos computadores 610 podem ser distribuídos codificando-os em 20 sinais modulados como uma onda. As formas de onda resultantes podem então ser transmitidas por um transmissor 640, propagadas como ondas portadoras eletromagnéticas moduladas tangíveis 650 e recebidas por um receptor 660. Com a recepção elas podem ser desmoduladas e os sinais decodificados em uma versão ou cópia adicional do produto computador 611 em uma memória ou outro dispositivo de armazenagem que seja parte de um segundo dispositivo eletrônico 11 e tipicamente similar em natureza ao dispositivo eletrônico 10.

Outras topologias e/ou dispositivo também podem ser usados para construir configurações alternativas da invenção. As configurações descritas acima são exemplares ao invés de limitantes e os limites da invenção devem ser determinados a partir das reivindicações. Embora 35 configurações preferidas da presente invenção tenham sido descritas em detalhes aqui acima, deve ficar claramente entendido que muitas variações e/ou modificações dos conceitos inventivos básicos ensinados aqui podem aparecer àqueles experientes na presente técnica e ainda cairão dentro do espirito e escopo da presente invenção, como definidos nas reivindicações anexas.

Claims (17)

1. Método para operar um computador, caracterizado pelo fato de compreender: carregar um primeiro Sistema Operacional (OS) em uma primeira partição de uma memória de sistema; carregar um segundo OS em uma segunda partição da memória do sistema; em resposta a uma solicitação de comutar a partir do segundo OS para o primeiro OS, executar uma instrução trazida a partir do segundo OS para solicitar uma mudança de Estado de Sistema de Interface de Energia e Configuração Avançada (ACPI), em que a solicitação para mudar o Estado de Sistema de ACPI compreende uma escrita em um registro predeterminado ; capturar, por um módulo, a escrita no registro predeterminado; após a captura, o módulo guarda um estado de hardware para um contexto do segundo OS; e após guardar, o módulo restaura um estado de hardware guardado para um contexto do primeiro OS e transfere o controle para o primeiro OS.

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de: o Estado de Sistema ACPI ser Estado S3 de Sistema ACPI.

3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de: o carregamento do segundo OS ser executado por um módulo compreendendo um carregador de boot, em que o carregamento do segundo OS é executado responsive a uma sequência de instruções de pedido ACPI no primeiro OS.

4. Método, de acordo com a reivindicação 3, caracterizado pelo fato de: o módulo invocar um serviço de Sistema Básico de Entrada— Saida (BIOS) para selecionar um próximo OS a ser carregado pelo carregador de boot.

5. Método, de acordo com a reivindicação 1, caracterizado pelo fato de: a primeira partição ser de um tipo Faixa de Endereço Reservada (ARR) e a segunda partição ser de um tipo Memória de Faixa de Endereço (ARM).

6. Método, de acordo com a reivindicação 1, caracterizado pelo fato de compreender adicionalmente: responsivo a executar uma instrução trazida da primeira partição, restaurar o estado de hardware guardado para o contexto do segundo OS; e transferir o controle para o segundo OS.

7. Método, de acordo com reivindicação 6, caracterizado pelo fato de compreender adicionalmente: trocar página de uma porção da segunda partição da memória do sistema para um disco; acrescentar a porção trocada da memória do sistema a uma pilha de software controlada pelo primeiro OS; e reinstalar a porção trocada da memória do sistema para a primeira partição após a execução de uma instrução trazida da primeira partição e antes de transferir o controle para o segundo OS.

8. Método, de acordo com reivindicação 1, caracterizado pelo fato de a solicitação de mudança do Estado de Sistema ACPI colocar o segundo OS em um estado de potência reduzida.

9. Meio não transitório lido por computador tendo instruções codificadas nele, caracterizado pelo fato de que as instruções, quando executadas por pelo menos um processador, fazem com que o citado pelo menos um processador: carregue um primeiro Sistema Operacional (OS) em uma primeira partição de uma memória de sistema; carregue um segundo OS em uma segunda partição da memória de sistema; em resposta a uma solicitação para comutar a partir do segundo OS para o primeiro OS, executar uma instrução trazida do segundo OS para solicitar uma mudança de um Estado de Sistema de Interface de Energia e Configuração Avançada (ACPI), em que a solicitação para mudar o Estado de Sistema de ACPI compreende uma escrita em um registro predeterminado; fazer com que um módulo capture a escrita no registro predeterminado ; após a captura, fazer com que o módulo guarde um estado de hardware para um contexto do segundo OS; e após guardar, fazer com que o módulo restaure um estado de hardware guardado para um contexto do primeiro OS e transfira o controle para o primeiro OS.

10. Meio não transitório lido por computador, de acordo com a reivindicação 9, caracterizado pelo fato de: a primeira e segunda partições serem mutuamente exclusivas; e o carregamento do segundo OS ser executado pelo módulo e ser executado responsivo a uma sequência de instruções de pedido de ACPI no primeiro OS.

11. Meio não transitório lido por computador, de acordo com a reivindicação 9, caracterizado pelo fato de: o carregamento do segundo OS ser executado pelo módulo e ser executado responsivo a uma sequência de instruções de pedido de ACPI no primeiro OS; e o módulo invocar um serviço de Sistema Básico de Entrada— Saida (BIOS) para selecionar um próximo OS a ser carregado.

12. Meio não transitório lido por computador, de acordo com a reivindicação 9, caracterizado pelo fato de a solicitação de mudança do Estado de Sistema ACPI colocar o segundo OS em um estado de potência reduzida.

13. Dispositivo eletrônico, caracterizado pelo fato de compreender: um controlador; e uma primeira memória de sistema tendo instruções codificadas nela, as instruções quando executadas pelo controlador fazem com que o citado controlador: carregue um primeiro Sistema Operacional (OS) em uma primeira partição da primeira memória de sistema ou de uma segunda memória de sistema; carregue um segundo OS em uma segunda partição da primeira memória de sistema ou da segunda memória de sistema; em resposta a uma solicitação para comutar a partir do segundo OS para o primeiro OS, executar uma instrução trazida do segundo OS para solicitar uma mudança de um Estado de Sistema de Interface de Energia e Configuração Avançada (ACPI), em que a solicitação para mudar o Estado de Sistema de ACPI compreende uma escrita em um registro predeterminado ; fazer com que um módulo capture a escrita no registro predeterminado ; após a captura, fazer com que o módulo guarde um estado de hardware para um contexto do segundo OS; e após guardar, fazer com que o módulo restaure um estado de hardware guardado para um contexto do primeiro OS e transfira o controle para o primeiro OS.

14. Dispositivo eletrônico, de acordo com a reivindicação 13, caracterizado pelo fato de: a primeira segunda partições serem mutuamente exclusivas.

15. Dispositivo eletrônico, de acordo com a reivindicação 13, caracterizado pelo fato de: o carregamento do segundo OS ser executado pelo módulo e ser executado responsive a uma sequência de instruções de pedido de ACPI no primeiro OS.

16. Dispositivo eletrônico, de acordo com a reivindicação 13, caracterizado pelo fato de: o módulo ser um módulo de direcionamento de OS (OSM).

17. Dispositivo eletrônico, de acordo com a reivindicação 13, caracterizado pelo fato de a solicitação de mudança do Estado de Sistema ACPI colocar o segundo OS em um estado de potência reduzida.

Images