Se dispone de un dispositivo de E/S, llamado PowerDev, que permite realizar operaciones relacionadas con el sistema de apagado de un equipo empotrado. En concreto, este dispositivo ofrece las siguientes funcionalidades:

  1. Apagado del equipo a través de un pulsador del dispositivo. El equipo debe pararse de forma ordenada. Por tanto, en este caso se debe finalizar el tratamiento de todas las interrupciones que eventualmente se estuvieran tratando, matar todos los procesos y sincronizar la cache del sistema de ficheros.
  2. Hibernación del equipo a través de un pulsador del dispositivo. En este caso se salvaguarda la información necesaria en el disco del equipo. Antes de realizar esta salvaguarda de información hay que esperar a que todas las interrupciones que se estuvieran tratando finalicen. A continuación, el equipo queda sin energía.
  3. Suspensión del equipo a través de un pulsador del dispositivo. El equipo queda en modo ahorro de energía, del cual sólo puede salir si se presiona el pulsador de arranque del equipo. En esta situación, no se vuelca nada a disco. El equipo se queda bloqueado en una instrucción HALT.

Además del uso de pulsadores del dispositivo PowerDev, se dispone de tres mandatos para realizar las tres operaciones anteriores: power_off (apagado), hibernate (hibernación) y stand-by (suspensión). Tanto durante el proceso de suspensión del equipo, como en su funcionamiento normal, se puede dar el caso de que la batería del mismo se esté terminando. A tal efecto, el dispositivo proporciona un mecanismo de alarma que indicará que queda menos de un 10% de batería.

Se dispone de un módulo (driver) en GNU/Linux para la gestión del dispositivo PowerDev. Responder razonadamente a las siguientes preguntas:

1.        Analice cada uno de los escenarios que aparecen en la siguiente tabla, indicando qué eventos están ligados a los mismos y/o los tipos de procesos que debería utilizar el driver para gestionarlos. Para ello, rellene la tabla y justifique razonadamente para cada escenario la elección realizada, teniendo en cuenta aspectos tales como: evento síncrono o asíncrono, tiempo de duración de la operación a realizar, ejecución por parte del sistema operativo o por proceso de usuario, necesidad de uso de proceso de núcleo en su caso, etc.

 

EVENTOS Y

ESCENARIOS

Interrupciones

Excepciones

Llamadas al sistema

Interrupciones software

Procesos de núcleo

Procesos de usuario

Apagado (pulsador)

 

 

 

 

 

 

power_off (mandato)

 

 

 

 

 

 

Hibernación (pulsador)

 

 

 

 

 

 

hibernate (mandato)

 

 

 

 

 

 

Suspensión (pulsador)

 

 

 

 

 

 

Stand-by (mandato)

 

 

 

 

 

 

Indicador de batería baja

 

 

 

 

 

 

 

2.        Analice cuál sería el estudio que tendría que llevar a cabo para saber si existe algún problema de sincronización con el dispositivo PowerDev, tanto para el caso de un núcleo expulsivo como no expulsivo.

 

SOLUCIÓN

A.1

1.        Apagado (a través de pulsador):

Se trata de un evento asíncrono, dado que está ligado al dispositivo de E/S PowerDev. Se generará pues una interrupción hardware, que deberá ser tratada en el contexto del proceso de ejecución por el driver del dispositivo PowerDev. El tratamiento consistirá en la parada del sistema de forma ordenada. Eso es lo que por ejemplo se lleva a cabo cuando el superusuario ejecuta shutdown. Por tanto, parece lógico que sea un proceso de usuario el que se encargue de llevar a cabo las operaciones que se ejecutan en la parada del sistema. Una posibilidad es que un demonio (proceso de usuario) se encuentre bloqueado en una operación del driver a la espera de que la interrupción hardware le desbloquee y se encargue de llevar a cabo dichas operaciones. Las operaciones de parada requieren ciertas llamadas al sistema, como por ejemplo matar todos los procesos o sincronizar la cache del sistema de ficheros. Dado que todas las interrupciones que se estuvieran tratando deben terminar, en principio parecería necesario el uso de interrupciones software para posponer la ejecución de la parada del sistema. Pero dado que es un proceso de usuario el que se encarga de llevar a cabo el apagado, cuando ejecute ya habrán terminado las interrupciones. Resumiendo, este escenario requiere el uso de: interrupciones hardware, llamadas al sistema y procesos de usuario.

 

2.        power_off (mandato):

Se trata de un mandato que, por analogía con el escenario número 1, realizará las mismas operaciones que lleva a cabo el demonio descrito anteriormente. Se podría tratar de un proceso de superusuario con las mismas funcionalidades que dicho demonio. De acuerdo a lo explicado en el escenario anterior, este escenario requiere el uso de llamadas al sistema y procesos de usuario.

 

3.        Hibernación (pulsador):

