ReactOS Newsletter: Newsletter 68

Newsletter 68

ARWINSS, la tercera es la vencida, tal vez
Progresos en la administración de la memoria
Soporte Ext2

Newsletter Archive

by Z98 on 2010-01-22
translated by Gabriel ilardi on 2010-01-29

top

ARWINSS, la tercera es la vencida, tal vez

Ha habido un aumento de especulaciones respecto a ARWINSS, a que sirve y que hace, a pesar de que Aleksey Bragin ha hecho varias declaraciones en mérito. Se había llegado a un punto donde algunas personas con informaciones parciales hacían afirmaciones como si las mismas fuesen ciertas cuando en realidad muchas veces eran incorrectas. ARWINSS no pretende sostituir el actual subsistema Win32. Existe como un esfuerzo paralelo para poner remedio a las limitaciones del actual subsistema Win32 aplicando un diseño distinto en vez que duplicar el de Windows NT. Además, ARWINSS se relaciona solo con el subsistema Win32, que es solo parte del proyecto y no representa el sistema operativo en su conjunto. Por ende, frases como ReactOS se 'resetea' o 'comienza nuevamente' son como mínimo exageradas. Con el paso del tiempo los aciertos o desaciertos técnicos de ARWINSS se harán evidentes mientras continuarán los trabajos en ambos, no existe nada que pueda excluir uno o el otro. De este modo damos una visión estratégica de alto nivel de ARWINSS y afortunadamente ponemos en claro que no estamos re-mezclando el proyecto y el diseño de ROS.

En cuanto a ARWINSS en sí, la implementación está basada en la arquitectura que usa actualmente Wine. Hay varias capas en Wine, la mayor parte del código re-utilizable se encuentra encima de un driver user mode que abstrae el sistema gráfico que se encuentra debajo. Hace falta un driver a parte por cada tipo de sistema gráfico en el cual se quiere utilizar Wine, actualmente existe un driver X11 llamado winex11 junto a un driver Quartz que se encuentra en fase de desarrollo. No existía un driver para el sistema gráfico Win32, hubiese sido redundante. ARWINSS sin embargo lo implementa, se llama winent y funciona como capa entre las distintas DLL de Win32 que implementa Wine y el componente del lado kernel del subsistema Win32, Win32k. Tradicionalmente tales DLL hacen llamadas a Win32k a través de syscalls, pero como hemos dicho previamente la implementación Wine se espera una capa intermedia. Además, el driver user mode solo maneja la comunicación con el sistema gráfico, ciertos servicios o recursos de las DLL que necesita Wine son provistos por wineserver. Afortunadamente, la mayor parte de las funcionalidades de wineserver habían sido implementadas en ReactOS consecuentemente Aleksey ha redirigido las llamadas que hacían las DLL a librerías y funciones de ReactOS. La presencia di winex11 en ciertos diagramas y también en el repositorio ha llevado a ciertas personas a pensar que ReactOS estaba tratando de usar X Window. Sin embargo, como ya hemos dicho antes, winex11 existía ya y ha sido simplemente arrastrado como parte de la importación inicial. Ciertamente no se usa en ReactOS y ha sido reemplazado definitivamente por el driver winent que Aleksey ha escrito. O sea que ninguno de los desarrolladores que han trabajado en ARWINSS ha tenido alguna idea respecto de X Window y la atención que se ha prestado a X11 ha sido una sorpresa visto que no tenía nada que ver con su trabajo.

Tenemos que aclarar otra cosa respecto a la diferencia entre ARWINSS y Wine en Unix. Dado que el sistema X ha estado siempre en user mode, la comunicación con el mismo requería una especie de RPC (remote procedure call) y por mucho tiempo X Window ofrecía poco para acelerar o minimizar estas llamadas. Comparándola con una syscall entre user mode y kernel mode, esta operación era más bien cara. Estos vínculos influyen negativamente en las prestaciones de Wine pero no así en ReactOS, el driver winent ejecuta simplemente llamadas de sistema en modalidad kernel Win32k.

top

Progresos en la administración de la memoria

El trabajo en el branch Cache Controller de Art Yerkes' ha visto progresos importantes durante los últimos meses, Art ha reimplementado y simplificado distintos componentes. Una de estas partes era el balanceador, que decide cuales páginas se deben escribir en el disco. Otro componente relacionado es el escritor de páginas modificado, que Art ha logrado hacer funcionar simplificando el bloqueo de los recursos hecho durante las operaciones de paging. Cuando el administrador de las páginas las debe liberar para poder hacer espacio para datos nuevos (mpw), este tratará de encontrar páginas que no hayan sido modificadas, o bien no "sucias", de este modo no debe realizar operaciones de I/O en el disco para poder liberarlas. Un modo para contribuir a ello es liberar estas páginas mientras el sistema se encuentra inactivo para minimizar el numero de páginas sucias presentes, que es exactamente lo que hace mpw. Sin embargo, previamente esto no funcionaba en ReactOS por una teoría fascinante pero muy compleja para manejar las sincronizaciones durante las operaciones de memoria.

