Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Asignación de dirección

Resumen

Introducción:

Debido a que hay una serie de interdependencias entre interfaces y debido a que diferentes configuraciones de dispositivos pueden requerir diferentes direcciones TCP / IP y asignaciones de rutas, se consideró esencial que la lógica para controlar la dirección IP y la asignación de rutas se consolidara en un solo módulo. WARM tiene el propósito de agregar y eliminar correctamente las direcciones TCP / IP y las interfaces IP relacionadas con Rutas a tejido a medida que esas interfaces pasan de activo <-> inactivo.

WARM está diseñado para configurarse en tiempo de compilación a través de WarmProjectConfig.hy WarmConfig.h . WarmProjectConfig.h debe reflejar con precisión las características compatibles del dispositivo en el que se ejecutará WARM.

WARM es un módulo portátil que limita su dependencia de cómo se configuran una pila TCP / IP y una interfaz de subprocesos. Para este propósito, WARM se basa en un conjunto de API de plataforma que debe implementar el integrador de plataforma. Además, el integrador de la plataforma es responsable de realizar las diversas llamadas a la API nl :: Warm desde los puntos de ejecución apropiados dentro de la base del código de la plataforma.

Teoría de operación:

La base del código de la plataforma llamará a las API nl :: Warm para anunciar un cambio de estado para las funciones relacionadas, como la interfaz WiFi y la interfaz Thread. Una llamada a cualquiera de estas API nl :: Warm puede resultar en una llamada de WARM a Platform :: RequestInvokeActions (). Platform :: RequestInvokeActions () debe implementarse para realizar las operaciones necesarias que llamarán a Warm :: InvokeActions () . Este proceso a primera vista puede parecer innecesariamente indirecto. ¿Por qué WARM no llamaría directamente a InvokeActions? La respuesta a esa pregunta es permitir que cualquier tarea en un sistema multitarea llame a las API nl :: Warm State Change y proporcionar un mecanismo para que solo una tarea específica llame a las API Platform ::. Después de tener en cuenta los requisitos de la plataforma, el integrador de la plataforma puede optar por implementar Platform :: RequestInvokeActions () para que publique un evento en la tarea adecuada que reaccionará llamando a Warm :: InvokeActions () . Si, para una plataforma determinada, se decide que no existen tales preocupaciones de multitarea, Platform :: RequestInvokeActions () se puede implementar para llamar a Warm :: InvokeActions () directamente.

Cuando se llama a Warm :: InvokeActions (), la lógica WARM examinará el estado actual del sistema y realizará las llamadas Platform :: API necesarias para alinear la dirección y el estado de enrutamiento con el estado del sistema y la configuración. Estas llamadas se realizan en un orden predefinido y si alguna de estas API devuelve kPlatformResultInProgress, la ejecución de la lista ordenada se suspenderá y finalizará. Además, cuando una de estas API devuelve kPlatformResultInProgress, se interpreta que la operación se completará de forma asincrónica y que la lógica WARM debe esperar a que se complete la operación. Una vez completada la operación, el código de la plataforma debe llamar a Warm :: ReportActionComplete () , pasando un resultado de kPlatformResultSuccess o kPlatformResultFailure. Al recibir esta llamada, la lógica WARM volverá a llamar a Platform :: RequestInvokeActions () para reiniciar la ejecución de la lista de acciones ordenadas.

De esta manera, WARM no requiere su propia tarea, sino que puede confiar en otra tarea para llamar a Warm según corresponda. Además, cualquier tarea puede llamar a una o más de las API de cambio de estado del sistema, lo que simplifica la integración.