Se trata de un evento asíncrono, dado que está ligado al dispositivo de E/S PowerDev. Se generará una interrupción hardware, que deberá ser tratada en el contexto del proceso de ejecución por el driver del dispositivo PowerDev. El tratamiento consistirá en la hibernación del sistema. Por analogía con el escenario 1, este proceso de hibernación se puede llevar a cabo por un proceso de usuario. Y por tanto, existirá otro demonio (proceso de usuario) que se encuentra bloqueado en una operación del driver a la espera de que esta interrupción hardware lo desbloquee para proceder a llevar a cabo las operaciones de hibernación. Estas operaciones requieren ciertas llamadas al sistema, tales como la salvaguarda de la información en el disco. Por el mismo razonamiento que en el escenario 1, en principio no se requieren interrupciones software. Del mismo modo que el escenario 1, este escenario requiere el uso de interrupciones hardware, llamadas al sistema y procesos de usuario.

 

4.        hibernate (mandato):

Se trata de un mandato que, por analogía con el escenario número 3, realizará las mismas operaciones que lleva a cabo el demonio descrito en el escenario anterior. Se podría tratar de un proceso de superusuario con las mismas funcionalidades que dicho demonio. De acuerdo a lo explicado en el escenario anterior, este escenario requiere el uso de llamadas al sistema y procesos de usuario.

 

5.        Suspensión (pulsador):

Se trata de un evento asíncrono, dado que está ligado al dispositivo de E/S PowerDev. Se generará una interrupción hardware, que deberá ser tratada en el contexto del proceso de ejecución por el driver del dispositivo PowerDev. La interrupción será de máxima prioridad, quedando inhabilitadas el resto de interrupciones. El tratamiento consiste en quedarse bloqueado en una instrucción HALT. Al ser una instrucción privilegiada, tendrá que realizarse por parte del sistema operativo. Por tanto, una posibilidad sería que en el propio tratamiento de la interrupción se realizara la suspensión del sistema. No hay que posponer ninguna funcionalidad, por lo que no se requiere el uso de interrupciones software. Por tanto, este escenario requiere el uso de interrupciones hardware.

 

6.        stand-by (mandato):

Se trata de un mandato que debe tener un efecto similar al escenario número 5. Por tanto, para conseguir que se ponga en marcha la suspensión se podría tener una llamada al sistema. Por tanto, este escenario requiere el uso de llamadas al sistema.

 

7.        Indicador de batería baja

Se trata de un evento asíncrono, generado por el dispositivo de E/S PowerDev cuando detecta que queda menos del

10% de batería. Se generará una interrupción hardware, que deberá ser tratada en el contexto del proceso de ejecución por el driver del dispositivo PowerDev. El tratamiento no se especifica en el enunciado y por tanto, dependiendo de cómo se trate dicha interrupción, será necesario utilizar mecanismos diferentes. Por tanto, este escenario al menos requiere el uso de interrupciones hardware.

 

Finalmente, hay que indicar que para los escenarios 1 y 3, se podría necesitar el uso de las interrupciones software si existen operaciones que se deben diferir al final del tratamiento de la ejecución de las interrupciones hardware.

 

A.2

 

En este apartado, se podrían dar problemas de sincronización si el código del driver maneja estructuras del sistema operativo que requieren su uso en exclusión mutua.

 

Un núcleo no expulsivo facilita considerablemente el tratamiento de los problemas de sincronización al limitar el grado de concurrencia en el sistema. El estudio que se debe llevar a cabo en este tipo de núcleo es:

·         Hay que estudiar cada parte del código de una llamada al sistema para ver si puede verse afectada por la ejecución de una rutina de interrupción. En el caso de PowerDev, habrá que analizar los posibles conflictos de las llamadas al sistema con las interrupciones del dispositivo, así como las nuevas llamadas al sistema con el resto de interrupciones del sistema. Si una determinada parte del código de la llamada se ve afectado por la rutina de interrupción de nivel N, durante ese fragmento se elevará el nivel de interrupción del procesador al valor N.

·         Se debe hacer un proceso similar con cada rutina de interrupción: se estudia su código y se comprueba si en alguna parte puede verse afectado por una interrupción de nivel superior. En caso afirmativo, se eleva el nivel de interrupción para evitar el problema de condición de carrera. En el caso de PowerDev, habrá que analizar los posibles conflictos entre las interrupciones existentes y las interrupciones del dispositivo.

 

Un núcleo expulsivo tiene mayor grado de concurrencia, lo que complica la correcta sincronización. A los problemas de sincronización ya existentes en los sistemas no expulsivos, hay que añadir los que conlleva la ejecución concurrente de llamadas, que, en principio, requeriría analizar las posibles interferencias entre todas las llamadas al sistema. En el caso de PowerDev, habría que analizar los posibles conflictos existentes entre la nueva llamada al sistema con el resto de llamadas al sistema.