GSoC (failed) application
libxdraw
My application to GSoC2009 could not be accepted (for reasons which are not important), but there were some interest on the project and I feel quite confident to give it a try in an unofficial way during the summer. After discussing my initial proposal with the mentors, this was my last comment on the GSoC web, and I think it explains quite well the aim of this project. I would also like to give thanks to all the organizators, for their comments and support during the application process and their effort.
Following rsc advice the original proposal has been modified. The draw device has been substituted by an standalone library, and instead of the wctl device a wsys server will be written. This is the new plan:
The first stage of the project (before the mid-term evaluation) will consist on writing a new (standalone) library, libxdraw. The idea is that this library is used by plan9-like draw devices in unix to speak to Xlib. Clients (p9p, 9vx, drawterm and Inferno) will call libxdraw, so they will not have to do any direct call to Xlib. However, they will be responsible of running libxdraw routines at their own: they can run them with kproc as kernel processes (9vx, drawterm, Inferno) or as unix commands (p9p devdraw). This way, changes to the clients should be minimal and localized:
- p9p: cmd/devdraw.c
- 9vx: a/devdraw.c
- drawterm: kern/devdraw.c
- Inferno: emu/port/win-x11a.c
On a second stage, a p9p wsys program will be writen. This program will run on unix and will serve a 9P wsys file system (built on p9p libdraw and 9pserve). This server could be mounted on 9vx/drawterm to open new (x)windows. p9p wsys would not provide a $wctl service or a cons device (and arguments to new when mounting will be ignored). On the other hand, it could be mounted with 'window -m' and run rio instances (but see below). From this point there are several possible paths:
- Port p9p libdraw (drawclient) to 9P and make use of the p9p wsys service in p9p applications.
- Give a proper "terminal" to the wsys device (9term code or something that can run natively, a modified acme, whatever that provides /dev/cons).
- Write a wsys kernel device for 9vx/drawterm, so they can manipulate their own windows without relying on external (p9p) processes.
- Explore the possibilities of running different (unix) processes for every window: it could introduce some overhead, on the other side it would give some more independence, and the possibility of using unix process management, and more functionality could be moved into libxdraw.
- Compare performance between p9p and native device in 9vx/drawterm and act in consequence.
The option to follow will depend on the results of the first month studying the existant code and the first stage of development.
Note on the wsys service: As discussed before a wsys service can be mounted with the 'window -m' command. However to run the 'window' command a $wctl file is needed. It is not convenient to launch processes directly from the p9p/kernel device. Instead, a $wctl pipe capable of executing 'window' commands can be obtained with simple rc functions (it will be rewriten in C, with error checking and without the need of dealing with 9vx awk system() command, but the concept is the same):
# bad awk system() in default 9vx distribution:
# fn wctl{ while () awk '$1=="new" { $1=""; if($2=="-cd") print "cd " $3; $2=$3=""; system("window -m" $0); }' }
fn wctl{ while ()awk '$1=="new" { $1=""; if($2=="-cd") print "cd " $3; $2=$3=""; print "window -m " $0 ; exit; }'|rc }
fn serv{ srvname=$1^.^$user;$1=/srv/^$srvname;shift;srv -e $"* $srvname }
fn riot{ serv riot wctl; wctltmp=$riot; riot=$wctl; wctl=$wctltmp; wctltmp=$riot }
After setting up wctl, the only missing piece for a window system is a cons device. As a workaround, rio can be run (or rio -i window). Further work could be possible, as mentioned above.
Goals of the project:
- Minimum goals: - Xlib draw library - p9p, 9vx, drawterm and Inferno ported to libxdraw - p9p wsys
- Desirable goals: - Improvements to p9p devdraw (9P) - 9vx/drawterm wsys kernel device
- Secondary goals: - Better console device - p9p 9term as a 9P service - ...