sábado, 27 de marzo de 2010

Entrevista con: Aicom (ACPI)

 

Microphone-Disabled-icon Con Aicom continuamos la saga de entrevistas que empezamos hace unas semanas con Mjmartin.

Aicom es el encargado de poner a punto nuestro Network Stack, pero desde hace algún tiempo (junto a Encoded) se han puesto a trastear con el ACPI.

¿Pero qué es esto del ACPI?¿Tiene algo que ver con el Network?¿Qué mejora esto del ACPI?

Como siempre, todo traducido al castellano…pero con el original en inglés para comparar :)

 

Veo a aicom por el canal, me tienen intrigados sus últimos commits respecto a una cosa llamada ACPI. He buscado información de ACPI en Google y, la verdad, lo que he encontrado es poquito y con sifón.

Pregunta: Hola aicom, ¿puedo robarte 3 minutos?(jeje…3..si el pobre supiera)

Aicom: Por supuesto (sure)

Pregunta: Avísame cuando estés preparado

Aicom: Preparado

Pregunta: Comencemos por lo fácil, ¿Qué es esta cosa del ACPI?

Aicom: ACPI permite controlar al Sistema Operativo el uso de la energía de los dispositivos que tenemos en un ordenador. Además enumera otros dispositivos y se lo comunica al Sistema Operativo.Y de paso controla el estado de energía del Sistema. Hace más cosas, pero esta es la parte mas entendible. (ACPI allows the OS to control the power usage of devices on the computer, it also enumerates other devices and reports them to the OS and it controls the system power state also it does more but that's most of the understandable stuff )

Un momento.(Mis neuronas trabajan para asimilar todo). ACPI se encarga  de gestionar la energía de los dispositivos,si antes no teníamos el ACPI, ¿quién se encargaba de los dispositivos?

Pregunta: Entonces…¿cómo estaba gestionando ReactOS el uso de la energía antes de ACPI?

Aicom: No lo hacía. Todos los dispositivos estaban a potencia total durante todo el tiempo y el Sistema no podía apagarse(It wasn´t.All devices ran at full power at all times, and the system could not shutdown)

¿Que el sistema no podía apagarse?Yo he apagado ReactOS sin problemas…Apunto esta duda para soltársela después…Sigamos con eso de “plena potencia”.

Pregunta: ¿Es malo funcionar a Plena Potencia?

Aicom: No es demasiado malo para Ordenadores de escritorio, pero para Portátiles es bastante peor. Correr a plena potencia es más rápido pero consume más energía y provoca más calor, así que mata antes la batería en los portátiles.  Usando ACPI se usa menos potencia (algunas veces),aunque reduce el rendimiento ligeramente.Digo “algunas veces” porque ACPI responde a la demanda del sistema.Por ejemplo, si usas el procesador muy intensivamente, Acpi no te va a ayudar.

(it isn't that bad for desktops, but for laptops it is much worse. Running at full power is faster but it uses more power and makes more heat, so it will kill Battery sooner in the Laptops. Using acpi, uses less power (sometimes), but it reduces performance very slightly. I say sometimes because acpi responds to the system's demands. If you are using the processor very intensely, acpi is not going to help you)

Pregunta: ¿Dónde se nota más los beneficios del ACPI?

Aicom: ACPI es una gran ayuda cuando el ordenador está en modo Standby.

(Acpi is a big help is when the computer is in standby mode. )

En modo Standby ACPI se reduce la energía necesaria por el ordenador mientras que el modo actual no-ACPI lo mantendría a plena potencia.

Aicom: …de hecho,sin ACPI, un ordenador no se puede poner en modo StandBy.

(In fact, without ACPI, a computer cannot go into standby mode)

Pregunta: ¿Y como funciona el ACPI?

Aicom: El Power Manager en Ntoskrnl envía a ACPI un comando (específicamente la IRP es IRP_MN_SET_POWER)el cual le indica como cambiar el estado de energía del Dispositivo.

(The power manager in ntoskrnl sends ACPI a command (if you want specifics, the IRP is IRP_MN_SET_POWER) which instructs it to change the power state of a device)

Pregunta: Entonces, ¿Tuviste que reescribir el Power Manager?¿O estaba listo para ser usado?(Ingenuo de mí)

Aicom: El Power Manager es bastante incompleto.El único comando que manda a ACPI es la transición de Apagado.

 

Así pues no existe modo Standby,por ahora, en ReactOS

Pregunta: ¿Vas a trabajar entonces en el Power Manager?

Aicom: Probablemente (I might)

La pregunta que he guardado en el tintero me aporrea constantemente. Es hora de soltársela que luego es tarde :)