Originariamente el código de administración de la memoria era relativamente simple en ReactOS, con el paso del tiempo se ha introducido mas código para manejar la sincronización de los recursos y de los deadlock. Un intento para administrar los recursos ha sido pageops, que representaba el estado del administrador de errores mientras procesaba una dirección específica en un proceso específico. Art non conocía a nadie que usase pageop, el concepto podría haber sido introducido por David Welch, un ex guru del kernel de ReactOS. Su implementación en ReactOS había introducido una grande cantidad de código duplicado en los administradores de errores porque tenía que monitorear que hacían y a dónde debían acceder los otros administradores de memoria. Art ha removido pageops de su branch usando un valor centinela para tener alejado el código de otros procesos de áreas sensibles hasta la notificación. Si bien este es un modo simplista para administrar el acceso compartido, es el más directo y el que se ponen en funcionamiento más fácilmente. En ReactOS el tener mas funcionalidades tiene una prioridad mayor que lo que es más adecuado según la teoría de la optimidad.

Otra modificación que ha hecho Art está relacionada con como el paginador decidía que páginas liberar y reutilizar cuando se acababa la memoria. Lo que sucedía antes era que áreas específicas de memoria terminaban por comerse unas con otras para satisfacer las solicitudes. Si el sistema necesitaba más espacio para páginas user por ejemplo, las mismas se liberaban para satisfacer la solicitud. Esto generaba problemas de performance cuando ciertas operaciones creaban paginaciones constantes liberando y ocupando páginas que habían sido apenas movidas a la memoria física. El paginador en el branch de Art es mucho más flexible y evita encontrarse en estas situaciones.

Otra modificación importante que ha hecho Art en su branch está vinculada al modo en el que se mapean las secciones y las páginas. Las secciones son otra abstracción de la memoria y están compuestas por varias páginas. Antes, el único modo para determinar a que sección pertenecía una página era controlar el espacio de direcciones en el que estaba mapeada la secciín. Sin embargo, hay situaciones en las que una secciín non estí mapeada a un espacio de direcciones, lo que crea complicaciones cuando se trata de liberarla. Art ha encontrado un modo para resolver este problema, identificando la secciín a la que pertenece una página viendo algunos bits en una de las estructuras de datos usadas en la administraciín de la memoria.

La suma de todos los trabajos efectuados ha hecho mucho más confiable el paging en ReactOS, al menos en el branch de Art. El paging es importante para manejar situaciones en las que el S.O. o bien las aplicaciones usan más memoria que la física presente. Previamente, ROS manejaba esta situación bastante mal, ya sea por la performance que por la integridad de los datos. Ahora Art logró hacer funcionar a ROS en modo seguro en sistemas con tan poca memoria como 32MB. Reducir esta cantidad sería imposible considerando las dimensiones del código y de los datos que tienen que permanecer en memoria para ayudar a hacer el paging, igualmente no hay necesidad de probar con menos memoria, porque con recursos así limitados se podría hacer funcionar solo el sistema operativo y nada más.

top

Soporte Ext2

Con el progreso logrado regulando el Controlador de la Cache, Art pudo hacer el boot y usar una partición ext2 en ROS. El instalador no tiene el soporte nativamente aún, por ello Art ha hecho el bootstrapping de ReactOS desde la partición usando grub para cargar freeldr. Además del trabajo hecho por Pierre Schweitzer en la librería de runtime del sistema de ficheros, Art tuvo solo que agregar solo pequeñeces. La cosa más imple ha sido el stubbing de oplocks, una funcionalidad a la cual se apoyan los sistemas de ficheros de red. Ningún sistema de ficheros local los usa, pero Matt Wu, el desarrollador del ext2 que Art está usando, ha sido bastante detallista siguiendo las reglas para escribir drivers de filesystem y ha hecho las llamadas para adherir a las prácticas sugeridas. Esto hace de su driver un optimo testcase. Fueron necesarias también otras dos adiciones mucho más complejas, incluídos los bloques de control de la memoria y el bloqueo del rango. Ambos están relacionados con el mapeo de bloques de filesystem a bloques de disco. Aún hacen falta algunas modificaciones de infraestructura para poder usar el trabajo de Art y Pierre. Como hemos dicho anteriormente, el instalador no soporta el uso de particiones ext2 y el bootloader podría necesitar algún que otro retoque. Sin embargo estas sirven como punto de partida para usar filesystems más avanzados en el futuro y el nuevo driver FAT en desarrollo gozará de las ventajas de todo lo que han hecho ambos. Por último, hay que notar que la mayor parte del trabajo se encuentra en branchs separados y no en el trunk, o sea que podría pasar algo de tiempo antes de que se vean efectivamente estas funcionalidades.

top