O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Atribuição de endereço

Resumo

Introdução:

Como há várias interdependências entre as interfaces e porque diferentes configurações de dispositivos podem exigir diferentes endereços TCP / IP e atribuição de rotas, foi considerado essencial que a lógica para controlar o endereço IP e a atribuição de rotas fosse consolidada em um único módulo. WARM tem o propósito de adicionar e remover endereços TCP / IP e interfaces de IP relacionadas a Rotas para tecer conforme essas interfaces passam de <-> inativas.

Quente é destinado a ser configurado em tempo de compilação através WarmProjectConfig.h e WarmConfig.h . WarmProjectConfig.h deve refletir com precisão os recursos suportados do dispositivo no qual o WARM será executado.

WARM é um módulo portátil que limita sua dependência de como uma pilha TCP / IP e uma interface de thread são configuradas. Para este propósito, WARM conta com um Conjunto de APIs de Plataforma que deve ser implementado pelo Integrador de Plataforma. Além disso, o Integrador de Plataforma é responsável por fazer as várias chamadas de API nl :: Warm a partir de pontos de execução apropriados dentro da base de código da Plataforma.

Teoria de Operação:

A base de código da plataforma chamará nl :: Warm API's para anunciar uma mudança de estado para recursos relacionados, como a interface WiFi e a interface Thread. Uma chamada para qualquer uma dessas APIs nl :: Warm pode resultar em uma chamada por WARM para Platform :: RequestInvokeActions (). Plataforma :: RequestInvokeActions () devem ser implementadas para realizar as operações necessárias que chamam quentes :: InvokeActions () . Este processo à primeira vista pode parecer desnecessariamente indireto. Por que WARM não chamaria InvokeActions diretamente? A resposta a essa pergunta é permitir que qualquer tarefa em um sistema multitarefa chame a API nl :: Warm State Change e fornecer um mecanismo para que apenas uma tarefa específica chame a API Platform ::. Depois de tomar os Requisitos de plataforma em consideração, a Plataforma Integrator podem optar por aplicar Plataforma :: RequestInvokeActions () para que ele envia um evento para a tarefa apropriada que vai reagir chamando quentes :: InvokeActions () . Se, para uma determinada plataforma, é decidido que não existem essas preocupações multi-tasking, Plataforma :: RequestInvokeActions () pode ser implementado para chamar quentes :: InvokeActions () diretamente.

Quando quentes :: InvokeActions () é chamado a lógica WARM irá examinar o estado do sistema atual e fazer todas as chamadas Platform :: API necessárias a fim de trazer o endereço e Estado de roteamento em linha com o Sistema e Estado de Configuração. Essas chamadas são feitas em uma ordem predefinida e se alguma dessas APIs retornar kPlatformResultInProgress, a execução da lista ordenada será suspensa e encerrada. Além disso, quando uma dessas APIs retorna kPlatformResultInProgress, é interpretado que a operação será concluída de forma assíncrona e que a lógica WARM deve aguardar a conclusão dessa operação. Após a conclusão da operação, o código da plataforma devem ligar Quente :: ReportActionComplete () , passando em resultado de kPlatformResultSuccess ou kPlatformResultFailure. Ao receber essa chamada, a lógica WARM chamará novamente Platform :: RequestInvokeActions () para reiniciar a execução da lista de ações ordenadas.

Dessa forma, o WARM não requer sua própria tarefa, mas pode, em vez disso, contar com outra tarefa para chamar Warm conforme apropriado. Além disso, qualquer tarefa pode chamar uma ou mais APIs de alteração do estado do sistema, simplificando a integração.