Pregunta: Antes dijiste que el “Sistema no puede apagarse”.¿Qué querías decir con eso?

Aicom: El sistema no puede apagarse sin ACPI porque no soportamos APM y probablemente nunca lo hagamos. Vista abandonó el soporte APM. ACPI automáticamente apaga el sistema así el Usuario no tiene que presionar el botón de encendido/apagado.

(The system can't shutdown without ACPI because we don't support APM and we probably never will. Vista dropped APM support. ACPI automatically turns the system off so the user doesn't need to push the power button)

Ey, cierto.Ahora lo recuerdo. Mi antiguo PC te avisaba que era “Seguro apagar el Sistema” y entonces presionaba el Botón de encendido y listo.Si no lo presionaba el ventilador,la pantalla,y ¿quién sabe si mas cosas?, se quedaban “encendidos”.Esto no ocurre actualmente con los ordenadores nuevos.El Sistema Operativo no solo se cierra a si mismo, sino que apaga todos los dispositivos(desde el micro hasta el Led de encendido) del ordenador.

Se me enciende una minibombilla…

Pregunta: He visto que estás trabajando en algo relativo a baterías…

Aicom: Un poco, sí..He escrito Battc (a bit, yes… I wrote battc)

Pregunta: ¿Necesitas tener implementado ACPI para dar soporte a esta implementación?

Aicom: Sí, el driver cmbatt.sys que usa la mayoría de las baterías  necesita el driver ACPI para comunicarse con la batería.

(yes, the cmbatt.sys driver that runs most batteries actually uses the ACPI driver to communicate with the battery)

Pregunta: ¿Y de donde proviene este código ACPI?¿Es un Port?¿Código propio?

Aicom: La mayoría del código proviene de la implementación de referencia de acpica.org. El resto del código expone la funcionalidad de acpica al SO.

El código dentro de la carpeta busmgr es código Linux. El código que no está en esa carpeta es código escrito por encoded y por mi.

(most of the code is from the reference implementation on acpica.org. the other stuff is code that exposes the functionality in acpica to the OS. the code inside the busmgr folder is linux code. the code that isn't in a folder is ROS code written by encoded and me)

Pregunta: Ahora pregúntate algo sobre ACPI y respóndela.

(Modo Vago ONN :3 )

Aicom: Lol. Vale.Tengo una.¿Cuáles son los principales problemas que impedían funcionar a ACPI?¿Qué te parece?

(lol. ok. I've got one. what were the main issues that prevented ACPI from working?how's that?)

Pregunta: Perfecto.Cuéntanos.

Aicom: Primero, el código que creaba el Identificador PNP para cada dispositivo estaba roto así pues no estaba creando un Identificador válido y los drivers no se instalaban. Después de que fuera arreglado este bug, tuvimos un problema con Vmware que “crasheaba”.

Seguí el problema hasta nuestro código PCI en el código OSL con la ayuda de un developer de Acpica, y arreglé un fallo flagrante en esa función (estábamos almacenando el número del Bus como número de Dispositivo)

Pero eso no arregló Vmware e hizo que QEMU dejara de funcionar!!

(first, the code that created a PNP ID for each device was broken so it wasn't creating a valid ID so drivers weren't getting installed. then after that was fixed, we had an issue with VMware crashing

I traced it back to our broken PCI config code in the OSL code with help from acpica-devel, I fixed a blatant typo in that function (we were storing the bus number as the device number) but that didn't fix the vmware problem and made qemu break)

Pregunta: Oo

Aicom:…así pues añadí algunos Debug Prints y descubrí que Vmware estaba fallando porque estaba pasando un Número de Dispositivo = 0. Asi pues añadí un chequeo para eso y Vmware boteó mas lejos. Pero crasheaba mas tarde.

(so I added some debug prints and found that vmware was crashing because it was passing a device number of 0, so then I added a check for that and vmware booted further. but it still crashed later)

Pregunta: ¿Y qemu seguía crasheando?

Aicom: Sí, seguía crasheando. (qemu was still breaking)

Aicom: Hice mas debugging y descubrí que estaba intentando leer fuera del área valida de PCI config, tanto en qemu como en vmware. Así pues añadí un chequeo para eso y ambas máquinas virtuales arrancaron.

(I did some more debugging and found that it was trying to read outside of the valid area for PCI config, on both qemu and vmware, so then I added a check for that and it booted on both vms)

Pero esto dio lugar a un Assert en la segunda fase de la instalación en Vmware. Pensé que estaba relacionado con un Debug Print en el PNPMGR que se quejaba de un “mal tipo de recurso” así que le di un repaso al código fuente de ACPI. Y encontré que se olvidaba de volver al comienzo de la Lista de Recursos antes de iterar por segunda vez.

(but it would hit an serial assert later in 2nd stage on vmware, I thought it might be related to a pnpmgr debug print complaining about a bad resource type so I had a look at the acpi resource code. I found that it forgot to move back to the head of the resource list before iterating a second time )

Después de arreglar esto, la advertencia del PNPMGR y el Assert de la segunda fase desaparecieron.

Entonces hice algunos testeos,y activé ACPI en el trunk.

FIN.

(after I fixed that, the pnpmgr warning and the 2nd stage assert disappeared, and then I did some testing and enabled ACPI in trunk.

THE END.)

 

Pregunta: ¿A que te vas a dedicar a partir de ahora?

Aicom: Probablemente trabaje en la evaluación ACPI de IOCTLs el cual permitirá funcionar el cmbatt de lassy(otro desarrollador), o podría trabajar en el Power MANAGER y así el driver ACPI puede ser usado mejor.

(I might work on the ACPI evaluation IOCTLs which would allow lassy's cmbatt to work or I could work on the power manager so the acpi driver could be used better)

Además he mandado un par de fixes para bugs en el PNPMGR que eran molestos. Estábamos usando el nombre del identificador de servicio que era “VGA” para el driver VGA como si fuera el nombre del fichero, en vez del nombre del fichero real almacenado en ImagePath que era “VGAMP.sys”.Así pues si alguien podría estar buscando VGA.SYS cuando el driver realmente es VGAMP.SYS.

(I did commit a couple of pnpmgr patches that were annoying. we were using the name of the service key which was "VGA" for the VGA driver as the file name instead of the actual file name in the ImagePath value which was "VGAMP.SYS". So somebody might go looking for VGA.SYS when the driver was really VGAMP.SYS)

El otro parche del PNPMGR no es muy interesante. Nadie ve sus efectos excepto el mensaje “Dispositivo está usando NULL driver” en el debuglog en el arranque. Lo muestra porque el PNPMGR encuentra que un INF fue instalado por un dispositivo pero que no ha instalado un Driver. Esto aparece para dispositivos de sistemas que no necesitan un driver, como el Timer del Sistema, Ventilador ACPI, Zona Termal,etc..

Solo mira en el Manager de Dispositivos aquellos dispositivos que se muestran pero que no tienen un fichero driver asociado.Todos esos dispositivos aparecerán en uno de estos mensajes” NULL Driver”.

(there is another patch for pnpmgr but it isn't very interesting. nobody sees any effects except the "Device is using NULL driver" message in the debug log on start up. It shows up because the pnpmgr finds that an INF was installed for a device but it didn't install a driver. it appears for system devices that don't need a driver, such as the system timer, acpi fan, thermal zone, etc.

Just look in device manager for devices that show up but don't have a driver file associated. All of those devices will appear in one of those NULL driver messages)

 

***********************

Y hasta aqui la entrevista a Aicom sobre ACPI, y de paso sobre sus futuros planes que lejos andan del Networking :)

Hasta la próxima entrevista :)

8 comentarios:

  1. Ha sido un verdadero placer leer esta entrevista. Gracias por este magnífico trabajo (también a los desarrolladores por prestarse a ser entrevistados).

    En verdad es una pena no tener una versión de estas entrevistas en la página oficial de ReactOS. Espero que alguien más (con un buen nivel de inglés y algo de tiempo) se pudiese encargar de ello.

    Un saludo.

    PD: ¿A por quién iréis ahora? (si se puede saber) ;)

    ResponderEliminar
  2. Raijinzrael (Hyoenmadan)28 de marzo de 2010, 4:10

    Fabuloso:

    Jejeje... como dijo Aicom, ACPI es mas que solo la administracion de energia, es toda una infraesctructura para el control de hardware por el sistema operativo, y nesesario para la Infraestructura de los Drivers WDM de Windows...

    Existen en la actualidad 2 implementaciones de las norma, 1 es de Intel, puesta a dispocision por medio de ACPICA.org y la otra es de Microsoft...

    Realmente se requiere de un enorme trabajo tener una implementacion ACPI funcionando al 100%, como anectdota, la implementacion de microsoft no estuvo completa y funcional sino hasta el SP3 de Windows 2000, antes de eso tenia muchos errores que provocaban BSOD sin previo aviso, y mejor ni mencionar la de Windows 98...

    Realmente le deseo buena suerte a Aicom, y que su nuevo proyecto tenga exito.

    ResponderEliminar
  3. que interesante, una duda, hasta antes de la ultima version que instale en virtualbox (bootcd-46353-dbg.iso) aparecia el mensaje "ya puede apagar su equipo con seguridad" (o algo asi, ahora en esta version al momento de apagar reactos desde dentro del sistema ya no veo este mensaje y se cierra la ventana que habia abierto virtualbox para reactos, es este el apagado al que se refieren?, entonces en hardware real ya no vamos a ver entonces el logo de reactos y el mensaje de que ya podemos apagar el equipo?, gracias de antemano por la aclaración.

    ResponderEliminar
  4. Hola Angelus,

    En primer lugar, muchas gracias ern nombre del equipo de El Blog de ReactOS. Creemos que es importante conocer de primera mano los entresijos del sistema, asi que, ¿qué mejor que los propios desarrolladores para explicarlas?

    En segundo lugar, en realidad sí existen entrevistas a los desarrolladores, lo que ocurre es que están ocultas por el sitio web, y a medio traducir (mea culpa).

    ¿A por quién iremos? Bueno, no he sido yo personalmente el que ha realizado las entrevistas, pero supongo que ni el propio Vicmarcal sabe a por quién irá... tendremos que esperar...

    ResponderEliminar
  5. HOla manuel,
    Una respuesta ràpida a tu pregunta: Sí, este es el apagado al que nos referimos. Mucho mejor y más actual que el anterior, ¿verdad? ;)

    ResponderEliminar
  6. la verdad si, aunque tambien me gusto que se mostrara el logo de reactos diciendo que ya se puede apagar el equipo, este logo se mostrara en equipos viejitos que aun se tenian que apagar a mano?, saludos.

    ResponderEliminar
  7. Magnífica entrevista y gran trabajo de los desarrolladores de ReactOS. Ojalá tuviese un poco más de tiempo para colaborar con este ambicioso proyecto.
    Creo que es muy importante que haya blogs como este que publiquen entrevistas e información sobre ReactOS, a veces los desarrolladores nos metemos en nuestro mundo de programación y no tenemos tiempo para informar a la comunidad de nuestros progresos.

    ResponderEliminar
  8. Manuel,
    Desde luego, aquellos equipos que no soporten ACPI tendrán que ser apagados a mano, y por lo tanto, se les mostrará la pantalla de apagado

    Em los equipos que sí soporten ACPI, no se verá dicha pantalla.

    ResponderEliminar