man(1) pages have been added to the devwsys-prev repository. Html versions are available in the wiki of the project at bitbucket. The new manual pages are:
Mostrando entradas con la etiqueta devwsys. Mostrar todas las entradas
Mostrando entradas con la etiqueta devwsys. Mostrar todas las entradas
domingo, 21 de agosto de 2011
Wctl: a killer service
In Plan 9, rio(1) does not only manage windows. In fact, it is also a process manager. We create a new window to make a new process. When we want to finish it, we delete that window. Devwsys, on the other hand, is running on a host system, and therefore it cannot create or delete processes.
What we need to create processes is a service in the hosted Plan 9 system which mounts devwsys and runs the given command. This is what the wctl script does, announcing a file descriptor in /srv and reading new commands, in the format of rio's wctl service.
A more interesting problem is how to finish a process when that window is deleted. Rio reads a pid as part of the attach specifier. When the user asks to delete a window (with the mouse or a wctl message) a different thread sends a note to the process, waits a bit, kill it and, only then, deletes the window.
Devwsys cannot create or finish processes, so it needs a method to say it to wctl. The IPC mechanism used is, of course, 9P. The pid in the attach specifier is read by devwsys and stored. When the user wants to close a window (with a wctl message or a request from the X window manager), a read of the file /kill will return that pid. If we read the file before the window has been asked for deletion it will just block. That way, we can wait for a window to be deleted. If there is nobody blocked reading /kill, the window is immediately deleted.
The "killer" process has access to the kill file mounting the root of the devwsys file system, using the attach specifier "/". If this specifier is given to mount, a new window will not be created. Instead, we will have access to a file tree containing the kill file and the wsys and draw directories (where the draw directory does not contain a new file, because there is no associated window).
The first thing the wctl script does is mounting the root fs. Each time a pid is read from the kill file, killproc will send a kill note to the process, wait 0.2 seconds, and then will send kill to the ctl file of the process. Once the process finishes all the references to its window file system are lost, and the window is destroyed by devwsys (in theory, acme for example is not so simple).
What we need to create processes is a service in the hosted Plan 9 system which mounts devwsys and runs the given command. This is what the wctl script does, announcing a file descriptor in /srv and reading new commands, in the format of rio's wctl service.
A more interesting problem is how to finish a process when that window is deleted. Rio reads a pid as part of the attach specifier. When the user asks to delete a window (with the mouse or a wctl message) a different thread sends a note to the process, waits a bit, kill it and, only then, deletes the window.
Devwsys cannot create or finish processes, so it needs a method to say it to wctl. The IPC mechanism used is, of course, 9P. The pid in the attach specifier is read by devwsys and stored. When the user wants to close a window (with a wctl message or a request from the X window manager), a read of the file /kill will return that pid. If we read the file before the window has been asked for deletion it will just block. That way, we can wait for a window to be deleted. If there is nobody blocked reading /kill, the window is immediately deleted.
The "killer" process has access to the kill file mounting the root of the devwsys file system, using the attach specifier "/". If this specifier is given to mount, a new window will not be created. Instead, we will have access to a file tree containing the kill file and the wsys and draw directories (where the draw directory does not contain a new file, because there is no associated window).
The first thing the wctl script does is mounting the root fs. Each time a pid is read from the kill file, killproc will send a kill note to the process, wait 0.2 seconds, and then will send kill to the ctl file of the process. Once the process finishes all the references to its window file system are lost, and the window is destroyed by devwsys (in theory, acme for example is not so simple).
lunes, 4 de julio de 2011
Drawing cats
There are still many thing to be done: resizes are not working, programs segfault when the right mouse button is pressed, anything using fonts will fail and memory is being leaked all over the place. But we can draw cats, everything should get easier now.
domingo, 26 de junio de 2011
Bye bye drawfcall
Devwsys no longer uses an internal Wsysmsg representation. As a matter of fact, drawfcall support has been completely removed. Getting rid of this level of indirection devwsys can become a simpler program. It will only support one interface: a 9p file system.
The drawfcall infrastructure in p9p's devdraw has been verey helpful to get started, but it was starting to get in the way. We want to run devwsys in different environments, any unnecessary complication should be avoided. Mixing the draw and wsys file systems is complex enough already.
The drawfcall infrastructure in p9p's devdraw has been verey helpful to get started, but it was starting to get in the way. We want to run devwsys in different environments, any unnecessary complication should be avoided. Mixing the draw and wsys file systems is complex enough already.
lunes, 20 de junio de 2011
Preview release of devwsys
A preliminary version of devwsys is publicly available:
Running devwsys a 9p server is started (by default in /tmp/ns.$USER.$DISPLAY/wsys). When mounted, a new window is created in the X display, and the following files can be accessed:
Devwsys still needs much more work, but is progressing. There are still many aspects to improve, and more files need to be implemented for rio(4) compatibility. The drawing device is the top priority now.This version does not have a functional drawing device yet, but can be used to create windows and read input events. Libixp and mk are the only external dependencies required to build. The Inferno drawing libraries are included in the repo.
Running devwsys a 9p server is started (by default in /tmp/ns.$USER.$DISPLAY/wsys). When mounted, a new window is created in the X display, and the following files can be accessed:
- winid: an unique window id.
- label: read or write it to get or set the label of the window.
- mouse: to get mouse and resize events.
- cons: to get keyboard events. Alt is the compose key.
- consctl is only a dummy file. cons is always on rawon mode.
- wsys/n/ gives access to the file system of all the open windows.
- draw/ and draw/new are not functional yet.
jueves, 16 de junio de 2011
Devwsys
Devwsys will be a new program. Its main components will be some libraries from Inferno (libdraw, libmemdraw, libmemlayer and also lib9 and some pieces from other libraries), libixp and a considerable amount of p9p's devdraw code, as well as from the Inferno kernel devices.
The objective of devwsys is simple in its conception: serve a 9p file system similar to that one of rio(4), with the difference that new windows are not created in a rio instance, but in the windowing system of the host (X11). In fact, a devwsys window will be more limited than a rio window, since it will not include any text editing capabilities, they will only be graphical windows (eg. consctl will only be a dummy file, cons will always be on rawon mode).
In the future, it could be convenient to use an alternative server, for example to work with the p9p's devdraw protocol in stdin/out or to replace libixp with something else. In a similar way, although it is not part of this project, it should be possible to use other windowing systems (like OSX, Windows or, if it takes off, Wayland). In order to achieve this goal, devwsys will use the internal message representation of devdraw. 9p messages will be converted into Wsysmsg's and a runmsg function will take care of interpreting this message and perform the relevant (window system agnostic) function calls. If we want to replace libixp we will only need to build the corresponding Wsysmsg from any form the requests take and supply a reply function, and if we want to support other windowing system only the functions used by runmsg will have to be implemented.
Of course, we are not there yet, but are getting a bit closer with every line of code. A very preliminary version of devwsys will be made public at the end of this week, with the basic functionality to create new windows and some support for input events (mouse and cons files), but not drawing yet.
The objective of devwsys is simple in its conception: serve a 9p file system similar to that one of rio(4), with the difference that new windows are not created in a rio instance, but in the windowing system of the host (X11). In fact, a devwsys window will be more limited than a rio window, since it will not include any text editing capabilities, they will only be graphical windows (eg. consctl will only be a dummy file, cons will always be on rawon mode).
In the future, it could be convenient to use an alternative server, for example to work with the p9p's devdraw protocol in stdin/out or to replace libixp with something else. In a similar way, although it is not part of this project, it should be possible to use other windowing systems (like OSX, Windows or, if it takes off, Wayland). In order to achieve this goal, devwsys will use the internal message representation of devdraw. 9p messages will be converted into Wsysmsg's and a runmsg function will take care of interpreting this message and perform the relevant (window system agnostic) function calls. If we want to replace libixp we will only need to build the corresponding Wsysmsg from any form the requests take and supply a reply function, and if we want to support other windowing system only the functions used by runmsg will have to be implemented.
Of course, we are not there yet, but are getting a bit closer with every line of code. A very preliminary version of devwsys will be made public at the end of this week, with the basic functionality to create new windows and some support for input events (mouse and cons files), but not drawing yet.
Suscribirse a:
Entradas (Atom)