diff options
Diffstat (limited to 'user')
33 files changed, 6007 insertions, 39 deletions
diff --git a/user/El_Dream_Machine.mdwn b/user/El_Dream_Machine.mdwn new file mode 100644 index 00000000..fe8b5a9c --- /dev/null +++ b/user/El_Dream_Machine.mdwn @@ -0,0 +1,44 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +**September 19, 2011** - Two pages of available comics about the Hurd [http://art9libre.tuxfamily.org/gaetan-01-en.php](http://art9libre.tuxfamily.org/gaetan-01-en.php) + +**September 9, 2011** - The second page is done ! For instance, it's in french. English version soon as it's possible... Follow this link [http://art9libre.tuxfamily.org/gaetan-02.php](http://art9libre.tuxfamily.org/gaetan-02.php)or have a look on the last message. + +**May 19, 2011** - Very difficult to do my comic on the Hurd I encountered problems of inspiration... I missed the second page but I started again [http://art9libre.tuxfamily.org/gaetan-02.php](http://art9libre.tuxfamily.org/gaetan-02.php) +I project to share the scenario (CC-BY-SA/Licence Art Libre). + +**January 13, 2011** - My story comics on the Hurd continues. I think I can introduce you to page 2 in a month. + +**January 11, 2011** - The goal was to install the Hurd in VirtualBox... +It happened on january,7 2011, a very nice day... Thanks to [http://www.paranoiaque.fr](http://www.paranoiaque.fr) for [the *Hurd.vdi* machine.](http://www.paranoiaque.fr/Hurd.vdi.tar.lzma) + +[A testimony](http://www.sites.google.com/site/hurdexperiences/en-hurd-vdi-tar-lzma) of this install and a video capture [Hurd operating.](http://www.dailymotion.com/video/xgl3nr_hurd-screenscat-ffmpeg-01_webcam) + +**October 14, 2010** - Here's the [french version.](http://art9libre.tuxfamily.org/gaetan-01.php) + +**October 13, 2010** - Page 1 out ! The beginning of the [the comics is here :](http://art9libre.tuxfamily.org/gaetan-01-en.php) +Hope it will pleased for you. + +**October 3, 2010** - I just try to become an end user of The Hurd. In 2004, I was able to install K9 on an old computer. +These times, my goal is to install it on my laptop (maybe with crosshurd or with a lzma image for virtualbox, or any other way...) + +Also, I'm currently working on a comics'The Call Of The Hurd'. It's free licensed cc-by-sa/Copyleft Art Libre. +1st page will be done before the end of the year I think (I look for good quality). + + + + + + + + + + diff --git a/user/El_Dream_Machine/discussion.mdwn b/user/El_Dream_Machine/discussion.mdwn new file mode 100644 index 00000000..e4ae858b --- /dev/null +++ b/user/El_Dream_Machine/discussion.mdwn @@ -0,0 +1,10 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] +J'espère avoir l'énergie de constituer un scénario modifiable sur un wiki par exemple... diff --git a/user/Erkan-Yilmaz.mdwn b/user/Erkan-Yilmaz.mdwn new file mode 100644 index 00000000..aea4e7ff --- /dev/null +++ b/user/Erkan-Yilmaz.mdwn @@ -0,0 +1 @@ +see <http://wiki.archhurd.org/wiki/User:Erkan_Yilmaz> diff --git a/user/Etenil.mdwn b/user/Etenil.mdwn new file mode 100644 index 00000000..a1a3373b --- /dev/null +++ b/user/Etenil.mdwn @@ -0,0 +1,40 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!toc]] + +## Current task + +Implement clustered paging in GNU Mach + +- - - + +## What the problem is +In Mach, memory access is ensured by the VM, an abstraction in the kernel. The VM is mapped by pages, which size is arbitrary and defined based on hardware specs. A single block of memory can then span over many pages, i.e. a file on a file system can represent a lot of pages. + +When a process attempts to access pages that don't reside in the physical memory (RAM), the MMU detects this and triggers a page fault. Page faults are then handled and the kernel calls down the process associated with the memory pages on a *one by one basis*. + +This is where the problem lies. Hard disks are inherently efficient at sequentially writing large chunks of data whereas they cope badly with random access, plus the kernel wastes time writing/reading a page and handling the next page. All of these make for slow I/O in Mach. + +## Solutions +There are a couple of ways I could think of to solve this problem. Pages could be enlarged, but that would cause a lot more problems. Or pages must be handled by groups instead of one by one. This means the changes will also need to be applied in the way user-space processes talk to Mach. + +## What's already been done +[[user/KAM]] has already made a patch that provides basic page clustering. I have yet to understand it completely, but there are troubling changes in the patch, most notably the removal of continuations in *vm_fault* and *vm_fault_page*. + +So far, what I can tell is that KAM seems to have modified the memory objects in Mach so that they handle clusters of pages. + +## What I intend to do +Starting from KAM's work, I'll try and at least proxy the current behaviour in the kernel so as to keep backwards compatibility, at least until all user-space processes are converted (maybe some sort of deprecation warning would help porting). I'll also need to modify ext2fs to make it use the clustered paging feature, hopefully it'll improve performance quite a bit. + +## Problems +As *braunr* and *antrik* pointed out on IRC, I seriously lack knowledge about kernel programming, and this is quite a big task. I also don't fully understand the inner workings of the kernel yet, even though *braunr* helped me a lot to understand the VM and page handling. + +I'll do what I can and keep maintaining this page so others may pickup where I left if I were to give up. diff --git a/user/arnuld.mdwn b/user/arnuld.mdwn index 1f913a2b..d26a543f 100644 --- a/user/arnuld.mdwn +++ b/user/arnuld.mdwn @@ -3,7 +3,7 @@ ## General * Name: arnuld uttre -* Email: arnuld (at) ippimail (dot) com +* Email: arnuld.mizong (at) gmail (dot) com * Country: India * Homepage: <http://www.lispmachine.wordpress.com> diff --git a/user/baswijnen.mdwn b/user/baswijnen.mdwn deleted file mode 100644 index 170eeae7..00000000 --- a/user/baswijnen.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -* Name: Bas Wijnen -* Email: <shevek@fmfNOSPAM.nl> -* Country: Netherlands diff --git a/user/bddebian.mdwn b/user/bddebian.mdwn deleted file mode 100644 index 25ac64e5..00000000 --- a/user/bddebian.mdwn +++ /dev/null @@ -1,4 +0,0 @@ -* Name: Barry deFreese -* Email: <bddebian@comcastNOSPAM.net> -* Country: USA -* Comment: GNU/Hurd hacker wannabe... diff --git a/user/diocles.mdwn b/user/diocles.mdwn deleted file mode 100644 index b25fd8ae..00000000 --- a/user/diocles.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -* Name: Tim Retout -* Email: <tim@retout.coNOSPAM.uk> -* Country: United Kingdom diff --git a/user/flaviocruz.mdwn b/user/flaviocruz.mdwn new file mode 100644 index 00000000..c4d3db69 --- /dev/null +++ b/user/flaviocruz.mdwn @@ -0,0 +1,124 @@ +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled +[[GNU Free Documentation License|/fdl]]."]]"""]] + +Name: Flávio Cruz + +Email: flaviocruz at gmail dot com + +Some [Hurd stuff](http://opensvn.csie.org/leic/hurd/) + +And code: [cl-hurd](http://git.savannah.gnu.org/cgit/hurd/incubator.git/log/?h=clisp) + +## Summer session + +Creating an extensible translator library in lisp using the mig generated stubs. + +### What's done + +- The library for writing translators is mostly written. +- This library is intended to implement virtual filesystems. Examples are: translators were data is located in a local file (like zipfs, tarfs, rarfs, ...), single file translators (that do content filtering, output of a command, etc), network based filesystems (ftpfs, httpfs, ...), proxy filesystems (like hostmux, usermux, etc..) +- It's possible to specialize the basic translator library and implement new translator classes. This is done using CLOS. +- There is a tree-translator class that makes the managing of a node tree very easy, doing all the work for us, through a simple directory API and implementing the directory callbacks for us. +- There is a simple example (something like zipfs) translator that can expose the directories and file contents of a ZIP file. +- More translator examples include: + - /dev/null translator. + - /dev/zero translator. + - translator that creates a symlink node. + - tmpfs like translator. + - a translator that does proxying between clients and the underlying translator returning all data in upper-case. + - a translator that watches for changes in a file describing the file system structure. + - an IRC translator. + - a categorizer translator: creates a virtual directory containing files listed in a file, each file is categorized with a script. For example, a script can output the music author (in an mp3 file) and then all files will be categorized by author. +- Translator options (manipulated through fsysopts) have a simple and easy to use API. +- All the Mach port manipulation API is available. +- It's possible to send and receive messages. Simple example: +<pre> + (let* ((spec-mixed (make-message-spec :fields '(:string :integer :char :string :integer :real))) + (msg-mixed (make-message :spec spec-mixed)) + (port (port-allocate :right-receive))) + (send-message msg-mixed :remote port :data (list "abc" 42 #\b "cba" 314 3.14)) + (receive-message msg-mixed :source port) ; This returns T on success. + (get-message msg-mixed))) ; Returns '("abc" 42 #\b "cba" 314 3.14) +</pre> +- New message types (like :string, :integer) can be implemented, providing a powerful extension mechanism. +- Creation of symlinks and symlink path resolution. +- Creation of character/block devices, fifos and sockets. +- Patch that opens stdin + stdout to /dev/null. +- Project has been separated into 5 ASDF installable systems: + - hurd-common + - mach + - hurd + - hurd-translator + - tree-translator +- Test cases are now written. + + +### What needs to be done + +- Fix fsys-getroot (block happens in trivfs based translators, when they do RPC's to me when I call fsys_getroot to them) and fetch-root (for passive translators). +- Make the library multithreaded (blocked by the pthread conversion project and the unavailable thread support in CLISP) +- Use the socket stubs? +- More documentation + + +### Project dependencies + +- CLISP +- [CFFI](http://common-lisp.net/project/cffi/) (apt-get installable) +- [Flexi streams](http://www.weitz.de/flexi-streams/) (apt-get installable) +- [Trivial garbage](http://www.cliki.net/trivial-garbage) (not in debian repositories) +- [cl-zip](http://common-lisp.net/project/zip/) (only needed for the zip translator) +- [cl-irc](http://common-lisp.net/project/cl-irc/) (for the irc translator) + + +## To do + +### Documentation +- Manually Bootstrapping a Translator + +### Translation +- Translate the Hurd website to Portuguese? + +## Completed tasks + +### Patches +- http://alioth.debian.org/tracker/index.php?group_id=30628&atid=410472 + - libsvg patch accepted. +- Adapted glibc patch (http://www.schwinge.homeip.net/~thomas/tmp/glibc-patches/0009-2007-07-22-version-of-init-first.c_vs._GCC_4.1.patch.patch) + - http://opensvn.csie.org/leic/hurd/patches/glibc-init-first.patch +- Patch to remove some GNUMach IPC warnings and minor cleanup: + - http://opensvn.csie.org/leic/hurd/patches/gnumach-ipc-warnings.patch +- Website patches that correct some encountered typos: + - http://opensvn.csie.org/leic/hurd/patches/hurd-talk-typo.patch + +### Documentation read + +- GNU/Hurd User's Guide, an introduction to the important concepts and software of the GNU system, written for new users, AKA "GNUbies." +- Towards a New Strategy of OS Design, an architectural overview by Thomas Bushnell, BSG. +- The Hurd, a presentation by Marcus Brinkmann. +- The Hurd Hacking Guide. +- The GNU Mach Reference Manual +- The GNU Hurd Reference Manual +- The Unofficial GNU Mach IPC beginner's guide +- Mach IPC without MIG +- CFFI User's Manual + +### Before selection + +- Uptime program in C and Lisp using CFFI. +- Hello translator. + +## Misc + +### Lisp implementations that run on Hurd + +- Clisp +- ECL +- ? diff --git a/user/gianlucaguida.mdwn b/user/gianlucaguida.mdwn deleted file mode 100644 index 34b581fa..00000000 --- a/user/gianlucaguida.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -* Name: Gianluca Guida -* Email: <glguida@gmailNOSPAM.com> -* Country: Italy diff --git a/user/jkoenig.mdwn b/user/jkoenig.mdwn new file mode 100644 index 00000000..d135e0e5 --- /dev/null +++ b/user/jkoenig.mdwn @@ -0,0 +1,36 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +## Jérémie Koenig + +Homepage: [[http://jk.fr.eu.org/]]<br/> +E-mail: [jk@jk.fr.eu.org](mailto:jk@jk.fr.eu.org) + +I am a Hurd enthusiast and occasional contributor, +currently a M.Sc. student at University of Strasbourg. +Among other things I am interested in formal methods, +languages and operating system design. +(Shameless plug: +I'll be looking for an internship in a research lab from January to June 2012 +and for a position as a Ph.D. student afterwards.) + +Contributions include: + + * Help [[port debian-installer|d-i]], + as a GSoC student for the Debian project during the summer of 2010. + * Rewrite the procfs translator + ([bug-hurd](http://lists.gnu.org/archive/html/bug-hurd/2010-08/msg00165.html) + [thread](http://lists.gnu.org/archive/html/bug-hurd/2010-09/msg00001.html)). + +I am working as a GSoC student this summer again, +for the GNU project, +on [[Java for Hurd|java]]. + + diff --git a/user/jkoenig/d-i.mdwn b/user/jkoenig/d-i.mdwn new file mode 100644 index 00000000..0b9f9f7d --- /dev/null +++ b/user/jkoenig/d-i.mdwn @@ -0,0 +1,358 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +## Hurd Debian-Installer + +My [proposal](http://wiki.debian.org/SummerOfCode2010/HurdDebianInstaller/JeremieKoenig) +to work on porting d-i on Hurd +as a [Google Summer of Code](http://code.google.com/soc/) student +has been accepted by the Debian project. + +I will be keeping track of my progress on this page. + +### Links + + * [Modified packages](http://jk.fr.eu.org/debian/unstable) + * [Latest images](http://jk.fr.eu.org/debian/hurd-installer) + * [Debian bugs](http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=jk@jk.fr.eu.org&tag=gsoc2010) + * [BusyBox port](http://lists.debian.org/debian-bsd/2010/05/msg00048.html) + * [GNU Mach initrd](http://lists.gnu.org/archive/html/bug-hurd/2010-06/msg00047.html) + +### Roadmap + +* **mach**: initrd support + * (./) preliminary patch posted and self-built (2010-06-12) + * adjustments will be needed (postponed) + * consider the alternatives discussed on bug-hurd (postponed) + +* **glibc**: fix `mkdir("/")` which returned `EINVAL` + * (./) eglibc 2.11.2-1 includes a quick fix by youpi (2010-06-15) + * (./) more complete patch posted to bug-hurd, + since other calls return incorrect errors under some circumstances + (2010-06-16) + * more work on it will be needed to make it fix the whole thing + (postponed) + +* (./) **partman** (2010-06-23) + * (./) add hurd-i386 to + `partman-partitioning/lib/disk-label.sh` + (2010-06-16, commited by youpi on 2010-06-23) + * (./) short-circuit + `partman-basicfilesystems/init.d/kernelmodules_basicfilesystems` + (2010-06-16) + * (./) partman-auto recipes: + make the default filesystem os-dependent + when it has not been preseeded (ie. the *seen* flag is clear) + * (./) force 4k blocks and 128 bytes inodes + * (./) submit patches to bugs.debian.org + ([[!debbug 586870]] and [[!debbug 586871]]) + * (./) rebuild with responsible version numbers and upload to my repository + +* (./) **libparted** (2010-06-23) + * (./) fix device paths ([[!debbug 586696]]) + * (./) fix crash on exit for part:* stores ([[!debbug 586682]]) + +* **hurd-udeb** (2010-06-23) + * (./) rebuild with the hack suggested by youpi for qemu network configuration + * (./) fix mount to accept `-o defaults` + * cleanup, ask youpi to commit + +* reloading the partition table (2010-06-25) + * User-space part stores + * (./) hurd-udeb now uses `part:N:device:X` for partition devices + (2010-06-23) + * (./) it also provides /lib/partman/commit.d/??hurd\_reloadpart, + which basically does `settrans -ag /dev/[hs]d*`. + (2010-06-24) + * Kernel-based partition devices + * (./) Mach's drivers from Linux support reloading partitions. + With help from youpi this has been made available through a + device\_set\_status() call. + * (./) make libparted use it + * Reminder: + I should file a bug against libparted with the patch sometime. + +* (./) The `/servers/exec` issue (2010-06-26) + * Due to /servers being inexistant, + the bootstrap ext2fs could not register the initial exec server, + meaning that non-bootstrap filesystems used a different one + (started from the passive translator), + which for some reason died on shell scripts, making them stall. + * Adding the `/servers` directory to hurd-udeb fixed it, + as well as the /hurd/proc issue + (failed to be run by init the first time around). + * Reminder: report the non-bootstrap exec servers failure on scripts. + +* (./) **base-installer**: (2010-06-26) + * Work around non-existant /proc/mounts. + * Firmlink /servers into /target after debootstrap + to make the network available. + +* (./) **grub-installer** + * (./) add hurd support (2010-06-27) + * /!\ grub-legacy still needs to be tested + * submit changes as a Debian bug + +**Milestone (2010-06-28): +installer kindof works, with documented manual intervention required** + +* (./) Sort out the situation with dev node creation (2010-07-07): + * Devices and servers used to be set up by debootstrap; + the hurd package would add some missing nodes. + * New strategy implemented in hurd and debootstrap: + * debootstrap uses active firmlinks into the host system + for the target system's /dev and /servers. + * the hurd package now include a `setup-translators` script, + which is used to register the passive translators by the installer's + `/libexec/runsystem` and hurd's postinst script. + +* **busybox**: submit upstream and to [[!debbug 323670]] + (waiting for upstream to review) + * (./) I have mentioned my work on the upstream mailing list, + * (./) merge the recent changes from upstream, + notably to the build system. + (2010-06-23) + * (./) ask upstream for review and merge + (2010-06-25) + * (./) sent as patches as requested + (2010-07-08) + * (./) backport any additional changes onto the debian branch + * (./) hijack [[!debbug 323670]] and submit my patches + +* **aptitude**: + * Currently broken on hurd-i386: + [[!debpkg gtest]] fails to build because of a segfault in one of the test + cases, [[!debpkg google-mock]] and hence [[!debpkg aptitude]] are missing + it as a build-dep. + The older package is not installable anymore because it's linked against + an older version of libept, which has been removed. + * (./) I bypassed the tests and uploaded the 3 packages to my repository + (2010-07-08) + * The segfault will have to be sorted out. (postponed) + +* (./) "Fix" the swap situation. (2010-07-08) + * The device\_close() libstore patch + had the unfortunate effect of making swapon fail, + since the device it activates has to be kept open. + * add options for MAKEDEV and setup-devices + to use the libparted stores + * disable youpi's patch + * make partman-basicfilesystems re-create the device + as a kernel partition, which is needed for swapon + +* (./) netcfg-static: port to hurd (2010-07-09) + * There was some amount of hurd support already + (namely, activating the interface by replacing the socket translator) + * However, this code started an active translator with + di\_exec\_shell\_log("settrans -a ...), + which stalled as a consequence of it capturing libdi's pipe + as its standard output. + * Network devices must be probed by trying to open Mach devices + with predetermined names (currently eth%d, wl%d), + because getifaddrs() does not seem to work on Hurd. + * /!\ netcfg, and configuring the installed system, postponed. + +* **procps** 3.2.7-11 (current hurd-i386 version) has [[!debbug 546888]] + * (./) Submit [[!debbug 588677]] and upload the result to my repository. + (2010-07-11) + +* (./) Set up a Debian mirror with modified packages for installation + * the [mirror](http://jk.fr.eu.org/debian/hurd-install/mirror) + is now up and running (2010-07-06) + * hacked the image build script to include its public key in + debian-archive-keyring at image build time (2010-07-08) + * Apparently debootstrap does not handle multiple versions very well. + Fix by using dpkg-scan{package,sources} rather than apt-ftparchive + to create index files. + (2010-07-10) + * Use the override files from ftp.debian.org, + to avoid debootstrap grabbing inappropriate packages. + * Changed them to make [[!debpkg ifupdown]], + [[!debpkg dhcp3-client]] and [[!debpkg dhcp3-client]] priority extra, + because they're uninstallable at the moment. + (2010-07-12) + +* (./) Put together a "jk-archive-keyring" package, + so that the mirror is authenticated in the target system as well. + (2010-07-12) + +* (./) Fix grub for user-space partitions (2010-07-16) + * grub-probe detects the whole device rather than the partition + as the device behind /boot/grub. + Consequently, grub-install fails. + * One approach would be to replace /dev/hd* by kernel devices + for file systems as well as for swap partitions. + > {X} this makes the installer crash, + > possibly due to cache coherency issue between hdX and hdXsY. + + * (./) GRUB2 kern/emu/getroot.c + [patched](http://lists.gnu.org/archive/html/bug-hurd/2010-07/msg00059.html) + to support part stores. + +* (./) Fix finish-install to skip `finish-install.d/90console` on Hurd + (2010-07-17) + +* (./) Avoid starting unnecessary /dev translators in a burst (2010-07-20) + * Use debootstrap use the extracted /usr/lib/hurd/setup-translators + to create device and server nodes in /target, + then firmlink the whole /target/dev and /target/servers + to the outer system. + * Make hurd.postinst not touch them on initial install. + +* (./) Fix mach-defpager for file and part stores on larger devices + * Use DEVICE\_GET\_RECORDS instead of DEVICE\_GET\_SIZE, which overflows an int + (2010-07-22) + +**Milestone (2010-07-22): +installer works but it's still somewhat ugly and broken** + +* (./) Ship the UTF-8 font for the hurd console + (2010-07-22) + * Upload a version of bogl with youpi's patch for Hurd. + (see [[!debbug 589987]]) + * Fix the hurd console for fonts with 16 pixels wide glyphs + (ie. handle the 8-wide glyph in there correclty) + * Support double-width glyphs (2010-07-24) + * (./) However the reduced font can't be loaded yet, + so make installer/build/Makefile + ship the whole `/usr/src/unifont.bgf` + as `/usr/share/hurd/vga-system.bgf`. + +* (./) Make the installer used the extended capabilities of the Hurd console + (2010-07-23) + * Set an UTF-8 locale in `/lib/debian-installer.d/S41term-hurd`. + * localechooser: set the language display level to 3 + when using the hurd console. + +* (./) **busybox**: cross-platform package uploaded to experimental + (2010-08-03?) + * Aurelien Jarno updated the packaging to busybox 1.17.1, + fixed a whole lot of bugs, + and uploaded a new package with both our changes; + * most patches adopted upstream, and included in the new package; + * (u)mount/swaponoff ported to kFreeBSD; + * per-OS configuration overrides. + +* (./) Update custom packages to the latest versions + and send updated patches to the BTS + (2010-08-11) + * updated partman-base to choose a default filesystem in debian/rules + rather than at runtime, + as suggested by Aurelien Jarno in [[!debbug 586870]] + * patch submitted for debian-installer-utils + ([[!debbug 592684]]). + * patch submitted for locale-chooser + ([[!debbug 592690]]). + * debootstrap, grub-installer and finish-install not yet submitted, + since the details may still change. + +* (./) **partman-target**: fix fstab creation + (2010-08-11) + * See [[!debbug 592671]] + * debian/rules: set `partman/mount_style` to `traditional` on Hurd. + * finish.d/create\_fstab\_header: add a Hurd case. + +* (./) **rootskel**: FTBFS on Hurd and other quirks + (to be fixed very soon) + +* **d-i/installer/build**: (expected soon) + * publish the patch I use + * sort out the changes suitable for inclusion + and ask youpi and/or debian-boot@l.d.o to commit them + +* call for testing and fix the bugs + +* Bug in setup-translators/MAKEDEV: + permissions are broken for nodes re-created through `MAKEDEV -k`, + because MAKEDEV's chmod/chown reaches the pre-existing translator + * Maybe settrans could be made to accept -o/--owner and + -p/--perm, to set the permissions for the underlying node? + +* (./) Silence the "no kernel" warning somehow. + +* Investigate the wget/libc/pfinet/whatever bug which corrupts Packages.gz, + see the IRC log for 2010-07-23, around 1am UTC+0200 + +* Try to resolve problems with udebs which are uninstallable on hurd-i386, + such as installation-locale and partman-whatever. + +* Provide `/proc/cmdline -> 2/cmdline`, or something. + +* Prepare a NMU for genext2fs (which is orphaned), + and ask youpi to sponsor the upload. + +* **busybox**: port + * fix stty/stat/ipcs on kFreeBSD, + * generally port more stuff, + * *ip* is needed (maybe) for network configuration, + * *mount*, *swaponoff* can be from hurd-udeb for now, + though the kFreeBSD people will need them + +* **partman**: further adjustments + * partman-base: handle /dev/hd?s* in lib/base.h + * hide irrelevant mount options? (sync, relatime) + +* Network configuration on the installed system. + This includes porting ifupdown and isc-dhcp-client, + which are currently uninstallable on hurd-i386. +* Also, better DHCP support during and after installation + +* improve the [initrd situation](FIXME: link to bug-hurd post): + ajust the ramdisk support in Mach, + use tmpfs if possible. + +* mklibs{,-copy}: + test library reduction, + make it copy the ld.so -> ld.so.1 symlink. + +* (./) hurd console fonts + +**Milestone (expected 2010-07-19): +it works great and it's beautiful** + +* test, fix, document +* support more types of installation images +* give a shot at the graphical installer if time permits +* integrate wireless drivers with netcfg +* see how [[zhengda]]'s work on DDE could be integrated +* etc.. + +### Mostly done + +#### Week 1 (2010-05-24) + +* genext2fs: patches submitted, [[!debbug 562999]] + which add support for all block sizes and choosing them at runtime. +* busybox: started porting the upstream and Debian package to Hurd and FreeBSD +* rebuilding hurd-udeb from the pkg-hurd version + and adding a ld.so link to the initrd + fixes the exec translator crashing on startup. + (BTW would there be a mean to detect this from the libdiskfs bootstrap code + and report it ?) + +#### Week 2 (2010-05-31 to 2010-06-06) + +* *busybox*: patches [posted](http://lists.debian.org/debian-bsd/2010/05/msg00048.html). +* *libdebian-installer4*: [[!debbug 584538]] +* started working on mach initrd support +* the installation images could boot into the main-menu + with the following changes: + * rebuild hurd-udeb from with the latest pkg-hurd patches + * use busybox from my osports-debian branch (see link above) + * tweak the d-i image build scripts + * the symlink /lib/ld.so -> ld.so.1 needs to be created somehow + (youpi mentionned it being the job of libc0.3-udeb I think) + * fix the poll() issue in libdebian-installer + (patch to be submitted soon), + also there is some hurd doxygen short-circuiting stuff + there which does not apply any more and prevents is to build. + * feed the initrd as a hard drive in qemu + (with some more space added to avoid it from becoming full) + diff --git a/user/jkoenig/gsoc2011_classes.dia b/user/jkoenig/gsoc2011_classes.dia new file mode 100644 index 00000000..1aa3ef6c --- /dev/null +++ b/user/jkoenig/gsoc2011_classes.dia @@ -0,0 +1,2227 @@ +<?xml version="1.0" encoding="UTF-8"?> +<dia:diagram xmlns:dia="http://www.lysator.liu.se/~alla/dia/"> + <dia:diagramdata> + <dia:attribute name="background"> + <dia:color val="#ffffff"/> + </dia:attribute> + <dia:attribute name="pagebreak"> + <dia:color val="#000099"/> + </dia:attribute> + <dia:attribute name="paper"> + <dia:composite type="paper"> + <dia:attribute name="name"> + <dia:string>#A4#</dia:string> + </dia:attribute> + <dia:attribute name="tmargin"> + <dia:real val="2.8222000598907471"/> + </dia:attribute> + <dia:attribute name="bmargin"> + <dia:real val="2.8222000598907471"/> + </dia:attribute> + <dia:attribute name="lmargin"> + <dia:real val="2.8222000598907471"/> + </dia:attribute> + <dia:attribute name="rmargin"> + <dia:real val="2.8222000598907471"/> + </dia:attribute> + <dia:attribute name="is_portrait"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="scaling"> + <dia:real val="1"/> + </dia:attribute> + <dia:attribute name="fitto"> + <dia:boolean val="false"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + <dia:attribute name="grid"> + <dia:composite type="grid"> + <dia:attribute name="width_x"> + <dia:real val="1"/> + </dia:attribute> + <dia:attribute name="width_y"> + <dia:real val="1"/> + </dia:attribute> + <dia:attribute name="visible_x"> + <dia:int val="1"/> + </dia:attribute> + <dia:attribute name="visible_y"> + <dia:int val="1"/> + </dia:attribute> + <dia:composite type="color"/> + </dia:composite> + </dia:attribute> + <dia:attribute name="color"> + <dia:color val="#d8e5e5"/> + </dia:attribute> + <dia:attribute name="guides"> + <dia:composite type="guides"> + <dia:attribute name="hguides"/> + <dia:attribute name="vguides"/> + </dia:composite> + </dia:attribute> + </dia:diagramdata> + <dia:layer name="Arrière-plan" visible="true" active="true"> + <dia:group> + <dia:object type="UML - LargePackage" version="0" id="O0"> + <dia:attribute name="obj_pos"> + <dia:point val="43.3541,9.67669"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="43.3041,8.62669;62.3869,21.8152"/> + </dia:attribute> + <dia:attribute name="meta"> + <dia:composite type="dict"/> + </dia:attribute> + <dia:attribute name="elem_corner"> + <dia:point val="43.3541,9.67669"/> + </dia:attribute> + <dia:attribute name="elem_width"> + <dia:real val="18.982784066269787"/> + </dia:attribute> + <dia:attribute name="elem_height"> + <dia:real val="12.08849294970096"/> + </dia:attribute> + <dia:attribute name="line_width"> + <dia:real val="0.10000000149011612"/> + </dia:attribute> + <dia:attribute name="line_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="fill_colour"> + <dia:color val="#ffffff"/> + </dia:attribute> + <dia:attribute name="text_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="name"> + <dia:string>#User-defined classes#</dia:string> + </dia:attribute> + </dia:object> + <dia:object type="UML - Class" version="0" id="O1"> + <dia:attribute name="obj_pos"> + <dia:point val="46.0492,12.9799"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="45.9992,12.9299;60.4592,18.4299"/> + </dia:attribute> + <dia:attribute name="elem_corner"> + <dia:point val="46.0492,12.9799"/> + </dia:attribute> + <dia:attribute name="elem_width"> + <dia:real val="14.359999999999999"/> + </dia:attribute> + <dia:attribute name="elem_height"> + <dia:real val="5.4000000000000004"/> + </dia:attribute> + <dia:attribute name="name"> + <dia:string>#HelloIo#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>#Implements a file which always contains "Hello, World!\n"#</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="suppress_attributes"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="suppress_operations"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="visible_attributes"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="visible_operations"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="visible_comments"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="wrap_operations"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="wrap_after_char"> + <dia:int val="40"/> + </dia:attribute> + <dia:attribute name="comment_line_length"> + <dia:int val="40"/> + </dia:attribute> + <dia:attribute name="comment_tagging"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="line_width"> + <dia:real val="0.10000000000000001"/> + </dia:attribute> + <dia:attribute name="line_color"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="fill_color"> + <dia:color val="#ffffff"/> + </dia:attribute> + <dia:attribute name="text_color"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="normal_font"> + <dia:font family="monospace" style="0" name="Courier"/> + </dia:attribute> + <dia:attribute name="abstract_font"> + <dia:font family="monospace" style="88" name="Courier-BoldOblique"/> + </dia:attribute> + <dia:attribute name="polymorphic_font"> + <dia:font family="monospace" style="8" name="Courier-Oblique"/> + </dia:attribute> + <dia:attribute name="classname_font"> + <dia:font family="sans" style="80" name="Helvetica-Bold"/> + </dia:attribute> + <dia:attribute name="abstract_classname_font"> + <dia:font family="sans" style="88" name="Helvetica-BoldOblique"/> + </dia:attribute> + <dia:attribute name="comment_font"> + <dia:font family="sans" style="8" name="Helvetica-Oblique"/> + </dia:attribute> + <dia:attribute name="normal_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="polymorphic_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="abstract_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="classname_font_height"> + <dia:real val="1"/> + </dia:attribute> + <dia:attribute name="abstract_classname_font_height"> + <dia:real val="1"/> + </dia:attribute> + <dia:attribute name="comment_font_height"> + <dia:real val="0.69999999999999996"/> + </dia:attribute> + <dia:attribute name="attributes"/> + <dia:attribute name="operations"> + <dia:composite type="umloperation"> + <dia:attribute name="name"> + <dia:string>#write#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="visibility"> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="inheritance_type"> + <dia:enum val="2"/> + </dia:attribute> + <dia:attribute name="query"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="class_scope"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="parameters"> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#data#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#char[]#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#offset#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + </dia:composite> + <dia:composite type="umloperation"> + <dia:attribute name="name"> + <dia:string>#read#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#char[]#</dia:string> + </dia:attribute> + <dia:attribute name="visibility"> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="inheritance_type"> + <dia:enum val="2"/> + </dia:attribute> + <dia:attribute name="query"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="class_scope"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="parameters"> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#offset#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#amount#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + </dia:composite> + <dia:composite type="umloperation"> + <dia:attribute name="name"> + <dia:string>#seek#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="visibility"> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="inheritance_type"> + <dia:enum val="2"/> + </dia:attribute> + <dia:attribute name="query"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="class_scope"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="parameters"> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#offset#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#whence#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + </dia:composite> + </dia:attribute> + <dia:attribute name="template"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="templates"/> + </dia:object> + </dia:group> + <dia:group> + <dia:object type="UML - LargePackage" version="0" id="O2"> + <dia:attribute name="obj_pos"> + <dia:point val="20.9284,1.19141"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="20.8784,0.141406;41.2223,31.2904"/> + </dia:attribute> + <dia:attribute name="meta"> + <dia:composite type="dict"/> + </dia:attribute> + <dia:attribute name="elem_corner"> + <dia:point val="20.9284,1.19141"/> + </dia:attribute> + <dia:attribute name="elem_width"> + <dia:real val="20.243864620053902"/> + </dia:attribute> + <dia:attribute name="elem_height"> + <dia:real val="30.049005191839264"/> + </dia:attribute> + <dia:attribute name="line_width"> + <dia:real val="0.10000000149011612"/> + </dia:attribute> + <dia:attribute name="line_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="fill_colour"> + <dia:color val="#ffffff"/> + </dia:attribute> + <dia:attribute name="text_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="name"> + <dia:string>#MIG-generated classes#</dia:string> + </dia:attribute> + </dia:object> + <dia:object type="UML - Class" version="0" id="O3"> + <dia:attribute name="obj_pos"> + <dia:point val="24.8976,5.14749"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="24.8476,5.09749;38.1526,9.79749"/> + </dia:attribute> + <dia:attribute name="elem_corner"> + <dia:point val="24.8976,5.14749"/> + </dia:attribute> + <dia:attribute name="elem_width"> + <dia:real val="13.205"/> + </dia:attribute> + <dia:attribute name="elem_height"> + <dia:real val="4.5999999999999996"/> + </dia:attribute> + <dia:attribute name="name"> + <dia:string>#IoServer#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>#Implements a message handler using a given IO object as a backend#</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="suppress_attributes"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="suppress_operations"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="visible_attributes"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="visible_operations"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="visible_comments"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="wrap_operations"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="wrap_after_char"> + <dia:int val="40"/> + </dia:attribute> + <dia:attribute name="comment_line_length"> + <dia:int val="40"/> + </dia:attribute> + <dia:attribute name="comment_tagging"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="line_width"> + <dia:real val="0.10000000000000001"/> + </dia:attribute> + <dia:attribute name="line_color"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="fill_color"> + <dia:color val="#ffffff"/> + </dia:attribute> + <dia:attribute name="text_color"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="normal_font"> + <dia:font family="monospace" style="0" name="Courier"/> + </dia:attribute> + <dia:attribute name="abstract_font"> + <dia:font family="monospace" style="88" name="Courier-BoldOblique"/> + </dia:attribute> + <dia:attribute name="polymorphic_font"> + <dia:font family="monospace" style="8" name="Courier-Oblique"/> + </dia:attribute> + <dia:attribute name="classname_font"> + <dia:font family="sans" style="80" name="Helvetica-Bold"/> + </dia:attribute> + <dia:attribute name="abstract_classname_font"> + <dia:font family="sans" style="88" name="Helvetica-BoldOblique"/> + </dia:attribute> + <dia:attribute name="comment_font"> + <dia:font family="sans" style="8" name="Helvetica-Oblique"/> + </dia:attribute> + <dia:attribute name="normal_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="polymorphic_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="abstract_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="classname_font_height"> + <dia:real val="1"/> + </dia:attribute> + <dia:attribute name="abstract_classname_font_height"> + <dia:real val="1"/> + </dia:attribute> + <dia:attribute name="comment_font_height"> + <dia:real val="0.69999999999999996"/> + </dia:attribute> + <dia:attribute name="attributes"/> + <dia:attribute name="operations"> + <dia:composite type="umloperation"> + <dia:attribute name="name"> + <dia:string>#IoServer#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="visibility"> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="inheritance_type"> + <dia:enum val="2"/> + </dia:attribute> + <dia:attribute name="query"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="class_scope"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="parameters"> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#back#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#Io#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + </dia:composite> + <dia:composite type="umloperation"> + <dia:attribute name="name"> + <dia:string>#handle#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#Message#</dia:string> + </dia:attribute> + <dia:attribute name="visibility"> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="inheritance_type"> + <dia:enum val="2"/> + </dia:attribute> + <dia:attribute name="query"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="class_scope"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="parameters"> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#message#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#Message#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + </dia:composite> + </dia:attribute> + <dia:attribute name="template"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="templates"/> + </dia:object> + <dia:object type="UML - Class" version="0" id="O4"> + <dia:attribute name="obj_pos"> + <dia:point val="24.2494,13.3231"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="24.1994,13.2731;38.6594,18.1731"/> + </dia:attribute> + <dia:attribute name="elem_corner"> + <dia:point val="24.2494,13.3231"/> + </dia:attribute> + <dia:attribute name="elem_width"> + <dia:real val="14.359999999999999"/> + </dia:attribute> + <dia:attribute name="elem_height"> + <dia:real val="4.8000000000000007"/> + </dia:attribute> + <dia:attribute name="name"> + <dia:string>#Io#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>#interface#</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="suppress_attributes"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="suppress_operations"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="visible_attributes"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="visible_operations"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="visible_comments"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="wrap_operations"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="wrap_after_char"> + <dia:int val="40"/> + </dia:attribute> + <dia:attribute name="comment_line_length"> + <dia:int val="17"/> + </dia:attribute> + <dia:attribute name="comment_tagging"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="line_width"> + <dia:real val="0.10000000000000001"/> + </dia:attribute> + <dia:attribute name="line_color"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="fill_color"> + <dia:color val="#ffffff"/> + </dia:attribute> + <dia:attribute name="text_color"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="normal_font"> + <dia:font family="monospace" style="0" name="Courier"/> + </dia:attribute> + <dia:attribute name="abstract_font"> + <dia:font family="monospace" style="88" name="Courier-BoldOblique"/> + </dia:attribute> + <dia:attribute name="polymorphic_font"> + <dia:font family="monospace" style="8" name="Courier-Oblique"/> + </dia:attribute> + <dia:attribute name="classname_font"> + <dia:font family="sans" style="80" name="Helvetica-Bold"/> + </dia:attribute> + <dia:attribute name="abstract_classname_font"> + <dia:font family="sans" style="88" name="Helvetica-BoldOblique"/> + </dia:attribute> + <dia:attribute name="comment_font"> + <dia:font family="sans" style="8" name="Helvetica-Oblique"/> + </dia:attribute> + <dia:attribute name="normal_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="polymorphic_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="abstract_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="classname_font_height"> + <dia:real val="1"/> + </dia:attribute> + <dia:attribute name="abstract_classname_font_height"> + <dia:real val="1"/> + </dia:attribute> + <dia:attribute name="comment_font_height"> + <dia:real val="0.69999999999999996"/> + </dia:attribute> + <dia:attribute name="attributes"/> + <dia:attribute name="operations"> + <dia:composite type="umloperation"> + <dia:attribute name="name"> + <dia:string>#write#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="visibility"> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="inheritance_type"> + <dia:enum val="2"/> + </dia:attribute> + <dia:attribute name="query"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="class_scope"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="parameters"> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#data#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#char[]#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#offset#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + </dia:composite> + <dia:composite type="umloperation"> + <dia:attribute name="name"> + <dia:string>#read#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#char[]#</dia:string> + </dia:attribute> + <dia:attribute name="visibility"> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="inheritance_type"> + <dia:enum val="2"/> + </dia:attribute> + <dia:attribute name="query"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="class_scope"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="parameters"> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#offset#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#amount#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + </dia:composite> + <dia:composite type="umloperation"> + <dia:attribute name="name"> + <dia:string>#seek#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="visibility"> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="inheritance_type"> + <dia:enum val="2"/> + </dia:attribute> + <dia:attribute name="query"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="class_scope"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="parameters"> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#offset#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#whence#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + </dia:composite> + </dia:attribute> + <dia:attribute name="template"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="templates"/> + </dia:object> + <dia:object type="UML - Class" version="0" id="O5"> + <dia:attribute name="obj_pos"> + <dia:point val="24.2494,21.6986"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="24.1994,21.6486;38.6594,27.9486"/> + </dia:attribute> + <dia:attribute name="elem_corner"> + <dia:point val="24.2494,21.6986"/> + </dia:attribute> + <dia:attribute name="elem_width"> + <dia:real val="14.359999999999999"/> + </dia:attribute> + <dia:attribute name="elem_height"> + <dia:real val="6.2000000000000002"/> + </dia:attribute> + <dia:attribute name="name"> + <dia:string>#IoUser#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>#Implements the Io interface by performing RPC#</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="suppress_attributes"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="suppress_operations"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="visible_attributes"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="visible_operations"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="visible_comments"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="wrap_operations"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="wrap_after_char"> + <dia:int val="40"/> + </dia:attribute> + <dia:attribute name="comment_line_length"> + <dia:int val="40"/> + </dia:attribute> + <dia:attribute name="comment_tagging"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="line_width"> + <dia:real val="0.10000000000000001"/> + </dia:attribute> + <dia:attribute name="line_color"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="fill_color"> + <dia:color val="#ffffff"/> + </dia:attribute> + <dia:attribute name="text_color"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="normal_font"> + <dia:font family="monospace" style="0" name="Courier"/> + </dia:attribute> + <dia:attribute name="abstract_font"> + <dia:font family="monospace" style="88" name="Courier-BoldOblique"/> + </dia:attribute> + <dia:attribute name="polymorphic_font"> + <dia:font family="monospace" style="8" name="Courier-Oblique"/> + </dia:attribute> + <dia:attribute name="classname_font"> + <dia:font family="sans" style="80" name="Helvetica-Bold"/> + </dia:attribute> + <dia:attribute name="abstract_classname_font"> + <dia:font family="sans" style="88" name="Helvetica-BoldOblique"/> + </dia:attribute> + <dia:attribute name="comment_font"> + <dia:font family="sans" style="8" name="Helvetica-Oblique"/> + </dia:attribute> + <dia:attribute name="normal_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="polymorphic_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="abstract_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="classname_font_height"> + <dia:real val="1"/> + </dia:attribute> + <dia:attribute name="abstract_classname_font_height"> + <dia:real val="1"/> + </dia:attribute> + <dia:attribute name="comment_font_height"> + <dia:real val="0.69999999999999996"/> + </dia:attribute> + <dia:attribute name="attributes"/> + <dia:attribute name="operations"> + <dia:composite type="umloperation"> + <dia:attribute name="name"> + <dia:string>#IoUser#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="visibility"> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="inheritance_type"> + <dia:enum val="2"/> + </dia:attribute> + <dia:attribute name="query"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="class_scope"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="parameters"> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#port#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#MachPort#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + </dia:composite> + <dia:composite type="umloperation"> + <dia:attribute name="name"> + <dia:string>#write#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="visibility"> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="inheritance_type"> + <dia:enum val="2"/> + </dia:attribute> + <dia:attribute name="query"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="class_scope"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="parameters"> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#data#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#char[]#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#offset#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + </dia:composite> + <dia:composite type="umloperation"> + <dia:attribute name="name"> + <dia:string>#read#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#char[]#</dia:string> + </dia:attribute> + <dia:attribute name="visibility"> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="inheritance_type"> + <dia:enum val="2"/> + </dia:attribute> + <dia:attribute name="query"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="class_scope"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="parameters"> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#offset#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#amount#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + </dia:composite> + <dia:composite type="umloperation"> + <dia:attribute name="name"> + <dia:string>#seek#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="visibility"> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="inheritance_type"> + <dia:enum val="2"/> + </dia:attribute> + <dia:attribute name="query"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="class_scope"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="parameters"> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#offset#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#whence#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + </dia:composite> + </dia:attribute> + <dia:attribute name="template"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="templates"/> + </dia:object> + <dia:object type="UML - Realizes" version="1" id="O6"> + <dia:attribute name="obj_pos"> + <dia:point val="31.4294,18.1734"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="31.3794,18.1734;31.5294,21.719"/> + </dia:attribute> + <dia:attribute name="meta"> + <dia:composite type="dict"/> + </dia:attribute> + <dia:attribute name="orth_points"> + <dia:point val="31.4294,18.1734"/> + <dia:point val="31.4294,18.1734"/> + <dia:point val="31.4294,21.6482"/> + <dia:point val="31.4294,21.6482"/> + </dia:attribute> + <dia:attribute name="orth_orient"> + <dia:enum val="0"/> + <dia:enum val="1"/> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="orth_autoroute"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="line_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="text_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="name"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:connections> + <dia:connection handle="0" to="O4" connection="14"/> + <dia:connection handle="1" to="O5" connection="16"/> + </dia:connections> + </dia:object> + <dia:object type="UML - Association" version="2" id="O7"> + <dia:attribute name="name"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="direction"> + <dia:enum val="1"/> + </dia:attribute> + <dia:attribute name="show_direction"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="assoc_type"> + <dia:enum val="1"/> + </dia:attribute> + <dia:attribute name="role_a"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="multipicity_a"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="visibility_a"> + <dia:enum val="3"/> + </dia:attribute> + <dia:attribute name="show_arrow_a"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="role_b"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="multipicity_b"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="visibility_b"> + <dia:enum val="3"/> + </dia:attribute> + <dia:attribute name="show_arrow_b"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="obj_pos"> + <dia:point val="24.8976,8.44749"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="22.3132,7.69749;25.6476,16.0231"/> + </dia:attribute> + <dia:attribute name="meta"> + <dia:composite type="dict"/> + </dia:attribute> + <dia:attribute name="orth_points"> + <dia:point val="24.8976,8.44749"/> + <dia:point val="22.3632,8.44749"/> + <dia:point val="22.3632,14.4231"/> + <dia:point val="24.2494,14.4231"/> + </dia:attribute> + <dia:attribute name="orth_orient"> + <dia:enum val="0"/> + <dia:enum val="1"/> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="orth_autoroute"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="text_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="line_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:connections> + <dia:connection handle="0" to="O3" connection="8"/> + <dia:connection handle="1" to="O4" connection="3"/> + </dia:connections> + <dia:childnode parent="O2"/> + </dia:object> + </dia:group> + <dia:group> + <dia:object type="UML - Realizes" version="1" id="O8"> + <dia:attribute name="obj_pos"> + <dia:point val="10.6153,8.74801"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="10.5653,8.74801;10.7153,12.32"/> + </dia:attribute> + <dia:attribute name="meta"> + <dia:composite type="dict"/> + </dia:attribute> + <dia:attribute name="orth_points"> + <dia:point val="10.6153,8.74801"/> + <dia:point val="10.6153,8.74801"/> + <dia:point val="10.6153,12.2493"/> + <dia:point val="10.6153,12.2493"/> + </dia:attribute> + <dia:attribute name="orth_orient"> + <dia:enum val="0"/> + <dia:enum val="1"/> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="orth_autoroute"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="line_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="text_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="name"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:connections> + <dia:connection handle="0" to="O10" connection="10"/> + <dia:connection handle="1" to="O11" connection="12"/> + </dia:connections> + <dia:childnode parent="O9"/> + </dia:object> + <dia:object type="UML - LargePackage" version="0" id="O9"> + <dia:attribute name="obj_pos"> + <dia:point val="0.503207,3.45415"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="0.453207,2.40415;18.7966,24.081"/> + </dia:attribute> + <dia:attribute name="meta"> + <dia:composite type="dict"/> + </dia:attribute> + <dia:attribute name="elem_corner"> + <dia:point val="0.503207,3.45415"/> + </dia:attribute> + <dia:attribute name="elem_width"> + <dia:real val="18.243354954612922"/> + </dia:attribute> + <dia:attribute name="elem_height"> + <dia:real val="20.576807332528524"/> + </dia:attribute> + <dia:attribute name="line_width"> + <dia:real val="0.10000000149011612"/> + </dia:attribute> + <dia:attribute name="line_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="fill_colour"> + <dia:color val="#ffffff"/> + </dia:attribute> + <dia:attribute name="text_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="name"> + <dia:string>#libports-like library#</dia:string> + </dia:attribute> + </dia:object> + <dia:object type="UML - Class" version="0" id="O10"> + <dia:attribute name="obj_pos"> + <dia:point val="4.78285,5.49761"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="4.73285,5.44761;16.4978,8.74761"/> + </dia:attribute> + <dia:attribute name="elem_corner"> + <dia:point val="4.78285,5.49761"/> + </dia:attribute> + <dia:attribute name="elem_width"> + <dia:real val="11.664999999999999"/> + </dia:attribute> + <dia:attribute name="elem_height"> + <dia:real val="3.2000000000000002"/> + </dia:attribute> + <dia:attribute name="name"> + <dia:string>#Server#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>#interface#</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="suppress_attributes"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="suppress_operations"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="visible_attributes"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="visible_operations"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="visible_comments"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="wrap_operations"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="wrap_after_char"> + <dia:int val="40"/> + </dia:attribute> + <dia:attribute name="comment_line_length"> + <dia:int val="17"/> + </dia:attribute> + <dia:attribute name="comment_tagging"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="line_width"> + <dia:real val="0.10000000000000001"/> + </dia:attribute> + <dia:attribute name="line_color"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="fill_color"> + <dia:color val="#ffffff"/> + </dia:attribute> + <dia:attribute name="text_color"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="normal_font"> + <dia:font family="monospace" style="0" name="Courier"/> + </dia:attribute> + <dia:attribute name="abstract_font"> + <dia:font family="monospace" style="88" name="Courier-BoldOblique"/> + </dia:attribute> + <dia:attribute name="polymorphic_font"> + <dia:font family="monospace" style="8" name="Courier-Oblique"/> + </dia:attribute> + <dia:attribute name="classname_font"> + <dia:font family="sans" style="80" name="Helvetica-Bold"/> + </dia:attribute> + <dia:attribute name="abstract_classname_font"> + <dia:font family="sans" style="88" name="Helvetica-BoldOblique"/> + </dia:attribute> + <dia:attribute name="comment_font"> + <dia:font family="sans" style="8" name="Helvetica-Oblique"/> + </dia:attribute> + <dia:attribute name="normal_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="polymorphic_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="abstract_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="classname_font_height"> + <dia:real val="1"/> + </dia:attribute> + <dia:attribute name="abstract_classname_font_height"> + <dia:real val="1"/> + </dia:attribute> + <dia:attribute name="comment_font_height"> + <dia:real val="0.69999999999999996"/> + </dia:attribute> + <dia:attribute name="attributes"/> + <dia:attribute name="operations"> + <dia:composite type="umloperation"> + <dia:attribute name="name"> + <dia:string>#handle#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#Message#</dia:string> + </dia:attribute> + <dia:attribute name="visibility"> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="inheritance_type"> + <dia:enum val="2"/> + </dia:attribute> + <dia:attribute name="query"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="class_scope"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="parameters"> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#msg#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#Message#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + </dia:composite> + </dia:attribute> + <dia:attribute name="template"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="templates"/> + </dia:object> + <dia:object type="UML - Class" version="0" id="O11"> + <dia:attribute name="obj_pos"> + <dia:point val="4.78285,12.2997"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="4.73285,12.2497;16.4978,15.5497"/> + </dia:attribute> + <dia:attribute name="elem_corner"> + <dia:point val="4.78285,12.2997"/> + </dia:attribute> + <dia:attribute name="elem_width"> + <dia:real val="11.664999999999999"/> + </dia:attribute> + <dia:attribute name="elem_height"> + <dia:real val="3.2000000000000002"/> + </dia:attribute> + <dia:attribute name="name"> + <dia:string>#Demux#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="suppress_attributes"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="suppress_operations"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="visible_attributes"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="visible_operations"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="visible_comments"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="wrap_operations"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="wrap_after_char"> + <dia:int val="40"/> + </dia:attribute> + <dia:attribute name="comment_line_length"> + <dia:int val="17"/> + </dia:attribute> + <dia:attribute name="comment_tagging"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="line_width"> + <dia:real val="0.10000000000000001"/> + </dia:attribute> + <dia:attribute name="line_color"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="fill_color"> + <dia:color val="#ffffff"/> + </dia:attribute> + <dia:attribute name="text_color"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="normal_font"> + <dia:font family="monospace" style="0" name="Courier"/> + </dia:attribute> + <dia:attribute name="abstract_font"> + <dia:font family="monospace" style="88" name="Courier-BoldOblique"/> + </dia:attribute> + <dia:attribute name="polymorphic_font"> + <dia:font family="monospace" style="8" name="Courier-Oblique"/> + </dia:attribute> + <dia:attribute name="classname_font"> + <dia:font family="sans" style="80" name="Helvetica-Bold"/> + </dia:attribute> + <dia:attribute name="abstract_classname_font"> + <dia:font family="sans" style="88" name="Helvetica-BoldOblique"/> + </dia:attribute> + <dia:attribute name="comment_font"> + <dia:font family="sans" style="8" name="Helvetica-Oblique"/> + </dia:attribute> + <dia:attribute name="normal_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="polymorphic_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="abstract_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="classname_font_height"> + <dia:real val="1"/> + </dia:attribute> + <dia:attribute name="abstract_classname_font_height"> + <dia:real val="1"/> + </dia:attribute> + <dia:attribute name="comment_font_height"> + <dia:real val="0.69999999999999996"/> + </dia:attribute> + <dia:attribute name="attributes"/> + <dia:attribute name="operations"> + <dia:composite type="umloperation"> + <dia:attribute name="name"> + <dia:string>#addServer#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="visibility"> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="inheritance_type"> + <dia:enum val="2"/> + </dia:attribute> + <dia:attribute name="query"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="class_scope"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="parameters"> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#s#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#Server#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + </dia:composite> + <dia:composite type="umloperation"> + <dia:attribute name="name"> + <dia:string>#handle#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#Message#</dia:string> + </dia:attribute> + <dia:attribute name="visibility"> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="inheritance_type"> + <dia:enum val="2"/> + </dia:attribute> + <dia:attribute name="query"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="class_scope"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="parameters"> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#msg#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#Message#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + </dia:composite> + </dia:attribute> + <dia:attribute name="template"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="templates"/> + <dia:childnode parent="O9"/> + </dia:object> + <dia:object type="UML - Association" version="2" id="O12"> + <dia:attribute name="name"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="direction"> + <dia:enum val="1"/> + </dia:attribute> + <dia:attribute name="show_direction"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="assoc_type"> + <dia:enum val="1"/> + </dia:attribute> + <dia:attribute name="role_a"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="multipicity_a"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="visibility_a"> + <dia:enum val="3"/> + </dia:attribute> + <dia:attribute name="show_arrow_a"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="role_b"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="multipicity_b"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="visibility_b"> + <dia:enum val="3"/> + </dia:attribute> + <dia:attribute name="show_arrow_b"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="obj_pos"> + <dia:point val="4.78285,12.9997"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="2.75192,6.54761;5.53285,14.5997"/> + </dia:attribute> + <dia:attribute name="meta"> + <dia:composite type="dict"/> + </dia:attribute> + <dia:attribute name="orth_points"> + <dia:point val="4.78285,12.9997"/> + <dia:point val="2.80192,12.9997"/> + <dia:point val="2.80192,6.59761"/> + <dia:point val="4.78285,6.59761"/> + </dia:attribute> + <dia:attribute name="orth_orient"> + <dia:enum val="0"/> + <dia:enum val="1"/> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="orth_autoroute"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="text_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="line_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:connections> + <dia:connection handle="0" to="O11" connection="3"/> + <dia:connection handle="1" to="O10" connection="3"/> + </dia:connections> + <dia:childnode parent="O9"/> + </dia:object> + <dia:object type="UML - Note" version="0" id="O13"> + <dia:attribute name="obj_pos"> + <dia:point val="5.16035,19.1017"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="5.11035,19.0517;16.1203,22.4517"/> + </dia:attribute> + <dia:attribute name="meta"> + <dia:composite type="dict"/> + </dia:attribute> + <dia:attribute name="elem_corner"> + <dia:point val="5.16035,19.1017"/> + </dia:attribute> + <dia:attribute name="elem_width"> + <dia:real val="10.91"/> + </dia:attribute> + <dia:attribute name="elem_height"> + <dia:real val="3.3000000000000003"/> + </dia:attribute> + <dia:attribute name="line_width"> + <dia:real val="0.10000000000000001"/> + </dia:attribute> + <dia:attribute name="line_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="fill_colour"> + <dia:color val="#ffffff"/> + </dia:attribute> + <dia:attribute name="text"> + <dia:composite type="text"> + <dia:attribute name="string"> + <dia:string>#Plus some kind of port set +support and a way to start +a server thread.#</dia:string> + </dia:attribute> + <dia:attribute name="font"> + <dia:font family="monospace" style="0" name="Courier"/> + </dia:attribute> + <dia:attribute name="height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="pos"> + <dia:point val="5.51035,20.3467"/> + </dia:attribute> + <dia:attribute name="color"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="alignment"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + <dia:childnode parent="O9"/> + </dia:object> + <dia:object type="UML - Realizes" version="1" id="O14"> + <dia:attribute name="obj_pos"> + <dia:point val="10.6153,8.74801"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="10.5653,8.74801;10.7153,12.32"/> + </dia:attribute> + <dia:attribute name="meta"> + <dia:composite type="dict"/> + </dia:attribute> + <dia:attribute name="orth_points"> + <dia:point val="10.6153,8.74801"/> + <dia:point val="10.6153,8.74801"/> + <dia:point val="10.6153,12.2493"/> + <dia:point val="10.6153,12.2493"/> + </dia:attribute> + <dia:attribute name="orth_orient"> + <dia:enum val="0"/> + <dia:enum val="1"/> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="orth_autoroute"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="line_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="text_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="name"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:connections> + <dia:connection handle="0" to="O10" connection="10"/> + <dia:connection handle="1" to="O11" connection="12"/> + </dia:connections> + <dia:childnode parent="O9"/> + </dia:object> + </dia:group> + <dia:object type="UML - Note" version="0" id="O15"> + <dia:attribute name="obj_pos"> + <dia:point val="29.2528,-4.64872"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="29.2028,-4.69872;32.8978,-2.89872"/> + </dia:attribute> + <dia:attribute name="meta"> + <dia:composite type="dict"/> + </dia:attribute> + <dia:attribute name="elem_corner"> + <dia:point val="29.2528,-4.64872"/> + </dia:attribute> + <dia:attribute name="elem_width"> + <dia:real val="3.5949999999999998"/> + </dia:attribute> + <dia:attribute name="elem_height"> + <dia:real val="1.7"/> + </dia:attribute> + <dia:attribute name="line_width"> + <dia:real val="0.10000000000000001"/> + </dia:attribute> + <dia:attribute name="line_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="fill_colour"> + <dia:color val="#ffffff"/> + </dia:attribute> + <dia:attribute name="text"> + <dia:composite type="text"> + <dia:attribute name="string"> + <dia:string>#io.defs#</dia:string> + </dia:attribute> + <dia:attribute name="font"> + <dia:font family="monospace" style="0" name="Courier"/> + </dia:attribute> + <dia:attribute name="height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="pos"> + <dia:point val="29.6028,-3.40372"/> + </dia:attribute> + <dia:attribute name="color"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="alignment"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + </dia:object> + <dia:object type="UML - Dependency" version="1" id="O16"> + <dia:attribute name="obj_pos"> + <dia:point val="31.0503,-2.94872"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="31.0003,-2.94872;32.3053,1.26212"/> + </dia:attribute> + <dia:attribute name="meta"> + <dia:composite type="dict"/> + </dia:attribute> + <dia:attribute name="orth_points"> + <dia:point val="31.0503,-2.94872"/> + <dia:point val="31.0503,-2.94872"/> + <dia:point val="31.0503,1.19141"/> + <dia:point val="31.0503,1.19141"/> + </dia:attribute> + <dia:attribute name="orth_orient"> + <dia:enum val="0"/> + <dia:enum val="1"/> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="orth_autoroute"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="text_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="line_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="name"> + <dia:string>#mig#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="draw_arrow"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:connections> + <dia:connection handle="0" to="O15" connection="6"/> + <dia:connection handle="1" to="O2" connection="1"/> + </dia:connections> + </dia:object> + <dia:object type="UML - Realizes" version="1" id="O17"> + <dia:attribute name="obj_pos"> + <dia:point val="38.6094,14.4231"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="38.5594,13.5731;46.0992,16.0015"/> + </dia:attribute> + <dia:attribute name="meta"> + <dia:composite type="dict"/> + </dia:attribute> + <dia:attribute name="orth_points"> + <dia:point val="38.6094,14.4231"/> + <dia:point val="42.3293,14.4231"/> + <dia:point val="42.3293,14.3799"/> + <dia:point val="46.0492,14.3799"/> + </dia:attribute> + <dia:attribute name="orth_orient"> + <dia:enum val="0"/> + <dia:enum val="1"/> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="orth_autoroute"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="line_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="text_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="name"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:connections> + <dia:connection handle="0" to="O4" connection="4"/> + <dia:connection handle="1" to="O1" connection="3"/> + </dia:connections> + </dia:object> + <dia:object type="UML - Realizes" version="1" id="O18"> + <dia:attribute name="obj_pos"> + <dia:point val="16.4478,6.59761"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="16.3978,5.74761;24.9476,8.17255"/> + </dia:attribute> + <dia:attribute name="meta"> + <dia:composite type="dict"/> + </dia:attribute> + <dia:attribute name="orth_points"> + <dia:point val="16.4478,6.59761"/> + <dia:point val="20.4657,6.59761"/> + <dia:point val="20.4657,6.54749"/> + <dia:point val="24.8976,6.54749"/> + </dia:attribute> + <dia:attribute name="orth_orient"> + <dia:enum val="0"/> + <dia:enum val="1"/> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="orth_autoroute"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="line_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="text_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="name"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:connections> + <dia:connection handle="0" to="O10" connection="4"/> + <dia:connection handle="1" to="O3" connection="3"/> + </dia:connections> + </dia:object> + </dia:layer> +</dia:diagram> diff --git a/user/jkoenig/gsoc2011_classes.png b/user/jkoenig/gsoc2011_classes.png Binary files differnew file mode 100644 index 00000000..7149b813 --- /dev/null +++ b/user/jkoenig/gsoc2011_classes.png diff --git a/user/jkoenig/gsoc2011_proposal.mdwn b/user/jkoenig/gsoc2011_proposal.mdwn new file mode 100644 index 00000000..9840f14f --- /dev/null +++ b/user/jkoenig/gsoc2011_proposal.mdwn @@ -0,0 +1,12 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +This page has moved [[here|java]]. + diff --git a/user/jkoenig/java.mdwn b/user/jkoenig/java.mdwn new file mode 100644 index 00000000..e5d288cc --- /dev/null +++ b/user/jkoenig/java.mdwn @@ -0,0 +1,511 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag stable_URL]] + + +# Improve Java on Hurd (GSoC 2011) + + +## Description + +The project consists in improving Java support on Hurd. +This includes porting OpenJDK, +creating low-level Java bindings for Mach and Hurd, +as well as creating Java libraries to help with translator development. + +For details, see my original [[proposal]]. + + +## Current status + +Feeling slightly behind schedule; but project is very ambitious, which has been +known from the beginning, and there is great progress, so there is no problem. +--[[tschwinge]], 2011-06-29. + + +### Apt repository + +Modified Debian packages are available in this repository: + + deb http://jk.fr.eu.org/debian experimental/ + deb-src http://jk.fr.eu.org/debian experimental/ + + +### Glibc signal code improvements + +2011-06-29: +Patches were submitted to `libc-alpha` +which implement global signal dispositions and `SA_SIGINFO`. +My latest code is available on +[github](http://github.com/jeremie-koenig/glibc/commits/master-beware-rebase), +and modified Debian packages +are available in my apt repository. + +2011-07-20: +The patches were reviewed by Samuel Thibault. +Samuel pointed out a couple of issues +and I beleive I have addressed all of them (fixes posted). +I'm in the process of publishing updated libc and hurd packages; +provided those work as expected, +the next step would be to get these changes into Debian. + +One question is how the new symbols introduced by my patches +should be handled. +Weak symbols turned out to be impractical, +so I'm currently considering using a Debian-specific +symbol version in the interim period (`GLIBC_2.13_DEBIAN_8` so far). +The ultimate symbol version to be used will depend on +the time at which the patches get integrated upstream +(most likely `GLIBC_2.15`), +at which point we will alias the interim version +to the new one in debian packages. + +I have modified libc0.3 to include a `deb-symbols(5)` file +(alternatively see <http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps>) +so that we get an accurate libc dependency in `hurd` and other packages +when the symbols in question are pulled in. + +[[hurd/libthreads]] (cthreads library) will not be changed. There's no reason +why its behavior should change, whereas for [[libpthread]] it's needed for +conformance. Patches posted on 2011-05-25, but there's a more recent one in +the modified hurd package (adds `_hurd_sigstate_delete` and removes the weak +symbols). + +IRC, freenode, #hurd, 2011-07-27: + + < jkoenig> the glibc patches are pending review and inclusion in Debian (I + think youpi wants to check my latest additions before we go ahead with + that) + < jkoenig> when it's in Debian and the sky does not fall, I intend to + resubmit a full series to libc-alpha for inclusion upstream. + +IRC, freenode, #hurd, 2011-08-24: + + < youpi> jkoenig: I'll probably commit your siginfo/globalsig patches soon + < youpi> I'm building the ant package atm, seems to proceed great + < jkoenig> youpi, great! + +Another issue which came up with OpenJDK is the expansion +by the dynamic linker of `$ORIGIN` in the `RPATH` header, +see below. + +#### Plans + +The patches are pending review and inclusion upstream. +As soon as we reach an agreement wrt. the new interfaces +(in particular wrt. the value of `SA_SIGINFO`), +the patches will be applied to the Debian libc packages +for broader testing. + + +##### Open Items + + * Test patches: in progress, [[jkoenig]], Svante. More volunteers welcome, + of course. + + > There's an issue with gdb, + > namely signals lose their "untracedness" when they go + > through the global sigstate's pending mask, + > so gdb spins intercepting a signal and trying to deliver it. + > [Patch](http://github.com/jeremie-koenig/glibc/commit/3ecb990e9d08d5f75adc40b738b35a1802cc0943). + + * If [[jkoenig]] thinks it's mature enough: should ask + [[Samuel|samuelthibault]] to test these patches on the buildds. + + > There's a risk that a dependency on my patched libc + > might be pulled in while building packages + > (in particular hurd) + > --[[jkoenig]] 2011-06-22 + + * Waiting on ABI finalization ([!] Roland). + + * Which numeric values to use for `SA_SIGINFO` (and `SA_NOCLDWAIT`)? + + > Staying in sync with BSD seems the most logical approach, + > so I have defined it to 0x40. --[[jkoenig]] 2011-06-29 + + * Get patches reviewed (Roland?), and integrated into official sources: [!] + [[tschwinge]]. + + > [[samuelthibault]] reviewed the patches and pointed out a couple of + > issues which I'm currently working on: + > + > * Slight behaviour change with respect to forgetting blocked ignored + > signals. POSIX is flexible in this regard but I guess we could retain + > them instead of the current behaviour. + > * Sigstate accessors could be made extern inline functions. + > I suggest we postpone this. + > * Incorrect changes for `msg_{get,set}_init_int(INIT_SIGMASK)` + > * Some comments which can be improved. + > + > Once these are fixed we can probably test the patches in Debian. + > + > --[[jk]] 2011-07-06 + + * Documentations bits (from here, the initial [[proposal]], and elsewhere) + should probably be + moved either into the appropriate glibc or Hurd documentation + files/reference manuals, or to [[glibc/signal]]. + + * `SA_SIGINFO` patch is based on [[Samuel|samuelthibault]]'s earlier work. + Thus, have him review the new patch? + + * `SA_SIGINFO` patch has a few TODOs w.r.t. protocol changes for missing + information, and for FPU state. Providing even incomplete information is + an improvement on the current status. The question is, whether + applications rely on this information in any hard way if `SA_SIGINFO` is + available? + + * We could possibly rename certain fields in `struct siginfo`, say + `si_pid_not_implemented`, to ensure compilation failures for programs + which use them. Or perhaps a linker warning is possible. + + IRC, freenode, #hurd, 2011-08-20: + + < youpi> jkoenig: I was considering renaming the fields of siginfo + < youpi> to catch applications which need those which we haven't + yet + < jkoenig> youpi, makes sense AFAICT + < youpi> one issue we'll get is some application which previously + built without SA_SIGINFO, and will now want some information + we're not yet able to provide + < youpi> but at least we'll know + < jkoenig> youpi, yes it would still be better than having them + crash at runtime because of it + + IRC, freenode, #hurd, 2011-08-21: + + < youpi> jkoenig: actually we need the fields for waitid + + * The FPU state is not included in the `ucontext_t` passed to the signal + handler. On the other hand, `ucontext_t` is actually being somewhat + deprecated: the functions to restore it are no longer in POSIX. + `thread_get_state`() should return this information, in case we decide + to fill the gap, and there might be existing glibc wrappers, too. + + * Perhaps have a look at `SA_NOCLDWAIT`. + + +### Port OpenJDK + +As suggested by [[tschwinge]], I have targeted OpenJDK 7 at first. +I don't expect it will be too hard to backport my patches to OpenJDK 6. +I have succeeded in building a working JIT-less ("zero") version, +although the dynamic linker issue must be worked around. +Porting Hotspot (the original just-in-time compiler of OpenJDK) +should not be too hard. +If that fails we can fall back on Shark +(a portable alternative JIT which uses LLVM). + +Complexity of porting HotSpot: probably low. The complex things should be +arch- rather than OS-specific. Not many Linux-specific interfaces used. +Garbage collection/memory management, etc. and/or most of other Linux-specific +interfaces are already dealt with for the zero build. + +The dynamic linker issue is as follows. +An executable-specific search path can be provided in the ELF RPATH header. +RPATH directories can include the special string `$ORIGIN`, +which is to be expanded to the directory the executable was loaded from. +OpenJDK's `java` command uses this feature to locate +the right `libjli.so` at runtime. +However, +on Hurd this information is not available to the dynamic linker +and as a consequence RPATH components which include `$ORIGIN` +are silently discarded. + +This can be worked around by defining +the `LD_ORIGIN_PATH` environment variable. +(which have I used to build and test OpenJDK so far.) + +IRC, freenode, #hurd, 2011-07-27: + + < jkoenig> if you have the latest hurd/libc in my repository, you should be + able to run /usr/lib/jvm/java-7-openjdk/bin/java without defining + LD_ORIGIN_PATH manually + < braunr> java: error while loading shared libraries: libjli.so: cannot + open shared object file: No such file or directory + < jkoenig> braunr, this one is expected, it's the symlink problem. + < braunr> oh ok + < jkoenig> (ie. thus far, if java is accessed as /usr/bin/java, the ld + origin ends up as /usr/bin) + + < jkoenig> *sigh*... it seems I'm going to have to reimplement realpath() + in elf/dl-origin.c. + < braunr> why ? + < jkoenig> using it from there results in duplicate symbols when linking + elf/librtld.map.o + < braunr> from where ? + < braunr> dl-origin ? + < jkoenig> apparently this part of the code uses a different allocator + (elf/dl-minimal.c) + < braunr> oh + < braunr> depndency issues ? + < braunr> or bootstrapping ones ? + < jkoenig> http://paste.debian.net/124310/ + < jkoenig> dl-origin is what provides the $ORIGIN value for RPATH (now + sysdeps/mach/hurd/dl-origin.c, in our case) + < braunr> but what's the problem ? + < braunr> what prevents you from using the existing implementation ? + < jkoenig> you mean copy-and-paste the code ? Well I'll end up doing that I + guess... not that it feels right. + < braunr> not really + < braunr> link against what provides it + < braunr> i'm really not familiar with glibc :/ + < jkoenig> also I'd like to understand what's happening precisely before I + resort to such blasphemy :-) + < braunr> :) + < jkoenig> maybe I could make {file,exec,_hurd}_exec_file_name() + canonicalize it instead. + < jkoenig> for some reason it does not feel right, though. + < braunr> why ? + < jkoenig> I'm not sure, loss of information maybe? + < jkoenig> (that I ran /usr/bin/java as opposed to /usr/lib/jvm/...) + < braunr> i guess you should explain the issue more clearly, i feel like + there is something i'm really missing :/ + < braunr> but it can wait + < jkoenig> that ld.so actually needs the canonical file name to substitute + $ORIGIN is its own problem, not that of exec or _hurd_exec_file_name.. + < jkoenig> Ok, so.. Initially the shell (indirectly) runs + _hurd_exec_file_name(..., "/usr/bin/java", ...), which then calls + file_exec_file_name() on the file in question, passing it its own + filename + < jkoenig> which is transmitted to exec_exec_file_name() + < jkoenig> (until now it's all pochu's patch) + < jkoenig> which then makes it available to the newly created process + through exec_startup_get_info_2() (my own addition) + < braunr> oh + < braunr> wasn't it available before oO ? + < jkoenig> no, exec only has access to a port to the executable file. + < braunr> how was argv[0] handled then ? + < jkoenig> argv[0] is handled like any other argument + < braunr> ok, so the file path is duplicated ? + < jkoenig> the shell (or whomever calls _hurd_exec) provide whatever they + want. + < braunr> ok + < jkoenig> well argv[0] is not necessarily the file path (at least not the + full path) + < braunr> right + < jkoenig> so exec() does some guesswork with $PATH but obviously that's + limited. + < braunr> so what you changed is that get_info_2 now receives a canonical + path ? + < jkoenig> right + < jkoenig> (or whatever was specified to _hurd_exec_file_name(), for this + reason and others we shouldn't use it for setuid programs.) + < jkoenig> well, not a canonical path. A path. (hence the problem) + < braunr> ok + < jkoenig> now both the filesystem and exec might run under another root so + they're not an option for canonicalization + < jkoenig> _hurd_exec_file_name (in libc) might be a better spot. + < braunr> resolution from the client, yes + +IRC, freenode, #hurd, 2011-08-03: + + < jkoenig> so my RPATH patches are polished and built, and I'll post them + soon, is the good news + +IRC, freenode, #hurd, 2011-08-17: + + < jkoenig> also fixed a fakeroot-induced deadlock in my dl-origin patches + (namely, under fakeroot, realpath() uses a socket (through stat), so we + need to use it when _hurd_dtable_lock is not held) + < jkoenig> also I'll post my dl-origin patches shortly + < youpi> dl-origin is about the environment variable that java needs, + right? + < jkoenig> about the environment variable it shouldn't need, yes :-) + < youpi> ah :) + < youpi> but ok, I vaguely remember what that refers to + < jkoenig> $LD_ORIGIN_PATH is used as an override (much like + LD_LIBRARY_PATH), but ideally ld.so uses whatever directory the loaded + binary is from. + < youpi> ok + < jkoenig> (as a substitution for $ORIGIN in RPATH) + + +#### Plans + +I intend to fix the RPATH issue +by building on [[pochu]]'s `file_exec_file_name()` +[patches](http://lists.gnu.org/archive/html/bug-hurd/2010-08/msg00023.html). + +I have succeeded in building a Hotspot-enabled `libjvm.so`, +although the current toolchain issues +([[toolchain/ELFOSABI_GNU]]; 2011-07-03: fix committed in binutils) +have so far prevented me from testing it. + +> It turns out the build fails later on in `hotspot/agent` +> because Hurd lack a `libthread_db.so`. +> Also, a Shark version builds, but the result does not work so far. +> +> In other news, Damien Raude-Morvan is +> [working on a kFreeBSD version](http://lists.debian.org/debian-java/2011/06/msg00124.html), +> so I intend to merge my current patches with his. +> +> --[[jkoenig]] 2011-06-29 + +IRC, freenode, #hurd, 2011-08-03: + + < jkoenig> and I'm battleing to update my OpenJDK patches to b147, and + merge the with the kFreeBSD ones. + < braunr> b147 ? + < jkoenig> but that thing is seriously huge and touches about everything, + so it's taking more time than I'd have hoped + < jkoenig> braunr, the latest release of IcedTea / OpenJDK 7 and the + current Debian version (in experimental of course) + < braunr> ok + < jkoenig> I'm trying to make this clean so that hopefully we can get them + integrated at some level of upstream (probably IcedTea, at least at + first) + +IRC, freenode, #hurd, 2011-08-10: + + < jkoenig> well actually I've finished merging my patches with the freebsd + ones, and updating them to the new openjdk-7, + < jkoenig> but now a new version of both is out :-P + + +##### Upstream Submission + +On 2011-07-15, *gnu_andrew* talked to us in the #hurd channel (freenode IRC), +who is a maintainer of IcedTea. He's supportive of the porting approach, and +is willing to review and integrate small patches for individual issues (rather +than some huge patchset). Send patches to <distro-pkg-dev@openjdk.java.net>. + +##### Open Items + + * [!] [[tschwinge]] to have a look at [[pochu]]'s `file_exec_file_name()` + patches, whether it's generally the right idea. + + * Assuming it is, continue with getting `$ORIGIN` working. + + * `libthread_db.so` issue. Likely, the Serviceability Agent is used by jdb + and the like only, so for now the goal should be to lose some functionality + by removing/avoiding this dependency. + + * [[java-access-bridge]] (not critical; JVM appears to work without) + + * IRC, freenode, #hurd, 2011-07-27: + + < jkoenig> there's a bug with java.nio when running javadoc, you might + run into it. + + * [[`SCM_CREDENTIALS`|open_issues/sendmsg/scm_creds]] + + IRC, freenode, #hurd, 2011-08-03: + + < jkoenig> wrt. peer credentials, openjdk also uses file modes for + security, and my guess is that it's sufficient, at least on Hurd, so + I've reduced my priority for this at least in the meantime + + * They seem to have a rather heavy-weight process for such projects: confer + <http://mail.openjdk.java.net/pipermail/announce/2011-January/000092.html>, + for example. Do we need this, too? + + > Probably not. + > My current approach (and Damien's wrt. the kFreeBSD patches) + > is to add preprocessor directives in the Linux code + > to make it more portable. + > --[[jkoenig]] 2011-06-29 + + * Eclipse + + OK for testing -- but I'd very much hope that it *just works* as soon as we + provide the required Java platform. But it may perhaps have some + Linux-specifics (needlessly?) in its basement. Is it available for Debian + GNU/kFreeBSD already? + + +### Java bindings for Mach + +The code is at <http://github.com/jeremie-koenig/hurd-java>. + +[[tschwinge]]'s notes for building with... + + * GCJ installed (due to the current Debian multilib confusion): + + $ tmp1=/usr/lib/gcc/i486-gnu/4.6 tmp2=/usr/lib/i386-gnu/gcc/i486-gnu/4.6 LIBRARY_PATH=$tmp2 COMPILER_PATH=$tmp1:$tmp2 C_INCLUDE_PATH=$tmp1/include make + + * OpenJDK installed (to have it find the shared library, and the jni.h header + file): + + $ jdk=/usr/lib/jvm/java-7-openjdk LD_LIBRARY_PATH=$jdk/jre/lib/i386/jli C_INCLUDE_PATH=$jdk/include make + +Doxygen-generated documentation is available at +<http://jk.fr.eu.org/hurd-java/doc/html/>; or run `make doc` yourself. + +IRC, freenode, #hurd, 2011-07-27: + + < jkoenig> I need to be able to read/write individual data items from + messages, in order to implement deallocation correctly, so I'm working on + that when I'm waiting for things to build, but it's not my primary focus + right now. + +IRC, freenode, #hurd, 2011-08-17: + + < jkoenig> so, weekly status report: I have made some progress on the java + bindings, I hope to have a safe version mach_msg soon, after which I can + begin experimenting with mig. + + +#### Plans + +(just started.) + + +##### Open Items + + * [[tschwinge]] has to read about RMI and CORBA. + + * MIG + + * Hacking [[microkernel/mach/MIG]] shouldn't be too difficult. + + * (Unless you want to make MIG's own code (that is, not the generated + code, but MIG itself) look a bit more nice, too.) ;-) + + * There are also alternatives to MIG. If there is interest, the following + could be considered: + + * FLICK ([[!GNU_Savannah_task 5723]]). [[tschwinge]] has no idea yet if + there would be any benefits over MIG, like better modularity (for the + backends)? If we feel like it, we could spend a little bit of time on + this. + + * For [[microkernel/Viengoos]], Neal has written a RPC stub generator + entirely in C Preprocessor macros. While this is obviously not + directly applicable, perhaps we can get some ideas from it. + + * Anything else that would be worth having a look at? (What are other + microkernels using?) + + * `mach_msg` + + * Seems like the right approach to [[tschwinge]], but he hasn't digested + all the pecularities yet. Will definitely need more time. + + +## Postponed + +Might get back to these as time/interest permits. + + +### GCJ + + * [[tschwinge]] has the feeling that Java in GCC (that is, GCJ) is mostly + dead? (True?) + + * Thus perhaps not too much effort should be spent with it. + + If the POSIX threads signal semantics makes it going, then great, otherwise + we should get a feeling what else is missing. + + +### Joe-E. diff --git a/user/jkoenig/java/discussion.mdwn b/user/jkoenig/java/discussion.mdwn new file mode 100644 index 00000000..352f6d62 --- /dev/null +++ b/user/jkoenig/java/discussion.mdwn @@ -0,0 +1,559 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!toc]] + + +# General + +Some [[tschwinge]] comments regarding your proposal. Which is very good, if I +may say so again! :-) + +Of course, everyone is invited to contribute here! + +I want to give the following methodology a try, instead of only having +email/IRC discussions -- for the latter are again and again showing a tendency +to be dumped and deposited into their respective archives, and be forgotten +there. Of course, email/IRC discussions have their usefulness too, so we're +not going to replace them totally. For example, for conducting discussions +with a bunch of people (who may not even be following these pages here), email +(or, as applicable, the even more interactive IRC) will still be the medium of +choice. (And then, the executive summary should be posted here, or +incorporated into your proposal.) + +Also, if you disagree with this suggested procedure right away, or at some +later point begin to feel that this thing doesn't work out, or simply takes too +much time (I don't think so: writing emails takes time, too), just say so, and +we can reconsider. + +Of course, as this wiki is a passive medium rather than an active one as IRC +and email are, it is fine to send notices like: *I have updated the wiki page, +please have a look*. + +One idea is that your proposal evolves alongside with the ongoing work, and +represents (in more or less detail) what has been done and what will be done. +Also, we can hopefully use parts of it for documentation purposes, or as +recipes for similar work (enabling other programming languages on the Hurd, for +example). + +For this, I suggest the following procedure: as applicable, you can either +address any comments in here (for example, if they're wrong :-), or if they +require further discussion; think: *email discussion*), or you can address them +directly in your propoal and remove the comments from here at the same time +(think: *bug fix*). + +Generally, you can assume that for things I didn't comment on (within some +reasonable timeframe/upon asking me again) that I'm fine with them. Otherwise, +I might say: *I don't like this as is, but I'll need more time to think about +it.* + +There is also a possibility that parts of your proposal will be split off; in +cases where we think they're valuable to follow, but not at this time. (As you +know, your proposal is not really a trivial one, so it may just be too much for +one person's summer.) Such bits could be moved to [[open_issues]] pages, +either new ones or existing ones, as applicable. + + +# GSoC Site Discussion + + * Discussion items from + <http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/jkoenig/1> + should be copied here: + + * technical bits (obviously); + + * also the *why do we want Java bindings* reasoning; + + * CLISP findings should also be documented somewhere permanently. + + * We should probaby open up a *languages for Hurd* section on the web + pages ([[!taglink open_issue_documentation]]). + + +# Java Native Interface (JNI) + + * <http://en.wikipedia.org/wiki/Java_Native_Interface> + * <http://download.oracle.com/javase/7/docs/technotes/guides/jni/> + * <http://java.sun.com/products/jdk/faq/jnifaq.html> + * <http://java.sun.com/docs/books/jni/> + + +## Java Native Access (JNA) + + * <http://jna.java.net/> + * <https://github.com/twall/jna#readme> + +This is a different approach, and *while some attention is paid to performance, +correctness and ease of use take priority*. + +As we plan on only having a few native methods (for invoking `mach_msg`, +essentially), JNA is probably the wrong approach: portability and ease of use +is not important, but performance is. + +## Compiled Native Interface (CNI) + + * <http://gcc.gnu.org/onlinedocs/gcj/About-CNI.html> + * <http://per.bothner.com/papers/UsenixJVM01/CNI01.pdf> + +Probably faster than JNI, but only usable with GCJ. + +> Given that we have very few JNI calls, +> it might be interesting to take a "dual" approach +> if CNI actually improves performance +> when compiling to native code. +> --[[jkoenig]] 2011-07-20 + +# IRC, freenode, #hurd, 2011-07-13 + +[[!tag open_issue_documentation]] + + <jkoenig> Yes, I guess so. Maybe start investigating mig because it may + have repercussions on what the best approach would be for some aspects of + the Mach bindings. + <tschwinge> I still think that making MIG emit Java code is not too + difficult, once you have the required Java infrastructure (like what + you're writing at the moment). + <tschwinge> On the other hand, if there's another approach that you'd like + to use, I'm not trying to force using MIG. + <braunr> i still have a problem understanding your approach + <braunr> at which level are your bindings located ? + <jkoenig> I expect mig it will be the easiest route, but of course possibly + it won't. + <tschwinge> jkoenig: Yeah, be give some high-level to low-level overview? + <jkoenig> ok, so + <jkoenig> at the very core, low-level, we have a very thin amount of JNI + code to access (proper) system calls. + <jkoenig> by "proper" I mean things like mach_task_self, mach_msg and + mach_reply_port, which are actually system calls rather than RPCs to the + kernel. + <braunr> right + <jkoenig> at this level, we manipulate port names as integers, and the + message buffers for mach_msg are raw ByteBuffers (from the java.nio + package) + <jkoenig> actually, so-called /direct/ ByteBuffers, which are backed by + memory allocated outside of the Java heap, rather than as a byte[] array + <jkoenig> we can retreive the pointer from the JNI code and use the buffer + directly. + <jkoenig> (so, good for performance and it's also portable.) + <braunr> ok + <braunr> i'm more interested in the higher level bindings :) + <jkoenig> ok so, higher up. + <jkoenig> design goal from my proposal: "the memory safety of Java should + be maintained and extended to Mach primitives such as port names and + out-of-line memory regions" + <jkoenig> so integer port names are not "safe" in the sense that they can + be forged and misused in all kinds of way + <jkoenig> which is why I have a layer of Java code whose job is to wrap + this kind of low-level Mach stuff into safe abstractions + <jkoenig> and ideally the user should only use these safe abstractions. + <tschwinge> (Not to restrict the programmer, but to help him write correct + code.) + <jkoenig> right. + <braunr> so you can't use mach RPCs directly + <jkoenig> tschwinge, also to actually restrict them, in a Joe-E / + object-capability context, but that's not the primary concern right now + ;-) + <braunr> or you force your wrappers to have these abstractions as input + <jkoenig> braunr, well, actually at this level you still have Mach RPC + <jkoenig> but for instance, port names are encapsulated into "MachPort" + objects which ensure they are handled correcly + <tschwinge> As I understand it, you use these abstractions to prepare a + usual mach_msg message, and then invoke mach_msg. + <braunr> ok + <jkoenig> and message buffers are wrapped into "MachMsg" objects which both + help you write the messages into the ByteBuffer and prevent you from + doing funky stuff + <jkoenig> and ensure the ports which you send/receive/pseudo-receive after + an error/... are deallocated as required, etc. + <braunr> what's the interface to use IPC ? + <tschwinge> Is MIG doing that, too, I think? (And antrik once found some + error there, which is still to be reviewed...) + <jkoenig> braunr, so basically as a user you would be free to use either + one of these layers, or to use MIG-generated classes which would + construct and exchange messages for you using the second (safe) layer. + <braunr> ok, let's just finish with the low level layer before going + further please + <jkoenig> tschwinge, MIG does some type checking on the received message + and saves you the trouble of constructing/parsing them yourself, but I'm + not sure about how mach_msg errors are handled + <braunr> what are the main methods of MachMsg for example ? + <jkoenig> braunr, you may want to have a look at + http://jk.fr.eu.org/hurd-java/doc/html/classorg_1_1gnu_1_1mach_1_1MachMsg.html + <braunr> right, sorry + <braunr> grabbed the code at work and forgot here + <jkoenig> and also + https://github.com/jeremie-koenig/hurd-java/blob/master/HelloMach.java + which uses it + <jkoenig> but roughly, you'd use setRemotePort, setLocalPort, setId to + write your message's header + <jkoenig> then use one of the putFoo() methods to add data items to the + message + <braunr> ok, the mapping with the low level C interface is very clear + <braunr> that's good for me + <jkoenig> the putFoo() methods would write the appropriate type + descriptors, then the actual data. + <braunr> we can go on with the MiG part if you want :) + <jkoenig> right, + <jkoenig> so here you may want to look at the UML class diagram from + http://www.bddebian.com/~hurd-web/user/jkoenig/java/proposal/ + <jkoenig> so in the C case, mig generates 3 files + <jkoenig> a header file which has the prototypes of the mig-generated + stubs, + <jkoenig> a *User.c which has their actual implementation + <jkoenig> and a *Server.c which handles demultiplexing the incoming + messages and helps with implementing servers. + <jkoenig> so we would do something along these lines, more or less: + <jkoenig> mig would generate the code for a Java interface in lieu of the + *.h file. + <jkoenig> a generated FooUser class would implement this interface by doing + RPC + <jkoenig> (so basically you would pass a MachPort object to the + constructor, and then you could use the resulting object to do RPC with + whatever is on the other end) + <jkoenig> and the generated FooServer class would do the opposite, + <braunr> ok + <braunr> issues with threads ? + <jkoenig> you would pass an object implementing the Foo interface to the + constructor, + <braunr> i'm guessing the demux part may have to create threads, right ? + <jkoenig> and the resulting object would handle messages by using the + object you passed. + <jkoenig> braunr, right, so that would be more a libports kind of code, + <braunr> the libports-like library, i see + <jkoenig> to which you could pass Server objects (for instance the + FooServer above), and it would handle incoming messages. + <braunr> how is message content mapped to a java interface ? + <jkoenig> this would be determined from the .defs files and MIG would + generate the appropriate code, hopefully. + <braunr> so the demux part would handle rpc integer identifiers ? + <jkoenig> right. + <braunr> but hm + <jkoenig> also mapping .defs files to Java interfaces might prove to be + tricky. data types conversion and all + <antrik> tschwinge: my mamory is rather hazy. IIRC the issue was that the + MIG-generated stubs deallocate out-of-line port arrays after the + implementation returns, before returning to the dispatcher + <braunr> i'll just overlook this specific implementation detail + <jkoenig> but we could use some annotation-based system if we need to + provide more information to generate the java code. + <antrik> but the Hurd (or rather glibc) RPC handling also automatically + deallocates everything if an error occurs + <antrik> so I changed the MIG code to deallocate only when no error occurs + <braunr> jkoenig: ok, we'll talk about that when there is more progress and + you have a better view of the problem + <antrik> at that time I was pretty sure that this is a correctly working + solution, but it always seemed questionable conceptually... however, I + wasn't able to come up with a better one, and nobody else commented on it + <braunr> antrik: shouldn't the hurd be changed not to deallocate something + it didn't allocate in the first place ? + <antrik> braunr: no, the server has to deallocate stuff before returning to + the client. the request message is destroyed before returning the reply. + <tschwinge> jkoenig, braunr: That's what I had in mind where MIG might be a + bit awkward. Then we can indeed either add annotations to the .defs + files, or reproduce them in some other format. That's some work, but + it's mostly a one-time work. + <tschwinge> After all, the RPC interface is a binary one, and there may be + more than one API for creating these messages, etc. + <antrik> jkoenig: actually, at least in the Hurd, server-side and + client-side headers are separate -- so MIG actually creates four files + <jkoenig> tschwinge, wrt to annotations I was more thinking about Java + ones, such as: @MIGDefsFile("mach/task.defs") @MIGCType("task_t") public + interface Task { } + <jkoenig> antrik, oh, ok, it makes sense. + <braunr> jkoenig: anything else ? + <jkoenig> braunr, nothing that I can think of + <braunr> ok + <antrik> tschwinge: I think it would be a *very* bad idea to introduce + redundancy regarding RPC definitions + <braunr> thanks for the tour :) + <antrik> (the _request.defs/_reply.defs mess is bad enough...) + <jkoenig> did I speak about the "Unsafe" pseudo-exception? that's + interesting :-) + <tschwinge> jkoenig: Also, virtual memory abstractions? + <braunr> jkoenig: you didn't + <tschwinge> antrik: Well, then we could create some other super-format. + But that's just a detail IMO. + <jkoenig> ok, so wrt virtual memory, a page we received can be wrapped with + some JNI help into a (direct) ByteBuffer object. + <jkoenig> deallocating sent pages will be tricky, though. + <tschwinge> antrik: To put it this way: for me the .defs files are just one + way of expressing the RPC interfaces' contracts. (At the same time, they + happen to be the actual reference for these, too. But the specification + itself could just as well be a textual one.) + <jkoenig> on approach I've been thinking about would be to "wrap" the + ByteBuffer object into an object which has the sole reference to it, so + that when it's deallocated the reference can be replaced with "null", and + further attempts to access the buffer would throw exceptions. + <braunr> sounds reasonable + <jkoenig> but that's still in flux in my head, we may end up needing our + own implementation of ByteBuffer-like objects. + <tschwinge> The problem being that there is no mechanism to ``revoke'' an + object once a reference to it has been shared. + <jkoenig> right. + <tschwinge> A wrapper is one possibility indeed. + <antrik> tschwinge: they are called interface *definitions* for a reason + :-) + <tschwinge> This is a very similar problem as with capabilities when there + is no revoke operation for these, too. + <tschwinge> antrik: Yes, because they define MIG's input. :-P + <tschwinge> Isn't that what is called a membrane in the capability world? + <antrik> I do not say that we have to consider the format of the .defs to + be set in stone; but I do insist on using a canonical machine-parsable + source for all language bindings + <tschwinge> attenuation + <jkoenig> tschwinge, you mean the revokable proxy contruct ? (It's the same + principle indeed) + <tschwinge> A common design pattern in object-capability systems: given + one reference of an object, create another reference for a proxy object + with certain security restrictions, such as only permitting read-only + access or allowing revocation. The proxy object performs security checks + on messages that it receives and passes on any that are allowed. Deep + attenuation refers to the case where the same attenuation is applied + transitively to any + <tschwinge> objects obtained via the original attenuated object, + typically by use of a "membrane". + <tschwinge> http://en.wikipedia.org/wiki/Object-capability_model + <tschwinge> Yes. + <tschwinge> Good. I understood something. ;-) + <tschwinge> antrik: OKAY! :-P + <tschwinge> jkoenig: And hopefully the JVM will optimize away all the + additional indirection... :-D + <tschwinge> jkoenig: Is there anything more to say about the VM layer? + <jkoenig> tschwinge, "hopefully", yes :-) + <tschwinge> Like, the data that I'm sharing -- is it untyped, isn't it? + <jkoenig> tschwinge, you mean that within the received/sent pages ? + <tschwinge> Yes. + <tschwinge> But that'S how it is, indeed. + <jkoenig> well actually the type descriptor should indicate what they + contain. + <tschwinge> I cannot trust anything I receive from externally. + <jkoenig> it's most often used for MACH_MSG_TYPE_CHAR items I guess, and it + will be type checked when retreive + <tschwinge> Yeah, and that then just *is* arbitrary data, like a block read + from a disk file. + <jkoenig> you would have something like: ByteBuffer + MachMsg.getBuffer(MachMsg.Type expected), and MachMsg would check the + type descriptor against that which you specified + <tschwinge> Or a packet transmitted over the network. + <tschwinge> OK, yes. + <antrik> jkoenig: in theory ints should be used quite often too. the whole + purpose of the type descriptors is to allow byte order swapping when + messages are passed between hosts with different architecture... + <jkoenig> tschwinge, right, except for out-of-line port arrays, which need + to be handled differently obviously. + <antrik> (which is totally irrelevat for our purposes -- especially since + the actual network IPC code doesn't exist anymore ;-) ) + <jkoenig> antrik, oh, interesting + <tschwinge> Yes, that was one original idea. + <jkoenig> actually my litmus test for what the bindings should be, is you + should be able to implement such a proxy in Java :-) + <tschwinge> antrik: And hey, you now have processors that can switch + between different modes during runtime... :-) + <jkoenig> (although arguably that's a little bit ambitious) + <braunr> tschwinge: there should be bits in page tables to indicate the + endianness to use on a page .. :) + <tschwinge> Hehe! + <tschwinge> jkoenig: Don't worry -- you're already known for ambitious + projects. One more can't hurt. + <jkoenig> Also, actually the word size is not something that I've been able + to abstract so far, so I'll be hardcoding little-endian 32 bits for now. + <braunr> why is that ? + <antrik> some of the Hurd RPC break the idea anyways BTW + <jkoenig> the org.vmmagic package (from Jikes RVM and JNode) could help + with that, but GCJ does not support it unfortunately (not sure about + OpenJDK) + <jkoenig> braunr, Java does not allow us to define new unboxed types + <braunr> jkoenig: does it have its own definition of the word size ? + <jkoenig> braunr, nope. + <jkoenig> (although, maybe, and also we could use JNI to query it) + <braunr> even if virtual, i'd expect a machine to have such a defnition + <jkoenig> braunr, maybe it has, but basically in Java nothing depends on + the word size + <jkoenig> 'int' is 32 bits, 'long' is 64 and that's it. + <braunr> oh right, i remember most types are fixed size, right ? + <jkoenig> right. + <braunr> if not all + <jkoenig> now Jikes RVM's "org.vmmagic" provides an interface to defined + new unboxed types which can depend on the actual word size, but Jikes RVM + is its own JVM so obviously they can use and provide whatever extensions + they need :-) + <jkoenig> (but maybe they've implemented them in OpenJDK for bootstrap + purposes, I'm not sure) + <tschwinge> I'm missing this detail: where does the word size come into + play here? + <jkoenig> anyway, I _could_ indiscriminately use 'long' for port names, and + sparkle the code with word size tests but that would be very clumsy + <braunr> jkoenig: port names are actually ints :/ + <jkoenig> tschwinge, the actual format of the message header and type + descriptors, for instance. + <braunr> jkoenig: ok, got your point + <jkoenig> braunr, by 'long' I mean 64-bits integers (which they are on + 64-bits machines I think?) + <braunr> :) + <braunr> jkoenig: port names are as large as the word size + <braunr> but in C at least, they're int, not long + <braunr> it doesn't change many things, but you get lots of warnings if you + try with a long :) + <tschwinge> What is the reason that port names are an + architecture-dependent word size's width, and not simply 32 bit? + <jkoenig> "4 billions of port names should be enough for everyone" :-) + <braunr> tschwinge: an optimization is to use them as pointers in the + kernel + <antrik> tschwinge: the machine's native word size is what it can process + most efficiently, and what should be used for most normal + operations... it makes sense to define stuff as int, except for network + communication + <tschwinge> jkoenig: Well, yeah, but if you want to communicate with a + peer, you have to agree on the maximum number anyway (not for port names, + though, which are local). + <braunr> antrik: int isn't the word size everywhere + <braunr> antrik: the most common type matching the word size is long, at + least on ILP32/LP64 data models + <antrik> braunr: that's just because some idiots assumed int would always + be 32 bits, and consequently when 64 architectures came up the compiler + guys chickened out ;-) + <braunr> without int, you wouldn't have a 32 bits type + <antrik> that's not true for all architectures and/or operating systems + though AFAIK + <braunr> or a 16 bits one + <braunr> antrik: windows guys got even more scared, so windows 64 is LLP64 + <antrik> BTW, I haven't checked, but it's quite possible that 32 bit + numbers are actually preferable even on AMD64... + <tschwinge> jkoenig: So, back on track. :-) + <tschwinge> jkoenig: You didn't find anything yet in Mach's VM interfaces + as well a MemoryObject, etc., that can't be used/implemented in the Java + world? + <braunr> antrik: they consume less memory, but don't have much effect on + performance + <jkoenig> tschwinge, once we have the basic system calls and the + corresponding abstractions in place, I don't think anything else + fundamentally problematic could possibly show up + <antrik> braunr: if you really *need* a type of a certain bit size, you + should use stdint types. so not having a 16 or 32 bit type in the + short/int/long canon is *not* an excuse + <tschwinge> jkoenig: That speaks for the Mach designers! + <braunr> antrik: right + <jkoenig> tschwinge, on trick is that for instance, mach_task_self would + still be unsafe even if it returned a nicely wrapped Task object, because + you could still wreck your own address space and threads with it. So we + would need the "attenuation" pattern mentionned above to provide a safe + one. + <jkoenig> (which would disallow thinks such as the port/thread/vm calls) + <braunr> jkoenig: you mentioned the unsafe pseudo exception earlier + <jkoenig> braunr, right, so the issue is with distinguishing safe from + unsafe methods + <antrik> braunr: BTW, the Windows guys actually broke a lot of stuff by + fixing long at 32 bits -- this way long doesn't match size_t and pointer + types anymore, which was an assumption that was true for pretty much any + system so far... + <tschwinge> jkoenig: Yes. (And again hope for the JVM to optim...) + <braunr> antrik: that's right :) + <braunr> antrik: that's LLP64 + <braunr> antrik: long long and pointers + <jkoenig> braunr, so basically the idea is that unsafe methods are declared + as "throws Unsafe" + <jkoenig> the effect is that if you use such a method you must either + "throw Unsafe" yourself, + <jkoenig> or if you're building a safe abstraction on top of Unsafe + methods, you'll "catch" the "exception" in question to tell the compiler + that it's okay. + <jkoenig> it's more or less inspired from the "semantic regimes" idea from + the org.vmmagic paper which is referenced in my original proposal, + <jkoenig> only implementing by hijacking the exception checking machinery, + which has a behaviour similar to what we want. + <braunr> ok + <braunr> but hmm this seems pretty normal, what's the tricky part ? :) + <tschwinge> braunr: The idea is that the programmer explicitly has to + acknowledge if he'S using an unsafe interface. + <braunr> tschwinge: sounds pretty normal too + <jkoenig> braunr, the trick is that you would not usually declare + exceptions which are never actually thrown (and actually since the + compiler does not know it's never thrown, I need to work around it in a + few places) + <braunr> oh, ok + <braunr> jkoenig: that's interesting indeed + <jkoenig> braunr, the org.vmmagic paper provides an example which uses some + annotations called @UncheckedMemoryAccess and @AssertSafe to the same + effect (which is kind of cleaner), but it would be a headache to + implement without help from the compiler I think (as far as I can tell + the annotation processor would have to inspect the bytecode) + <braunr> but hm + <braunr> what's the true problem about this ? + <jkoenig> (the paper advocates "high-level low-level programming" and is a + very interesting read I think, + http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.151.5253&rep=rep1&type=pdf, + for what it's worth) + <braunr> what's wrong if you just declare your methods unsafe and don't + alter anything else ? + <tschwinge> Yes, I read it and it is interesting. Unfortunately, it seems + I forgot most of it again... + <jkoenig> braunr, declare? alter? + <jkoenig> you mean just tag them with an annotation? + <braunr> just stating a method "throws Unsafe" + <jkoenig> braunr, well some compiler will output a warning because they can + tell there's no way the method is going to throw such an exception. + <jkoenig> and then some other compiler will complain that my + @SuppressWarnings("unused") does not serve any purpose to them :-) + <jkoenig> also, when initializing final fields, I need to work around the + fact that the compiler thinks "Unsafe" might be thrown. + <jkoenig> see for instance MachPort.DEAD + <braunr> jkoenig: ok + <jkoenig> braunr, but I'm more than willing to accept this in exchange for + a clear, compiler-enforced materialization of the border between safe an + unsafe code. + <jkoenig> actually another question I have is the amount of static typing I + should add to the safe version, for instance should I subclass MachPort + into MachSendRight, MachReceiveRight and so on. I don't want to depart + from the C inteface too much but it could be useful. + <braunr> jkoenig: can't answer that :) + <braunr> jkoenig: keep them in mind for later i think + <tschwinge> jkoenig: What's the safety concern w.r.t. having MachPort (not) + final? + <jkoenig> tschwinge, actually I'm partly wrong in that we only need name() + and a couple other methods to be final + <tschwinge> jkoenig: That's what I was thinking. :-) + <tschwinge> I though I'm missing something here. + <jkoenig> tschwinge, the idea is that the user (ie., the adversary :-) + could extend MachPort and inject their own fake port name into messages + <jkoenig> by overriding name() or clear() + <tschwinge> Yeah, but if these are final, that's not possible. + <jkoenig> right. + <tschwinge> And that *should* be enough, I think. + <tschwinge> Unless I'm missing something. + <jkoenig> I don't think so. Also I hope it is, because as mentionned above + there might be some value in subclassing MachPort. + <tschwinge> Yep. + <jkoenig> incidentally, declaring the class or the method final will allow + the JVM to inline them I think. + <tschwinge> It will help the JVM, yes. It can also figure that out without + final, though. (And may have to de-optimize the code again in case there + are additional classes loaded during run-time.) + <tschwinge> jkoenig: The reference counting in MachPort. I think I'm + beginning to understand this. + <jkoenig> oh ok + <jkoenig> tschwinge, yes the javadoc is maybe a bit obscure so far. + <jkoenig> but basically you don't want the port name you acquire to become + invalid before you're done using it. + <tschwinge> But how is this different from the C world? + <jkoenig> here my goal is to provide some guarantees if you use only safe + methods + <jkoenig> like, you can't forge a port name and things like that + <jkoenig> so basically it should never be possible to include an invalid + port name in a message if you use only safe methods. + <tschwinge> Ah, I see! + <tschwinge> Now that does make sense. + <jkoenig> but the mechanism in itself is similar to the Hurd port cells and + user_link structures + <tschwinge> It's again ``only'' helping the programmer. + <jkoenig> right, no object-capability ulterior motives :-) + <jkoenig> another assumption which the javadoc does not state yet it that + basically there should be exactly one MachPort object for each mach-level + port name reference (in the sense of mach_port_mod_refs) + <tschwinge> Yes, I figured out that bit. diff --git a/user/jkoenig/java/java-access-bridge.mdwn b/user/jkoenig/java/java-access-bridge.mdwn new file mode 100644 index 00000000..57c87068 --- /dev/null +++ b/user/jkoenig/java/java-access-bridge.mdwn @@ -0,0 +1,92 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_porting]] + +Debian's *openjdk-7-jre* package depends on *libaccess-bridge-java-jni* (source +package: *java-access-bridge*). + +The latter one has *openjdk-6-jdk* as a build dependency, but that can be +hacked around: + + # ln -s java-7-openjdk /usr/lib/jvm/java-6-openjdk + +Trying to build it: + + $ LD_LIBRARY_PATH=/usr/lib/jvm/java-7-openjdk/jre/lib/i386/jli dpkg-buildpackage -b -uc -d + [...] + make[3]: Entering directory `/media/erich/home/thomas/tmp/libaccess-bridge-java-jni/java-access-bridge-1.26.2/idlgen' + /usr/lib/jvm/java-6-openjdk/bin/idlj \ + -pkgPrefix Bonobo org.GNOME \ + -pkgPrefix Accessibility org.GNOME \ + -emitAll -i /usr/share/idl/bonobo-activation-2.0 -i /usr/share/idl/at-spi-1.0 -i /usr/share/idl/bonobo-2.0 \ + -fallTie /usr/share/idl/at-spi-1.0/Accessibility.idl + /usr/share/idl/at-spi-1.0/Accessibility_Collection.idl (line 66): WARNING: Identifier `object' collides with a keyword; use an escaped identifier to ensure future compatibility. + boolean isAncestorOf (in Accessible object); + ^ + /usr/share/idl/at-spi-1.0/Accessibility_Component.idl (line 83): WARNING: Identifier `Component' collides with a keyword; use an escaped identifier to ensure future compatibility. + interface Component : Bonobo::Unknown { + ^ + Exception in thread "main" java.lang.AssertionError: Platform not recognized + at sun.nio.fs.DefaultFileSystemProvider.create(DefaultFileSystemProvider.java:71) + at java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:108) + at java.nio.file.FileSystems$DefaultFileSystemHolder.access$000(FileSystems.java:89) + at java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:98) + at java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:96) + at java.security.AccessController.doPrivileged(Native Method) + at java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(FileSystems.java:95) + at java.nio.file.FileSystems$DefaultFileSystemHolder.<clinit>(FileSystems.java:90) + at java.nio.file.FileSystems.getDefault(FileSystems.java:176) + at sun.util.calendar.ZoneInfoFile$1.run(ZoneInfoFile.java:489) + at sun.util.calendar.ZoneInfoFile$1.run(ZoneInfoFile.java:480) + at java.security.AccessController.doPrivileged(Native Method) + at sun.util.calendar.ZoneInfoFile.<clinit>(ZoneInfoFile.java:479) + at sun.util.calendar.ZoneInfo.getTimeZone(ZoneInfo.java:658) + at java.util.TimeZone.getTimeZone(TimeZone.java:559) + at java.util.TimeZone.setDefaultZone(TimeZone.java:656) + at java.util.TimeZone.getDefaultRef(TimeZone.java:623) + at java.util.TimeZone.getDefault(TimeZone.java:610) + at java.text.SimpleDateFormat.initializeCalendar(SimpleDateFormat.java:682) + at java.text.SimpleDateFormat.<init>(SimpleDateFormat.java:619) + at java.text.DateFormat.get(DateFormat.java:772) + at java.text.DateFormat.getDateTimeInstance(DateFormat.java:547) + at com.sun.tools.corba.se.idl.toJavaPortable.Util.writeProlog(Util.java:1139) + at com.sun.tools.corba.se.idl.toJavaPortable.Skeleton.writeHeading(Skeleton.java:145) + at com.sun.tools.corba.se.idl.toJavaPortable.Skeleton.generate(Skeleton.java:102) + at com.sun.tools.corba.se.idl.toJavaPortable.InterfaceGen.generateSkeleton(InterfaceGen.java:159) + at com.sun.tools.corba.se.idl.toJavaPortable.InterfaceGen.generate(InterfaceGen.java:108) + at com.sun.tools.corba.se.idl.InterfaceEntry.generate(InterfaceEntry.java:110) + at com.sun.tools.corba.se.idl.toJavaPortable.ModuleGen.generate(ModuleGen.java:75) + at com.sun.tools.corba.se.idl.ModuleEntry.generate(ModuleEntry.java:83) + at com.sun.tools.corba.se.idl.Compile.generate(Compile.java:324) + at com.sun.tools.corba.se.idl.toJavaPortable.Compile.start(Compile.java:169) + at com.sun.tools.corba.se.idl.toJavaPortable.Compile.main(Compile.java:146) + make[3]: *** [org/GNOME/Accessibility/Accessible.java] Error 1 + make[3]: Leaving directory `/media/erich/home/thomas/tmp/libaccess-bridge-java-jni/java-access-bridge-1.26.2/idlgen' + make[2]: *** [all-recursive] Error 1 + make[2]: Leaving directory `/media/erich/home/thomas/tmp/libaccess-bridge-java-jni/java-access-bridge-1.26.2/idlgen' + make[1]: *** [all-recursive] Error 1 + make[1]: Leaving directory `/media/erich/home/thomas/tmp/libaccess-bridge-java-jni/java-access-bridge-1.26.2' + make: *** [debian/stamp-makefile-build] Error 2 + dpkg-buildpackage: error: debian/rules build gave error exit status 2 + + +IRC, freenode, #hurd, 2011-08-10: + + < jkoenig> and with my latest fix (hardwire os.name as "Linux"), + java-access-bridge actually built \o/ + < youpi> I wouldn't call it a "fix" :) + < jkoenig> true, but pretty much everything assumes we're either solaris, + linux or windows :-/ + < jkoenig> also we're actually using the Linux code which it is used to + select throughout the JDK + < jkoenig> if it's any consolation, os.version stays "GNU-Mach + 1.3.99/Hurd-0.3" :-) + < youpi> ideally it should simply be changed to "GNU" diff --git a/user/jkoenig/java/proposal.mdwn b/user/jkoenig/java/proposal.mdwn new file mode 100644 index 00000000..feb7e9dc --- /dev/null +++ b/user/jkoenig/java/proposal.mdwn @@ -0,0 +1,629 @@ +[[!tag stable_URL]] + +# Java for Hurd (and vice versa) + +Contact information: + + * Full name: Jérémie Koenig + * Email: jk@jk.fr.eu.org + * IRC: jkoenig on Freenode and OFTC + +## Introductions + +I am a first year M.Sc. student +in Computer Science at University of Strasbourg (France). +My interests include capability-based security, +programming languages and formal methods +(in particular, object-capability languages and proof-carrying code). + +### Proposal summary + +This project would consist in improving Java support on Hurd. +The first part would consist in +fixing bugs and porting Java-related packages. +The second part would consist in +creating low-level Java bindings for the Hurd interfaces, +as well as libraries to make translator development easier. + +### Previous involvement + +I started contributing to Hurd last summer, +during which I participated to Google Summer of Code +as a student for the Debian project. +I worked on porting Debian-Installer to Hurd. +This project was mostly a success, +although we still have to use a special mirror for installation +with a few modified packages +and tweaked priorities +to work around some uninstallable packages +with Priority: standard. + +Shortly afterwards, +I rewrote the procfs translator +to fix some issues with memory leaks, +make it more reliable, +and improve compatibility with Linux-based tools +such as `procps` or `htop`. + +Although I have not had as much time +as I would have liked to dedicate to the Hurd +since that time, +I have continued to maintain the mirror in question, +and I have started to work +on implementing POSIX threads signal semantics in glibc. + +### Project-related skills and interests + +I have used Java mostly for university assignments. +This includes non-trivial projects +using threads and distributed programming frameworks +such as Java RMI or CORBA. +I have also used it to experiment with +Google App Engine +(web applications) +and Google Web Toolkit +(a compiler from Java to Javascript which helps with AJAX code), +and I have some limited experience with JNI +(the Java Native Interface, to link Java with C code). + +My knowledge of the Hurd and Debian GNU/Hurd is reasonable, +as the Debian-Installer and procfs projects +gave me the opportunity to fiddle with many parts of the system. + +Initially, +I started working on this project because I wanted to use +[Joe-E](http://code.google.com/p/joe-e/) +(a subset of Java) +to investigate the potential +[[applications of object-capability languages|objcap]] +in a Hurd context. +I also believe that improving Java support on Hurd +would be an important milestone. + +### Organisational matters + +I am subscribed to bug-hurd@g.o and +I do have a permanent internet connexion. + +I would be able to attend the regular IRC meetings, +and otherwise communicate with my mentor +through any means they would prefer +(though I expect email and IRC would be the most practical). +Since I'm already familiar with the Hurd, +I don't expect I would require too much time from them. + +My exams end on May 20 so I would be able to start coding +right at the beginning of the GSoC period. +Next year's term would probably begin around September 15, +so that would not be an issue either. +I expect I would work around 40 hours per week, +and my waking hours would be flexible. + +I don't have any other plans for the summer +and would not make any if my project were to be accepted. + +Full disclosure: +I also submitted a proposal to the Jikes RVM project +(which is a research-oriented Java Virtual Machine, +itself written in Java) +for implementing a new garbage collector into the MMTk subsystem. + +## Improve Java support + +### Justification + +Java is a popular language and platform used by many desktop and web +applications (mostly on the server side). As a consequence, competitive Java +support is important for any general-purpose operating system. +Better Java support would also be a prerequisite +for the second part of my proposal. + +### Current situation + +Java is currently supported on Hurd with the GNU Java suite: + + * [GCJ](http://gcc.gnu.org/java/), + the GNU Compiler for Java, is part of GCC and can compile Java + source code to Java bytecode, and both source code and bytecode to + native code; + * libgcj is the implementation of the Java runtime which GCJ uses. + It is based on [GNU Classpath](http://www.gnu.org/software/classpath/). + It includes a bytecode interpreter which enables + Java applications compiled to native code to dynamically load and execute + Java bytecode from class files. + * The gij command is a wrapper around the above-mentioned virtual machine + functionality of libgcj and can be used as a replacement for the java + command. + +However, GCJ does not work flawlessly on Hurd.r +For instance, some parts of libgcj relies on +the POSIX threads signal semantics, which are not yet implemented. +In particular, this makes ant hang waiting for child processes, +which makes some packages fail to build on Hurd +(“ant” is the “make” of the Java world). + +### Tasks + + * **Finish implementing POSIX thread semantics** in glibc (high priority). + According to POSIX, signal dispositions should be global to a process, + while signal blocking masks should be thread-specific. Signals sent to the + process as a whole are to be delivered to any thread which does not block + them. By contrast, Hurd has per-thread signal dispositions and signals + sent to a process are delivered to the main thread only. I have been + working on refactoring the glibc signal code and implementing the POSIX + semantics as a per-thread option. However, due to lack of time I have not + yet been able to test and debug my code properly. Finishing this work + would be my first task. + * **Fix further problems with GCJ on Hurd** (high priority). While I’m not + aware of any other problems with GCJ at the moment, I suspect some might + turn up as I progress with the other tasks. Fixing these problems would + also be a high-priority task. + * **Port OpenJDK 6** (medium priority). While GCJ is fine, it is not yet + 100% complete. It is also slower than OpenJDK on architectures where a + just-in-time compiler is available. Porting OpenJDK would therefore + improve Java support on Hurd in scope and quality. Besides, it would also + be a good way to test GCJ, which is used for bootstrapping by the Debian + OpenJDK packages. Also note that OpenJDK 6 is now the default Java + Runtime Environment on all released Linux-based Debian architectures; + bringing Hurd in line with this would probably be a good thing. + * **Port Eclipse and other Java applications** (low priority). Eclipse is a + popular, state-of-the-art IDE and tool suite used for Java and other + languages. It is a dependency of the Joe-E verifier (see part 3 of this + proposal). Porting Eclipse would be a good opportunity to test GCJ and + OpenJDK. + +### Deliverables + + * The glibc pthreads patch and any other fixes on the Hurd side + would be submitted upstream + * Patches against Debian source packages + required to make them build on Hurd would be submitted + to the [Debian bug tracking system](http://bugs.debian.org/). + + +## Create Java bindings for the Hurd interfaces + +### Justification + +Java is used for many applications and often taught to +introduce object-oriented programming. The fact that Java is a +garbage-collected language makes it easier to use, especially for the less +experienced programmers. Besides, its object-oriented nature is a +natural fit for the capability-based design of Hurd. +The JVM is also used as a target for many other languages, +all of which would benefit from the access provided by these bindings. + +Advantages over other garbage-collected, object-oriented languages include +performance, type safety and the possibility to compile a Java translator to +native code and +[link it statically](http://gcc.gnu.org/wiki/Statically_linking_libgcj) +using GCJ, should anyone want to use a +translator written in Java for booting. +Note that Java is +[being](http://www.linuxjournal.com/article/8757) +[used](http://oss.readytalk.com/avian/) +in this manner for embedded development. +Since GCJ can take bytecode as its input, +this expect this possibility would apply to any JVM-based language. + +Java bindings would lower the bar for newcomers +to begin experimenting with what makes Hurd unique +without being faced right away with the complexity of +low-level systems programming. + +### Tasks summary + + * Implement Java bindings for Mach + * Implement a libports-like library for Java + * Modify MIG to output Java code + * Implement libfoofs-like Java libraries + +### Design principles + +The principles I would use to guide the design +of these Java bindings would be the following ones: + + * The system should be hooked into at a low level, + to ensure that Java is a "first class citizen" + as far as the access to the Hurd's interfaces is concerned. + * At the same time, the memory safety of Java should be maintained + and extended to Mach primitives such as port names and + out-of-line memory regions. + * Higher-level interfaces should be provided as well + in order to make translator development + as easy as possible. + * A minimum amount of JNI code (ie. C code) should be used. + Most of the system should be built using Java itself + on top of a few low-level primitives. + * Hurd objects would map to Java objects. + * Using the same interfaces, + objects corresponding to local ports would be accessed directly, + and remote objects would be accessed over IPC. + +One approach used previously to interface programming languages with the Hurd +has been to create bindings for helper libraries such as libtrivfs. Instead, +for Java I would like to take a lower-level approach by providing access to +Mach primitives and extending MIG to generate Java code from the interface +description files. + +This approach would be initially more involved, and would introduces several +issues related to overcoming the "impedance mismatch" between Java and Mach. +However, once an initial implementation is done it would be easier to maintain +in the long run and we would be able to provide Java bindings for a large +percentage of the Hurd’s interfaces. + +### Bindings for Mach system calls + +In this low-level approach, my intention is to enable Java code to use Mach +system calls (in particular, mach_msg) more or less directly. This would +ensure full access to the system from Java code, but it raises a number of +issues: + + * the Java code must be able to manipulate Mach-level entities, such as port + rights or page-aligned buffers mapped outside of the garbage-collected + heap (for out-of-line transfers); + * putting together IPC messages requires control of the low-level + representation of data. + +In order to address these concerns, classes would be encapsulating these +low-level entities so that they can be referenced through normal, safe objects +from standard Java code. Bindings for Mach system calls can then be provided +in terms of these classes. Their implementation would use C code through the +Java Native Interface (JNI). + +More specifically, this functionality would be provided by the `org.gnu.mach` +package, which would contain at least the following classes: + + * `MachPort` would encapsulate a `mach_port_t`. (Some of) its constructors + would act as an interface for the `mach_port_allocate()` system call. + `MachPort` objects would also be instantiated from other parts of the JNI + C code to represent port rights received through IPC. The `deallocate()` + method would call `mach_port_deallocate()` and replace the encapsulated + port name with `MACH_PORT_DEAD`. We would recommend that users call it + when a port is no longer used, but the finalizer would also deallocate the + port when the `MachPort` object is garbage collected. + * `Buffer` would represent a page-aligned buffer allocated outside of the + Java heap, to be transferred (or having been received) as out-of-line + memory. The JNI code would would provide methods to read and write data at + an arbitrary offset (but within bounds) and would use `vm_allocate()` and + `vm_deallocate()` in the same spirit as for `MachPort` objects. + * `Message` would allow Java code to put together Mach messages. The + constructor would allocate a `byte[]` member array of a given size. + Additional methods would be provided to fill in or query the information + in the message header and additional data items, including `MachPort` and + `Buffer` objects which would be translated to the corresponding port names + and out-of-line pointers. + A global map from port names to the corresponding `MachPort` object + would probably be needed to ensure that there is a one-to-one + correspondence. + * `Syscall` would provide static JNI methods for performing system calls not + covered by the above classes, such as `mach_msg()` or + `mach_thread_self()`. These methods would accept or return `MachPort`, + `Buffer` and `Message` objects when appropriate. The associated C code + would access the contents of such objects directly in order to perform the + required unsafe operations, such as constructing `MachPort` and `Buffer` + objects directly from port names and C pointers. + +Note that careful consideration should be given to the interfaces of these +classes to avoid “safety leaks” which would compromise the safety guarantees +provided by Java. Potential problematic scenarios include the following +examples: + + * It must not be possible to write an integer at some position in a + `Message` object, and to read it back as a `MachPort` or `Buffer` object, + since this would allow unsafe access to arbitrary memory addresses and + mach port names. + * Providing the `mach_task_self()` system call would also provide access to + arbitrary addresses and ports by using the `vm_*` family of RPC operations + with the returned `MachPort` object. This means that the relevant task + operations should be provided by the `Syscall` class instead. + +Finally, access should be provided to the initial ports and file descriptors +in `_hurd_ports` and provided by the `getdport()` function, +for instance through static methods such as +`getCRDir()`, `getCWDir()`, `getProc()`, ... in a dedicated class such as +`org.gnu.hurd.InitPorts`. + +A realistic example of code based on such interfaces would be: + + import org.gnu.mach.MsgType; + import org.gnu.mach.MachPort; + import org.gnu.mach.Buffer; + import org.gnu.mach.Message; + import org.gnu.mach.Syscall; + import org.gnu.hurd.InitPorts; + + public class Hello + { + public static main(String argv[]) + /* Parent class for all Mach-related exceptions */ + throws org.gnu.mach.MachException + { + /* Allocate a reply port */ + MachPort reply = new MachPort(); + + /* Allocate an out-of-line buffer */ + Buffer data = new Buffer(MsgType.CHAR, 13); + data.writeString(0, "Hello, World!"); + + /* Craft an io_write message */ + Message msg = new Message(1024); + msg.setRemotePort(InitPorts.getdport(1)); + msg.setLocalPort(reply, Message.Type.MAKE_SEND_ONCE); + msg.setId(21000); + msg.addBuffer(data); + + /* Make the call, MACH_MSG_SEND | MACH_MSG_RECEIVE */ + Syscall.machMsg(msg, true, true, reply); + + /* Extract the returned value */ + msg.assertId(21100); + int retCode = msg.readInt(0); + int amount = msg.readInt(1); + } + } + +Should this paradigm prove insufficient, +more ideas could be borrowed from the +[`org.vmmagic`](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.151.5253&rep=rep1&type=pdf) +package used by [Jikes RVM](http://jikesrvm.org/), +a research Java virtual machine itself written in Java. + +### Generating Java stubs with MIG + +Once the basic machinery is in place to interface with Mach, Java programs +have more or less equal access to the system functionality without resorting +to more JNI code. However, as illustrated above, this access is far from +convenient. + +As a solution I would modify MIG to add the option to output Java code. MIG +would emit a Java interface, a client class able to implement the interface +given a Mach port send right, an a server class which would be able to handle +incoming messages. The class diagram below, although it is by no means +complete or exempt of any problem, illustrates the general idea: + +[[gsoc2011_classes.png]] + +This structure is somewhat reminiscent of +[Java RMI](http://en.wikipedia.org/wiki/Java_remote_method_invocation) +or similar systems, +which aim to provide more or less transparent access to remote objects. +The exact way the Java code would be generated still needs to be determined, +but basically: + + * An interface, corresponding to the header files generated by MIG, would + enumerate the operations listed in a given .defs files. Method names would + be transformed to adhere to Java conventions (for instance, + `some_random_identifier` would become `someRandomIdentifier`). + * A user class, corresponding to the `*User.c` files, + would implement this interface by doing RPC over a given MachPort object. + * A server class, corresponding to `*Server.c`, would be able to handle + incoming messages using a user-provided implementation of the interface. + (Possibly, a skeleton class providing methods which would raise + `NotImplementedException`s would be provided as well. + Users would derive from this class and override the relevant methods. + This would allow them not to implement some operations, + and would avoid pre-existing code from breaking when new operations are + introduced.) + +In order to help with the implementation of servers, some kind of library +would be needed to associate Mach receive rights with server objects and to +handle incoming messages on dedicated threads, in the spirit of libports. +This would probably require support for port sets at the level of the Mach +primitives described in the previous section. + +When possible, operations involving the transmission of send rights +of some kind would be expressed in terms of the MIG-generated interfaces +instead of `MachPort` objects. +Upon reception of a send right, +a `FooUser` object would be created +and associated with the corresponding `MachPort` object. +If the received send right corresponds to a local port +to which a server object has been associated, +this object would be used instead. +This way, +subsequent operations on the received send right +would be handled as direct method calls +instead of going through RPC mechanisms. + +Some issues will still need to be solved regarding how MIG will convert +interface description files to Java interfaces. For instance: + + * `.defs` files are not explicitly associated with a type. For instance in + the example above, MIG would have to somehow infer that io_t corresponds + to `this` in the `Io` interface. + * More generally, a correspondence between MIG and Java types would have + to be determined. Ideally this would be automated and not hardcoded + too much. + * Initially, reply port parameters would be ignored. However they may be + needed for some applications. + +So the details would need to be flushed out during the community bonding +period and as the implementation progresses. However I’m confident that a +satisfactory solution can be designed. + +Using these new features, the example above could be rewritten as: + + import org.gnu.hurd.InitPorts; + import org.gnu.hurd.Io; + import org.gnu.hurd.IoUser; + + class Hello { + static void main(String argv[]) throws ... + { + Io stdout = new IoUser(InitPorts.getdport(1)); + String hello = “Hello, World!\n”; + + int amount = stdout.write(hello.getBytes(), -1); + + /* (A retCode corresponding to an error + would be signalled as an exception.) */ + } + } + +An example of server implementation would be: + + import org.gnu.hurd.Io; + import java.util.Arrays; + + class HelloIo implements Io { + final byte[] contents = “Hello, World!\n”.getBytes(); + + int write(byte[] data, int offset) { + return SOME_ERROR_CODE; + } + + byte[] read(int offset, int amount) { + return Arrays.copyOfRange(contents, offset, + offset + amount - 1); + } + + /* ... */ + } + +A new server object could then be created with `new IoServer(new HelloIo())`, +and associated with some receive right at the level of the ports management +library. + +### Base classes for common types of translators + +Once MIG can target Java code, and a libports equivalent is available, +creating new translators in Java would be greatly facilitated. However, +we would probably want to introduce basic implementations of file system +translators in the spirit of libtrivfs or libnetfs. They could take the form +of base classes implementing the relevant MIG-generated interfaces which +would then be derived by users, +or could define a simpler interface +which would then be used by adapter classes +to implement the required ones. + +I would draw inspiration from libtrivfs and libnetfs +to design and implement similar solutions for Java. + +### Deliverables + + * A hurd-java package would contain the Java code developed + in the context of this project. + * The Java code would be documented using javadoc + and a tutorial for writing translators would be written as well. + * Modifications to MIG would be submitted upstream, + or a patched MIG package would be made available. + +The Java libraries resulting from this work, +including any MIG support classes +as well as the class files built from the MIG-generated code +for the Mach and Hurd interface definition files, +would be provided as single `hurd-java` package for +Debian GNU/Hurd. +This package would be separate from both Hurd and Mach, +so as not to impose unreasonable build dependencies on them. + +I expect I would be able to act as its maintainer in the foreseeable future, +either as an individual or as a part of the Hurd team. +Hopefully, +my code would be claimed by the Hurd project as their own, +and consequently the modifications to MIG +(which would at least conceptually depend on the Mach Java package) +could be integrated upstream. + +Since by design, +the Java code would use only a small number of stable interfaces, +it would not be subject to excessive amounts of bitrot. +Consequently, +maintenance would primarily consist in +fixing bugs as they are reported, +and adding new features as they are requested. +A large number of such requests +would mean the package is useful, +so I expect that the overall amount of work +would be correlated with the willingness of more people +to help with maintenance +should I become overwhelmed or get hit by a bus. + + +## Timeline + +The dates listed are deadlines for the associated tasks. + + * *Community bonding period.* + Discuss, refine and complete the design of the Java bindings + (in particular the MIG and "libports" parts) + * *May 23.* + Coding starts. + * *May 30.* + Finish implementing pthread signal semantics. + * *June 5.* + Port OpenJDK + * *June 12.* + Fix the remaining problems with GCJ and/or OpenJDK, + possibly port Eclipse or other big Java packages. + * *June 19.* + Create the bindings for Mach. + * *June 26.* + Work on some kind of basic Java libports + to handle receive rights. + * *July 3.* + Test, write some documentation and examples. + * *July 17 (two weeks).* + Add the Java target to MIG. + * *July 24.* + Test, write some documentation and examples. + * *August 7 (two weeks).* + Implement a modular libfoofs to help with translator development. + Try to write a basic but non-trivial translator + to evaluate the performance and ease of use of the result, + rectify any rough edges this would uncover. + * *August 22. (last two weeks)* + Polish the code and packaging, + finish writing the documentation. + + +## Conclusion + +This project is arguably ambitious. +However, I have been thinking about it for some time now +and I'm confident I would be able to accomplish most of it. + +In the event multiple language bindings projects +would be accepted, +some work could probably be done in common. +In particular, +[ArneBab](http://www.bddebian.com/~hurd-web/community/weblogs/ArneBab/2011-04-06-application-pyhurd/) +seems to favor a low-level approach for his Python bindings as I do for Java, +and I would be happy to discuss API design and coordinate MIG changes with him. +I would also have an extra month after the end of the GSoC period +before I go back to school, +which I would be able to use to finish the project +if there is some remaining work. +(Last year's rewrite of procfs was done during this period.) + +As for the project's benefits, +I believe that good support for Java +is a must-have for the Hurd. +Java bindings would also further the Hurd's agenda +of user freedom by extending this freedom to more people: +I expect the set of developers +who would be able to write Java code against a well-written libfoofs +is much larger than +those who master the intricacies of low-level systems C programming. +From a more strategic point of view, +this would also help recruit new contributors +by providing an easier path to learning the inner workings of the Hurd. + +Further developments +which would build on the results of this project +include my planned [[experiment with Joe-E|objcap]] +(which I would possibly take on as a university project next year). +Another possibility would be to reimplement some parts +of the Java standard library +directly in terms of the Hurd interfaces +instead of using the POSIX ones through glibc. +This would possibly improve the performance +of some Java applications (though probably not by much), +and would otherwise be a good project +for someone trying to get acquainted with Hurd. + +Overall, I believe this project would be fun, interesting and useful. +I hope that you will share this sentiment +and give me the opportunity to spend another summer working on Hurd. + diff --git a/user/jkoenig/objcap.mdwn b/user/jkoenig/objcap.mdwn new file mode 100644 index 00000000..e4cd20e8 --- /dev/null +++ b/user/jkoenig/objcap.mdwn @@ -0,0 +1,85 @@ + +# Potential applications of object-capability languages + +The work discussed is this last part would have +fewer immediate benefits for the Hurd project +and has more of a research orientation. +It is also unlikely that there would be any time remaining +to work on it at the end of the summer. +(Though it could work as some kind of reward +if I somehow managed to do a prefect job of all the rest +within the allocated time :-) ). +As a consequence, +I don't really consider this a part of my application. + +This being said, +to some extent the project discussed here +will informed the way I design the Java bindings, +since it depends on them +and I intend to work on this at some point in the future. +I also believe it touches on some interesting ideas, +and a Summer of Code application is probably +as good an occasion as any to discuss them. + +### Justification + +The primary advantage of multi-server operating systems is the ability to +break what used to be the kernel into small pieces which can be isolated +from each others. This makes sense from an engineering perspective, as +smaller components can be swapped with different implementations and reduce +the impact of bugs. +A capability-based approach also ensures that the +authority wielded by components is clear and reduced to the minimum required +for them to function. +These properties are crucial to the Hurd's agenda of user freedom, +since in order to allow them to plug their own code into the system +[FIXME: développer] + +However, this flexibility has a cost. In a system where the isolation of +components relies on running them inside different address spaces, +communication between them must be done through IPC calls. +This introduces a trade-off between the size of the modules +and performance as well as practicality, +which imposes a limit to the granularity with which the system +can be decomposed and the principle of least authority applied +(to the code within a given process, a Mach port is ambient authority). + +Another issue is that of the threading structure of the system as a whole. +In systems based on a monolithic kernel, user threads execute the kernel +code themselves, which is then intrinsically concurrent. By contrast, in a +system based on a “client-server” paradigm, each server must be explicitly +multi-threaded if it is to serve requests concurrently. + +### Object-capability languages + +An object-capability language is an object-oriented language which is +restricted enough so that object references are themselves capabilities. + +One such language is Joe-E (FIXME: lien), +which is an object-capability subset of Java: +global state and static methods are mostly forbidden; +careful white-listing of the objects and methods +provided by the Java standard library +ensures that compliant code cannot not access ambient autority. +Ways in which object references can be transferred +are restricted to the most obvious ones +(for instance, exceptions are carefully restricted). + +As a result, untrusted Joe-E code can be executed without any further +isolation and its autority can be controlled by carefully limiting the +object references which are passed to it. +This would allow to load and execute translators written in Joe-E +in a single address space. + +### Bundling translators into a single process + +[mechanisme pour transmettre le code Joe-E +et les port initiaux au serveur] +[émulation des différentes tâches] + +### Challenges and further work + +[proof-carrying code / typed assembly, +resource accounting (passer en revue la conception de Viengoos?)] + + diff --git a/user/kam.mdwn b/user/kam.mdwn new file mode 100644 index 00000000..8ee68866 --- /dev/null +++ b/user/kam.mdwn @@ -0,0 +1,152 @@ +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled +[[GNU Free Documentation License|/fdl]]."]]"""]] + +[[!meta title="Karim Allah Ahmed"]] + +<karim.allah.ahmed@gmail.com> + +Egypt. + +--- + +#GSoC: 2010 Project +Goal: + +--- +#Roadmap + +##Progress + +###Preparation Phase: + +Understanding how gnumach ticks [ at least the parts related to the project ] + +--- + +####28th of April - 5th of May: + +* Reading the paging in code in gnumach. +* Reading the libpager code, and the multipage patch. +* Reading the translators code, only the part implementing the external pager interface. + +####5th of May - 12th of May: + +* Reading the paging out code in gnumach. +* Understanding IPC in gnumach and reading some code. +* Reading "[gnu_src]/kern/sched_prim.c" + +####12th of May - 19th of May: + +* Finishing the leftover code in some of the previous phases. +* Building a big and a more clear picture of how gnumach ticks [ wiring things together ]. + +####19th of May - 23th of May: + +* Off [College related-activities]. + +--- + +###Coding Phase: + +Stage 1: + +####24th of May - 26th of May: + +* Read the freeBSD multipages implementation. +* Basic Modifications of gnumach's code. +* err.. scratch this step. It's easier to work on porting OSF Mach's implementation of multi-pages. + +####26th of May - 28th of May: + +* (./) port OSF Mach's clustered pagein during 'page faults' ( [src]/vm/vm_fault.c ) +* (./) port "cluster_size" attribute of memory objects from OSF Mach. +* (./) port "behavior" attribute of vm_map entries from OSF Mach. + +####29th of May - 2nd of June: + +* Off ( Oral Exams ) + +####2nd of May - 4th of June: + +* Finish the port of the previous phase. + +--- + +####4th of June - 4th of July: + +* Off ( Final Exams ). + +--- + +Stage 2: + +####5th of July - 7th of July: + +* (./) Add "cluster_size" attribute to Neal Walfield's patch for the pager library. + +--- + +Stage 3: + +####8th of July - 15th of July: + +* (./) Patch the diskfs library to use the new pager library API. +* (./) Patch the ext2fs disk paging related routines to use the new pager library API. + + +####16th of July - 19th of July: + +* Testing the current patches. +* Stuck in compiling code ( http://30.media.tumblr.com/tumblr_l5ie1bb2u91qbjipvo1_500.jpg ) , so I started reading some documentation meanwhile ( [0] , [1] ). + +--- + +Stage 4: + +####19th of July - 31th of June: + +* Check OSF Mach's mach-defpager. +* Patch (or port OSF Mach's default pager) HURD's mach-defpager to use the new gnumach's RPCs. + +--- + +Stage 5: + +####1st of August - 10th of August: + +* Testing the ported translators. +* Fixing the boot bit-mapped memory allocator patch. + +--- + +Stage 1: + +* clustered_paging.diff patch http://lists.gnu.org/archive/html/bug-hurd/2010-06/msg00024.html + +TODO: + +* Update the headers of the modified files in GNU Mach to reflect the fact that they were ported from OSF Mach. + +* Implement posix_madvise(), posix_fadvise, and readahead() in glibc. + +* Update the documentation of GNU Mach with the new interfaces. + +* (./) Revise and finish the code related to default_memory_manager management in GNU Mach. [done] + +* Port the vm_page "clustered" attribute. [ to mark that the page wasn't requested but was paged-in as part of the cluster ]. + + +--- + + +# Readings + +[0] http://www.nongnu.org/ext2-doc/ext2.html +[1] http://kerneltrap.org/node/452 diff --git a/user/madhusudancs.mdwn b/user/madhusudancs.mdwn new file mode 100644 index 00000000..903b0964 --- /dev/null +++ b/user/madhusudancs.mdwn @@ -0,0 +1,395 @@ +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled +[[GNU Free Documentation License|/fdl]]."]]"""]] + +[[!meta title="GNU/Linux compatible procfs"]] + +[[!toc]] +---- + + Project Name +---- + +GNU/Linux compatible procfs pseudo-filesystem + +------ + + Project Description +---- +I wish to provide a sophisticated procfs pseudo-filesystem to “the Hurd”. An implementation of /proc pseudo-filesystem already exists in hurdextras repository. After skimming through the code it is clear that it needs a lot +of rework and tuning. Experiences from GNU/Linux have proven procfs to be a very useful facility in implementing +many of the process management tools. So the goal of this project is to rework on the existing procfs on “the Hurd” +so that its not only reliable and robust but also more importantly it is fully compatible with the GNU/Linux procfs. +The project thus aims at making the GNU/Linux process management tools like top, sysctl, kill, +skill, nice, snice, pgrep, free, tload, uptime, fuser, killall, pidof, pstree, etc., to run out of the box. + +------ + + Mentor +---- + +Olaf Buddenhagen + +------ + + Project Schedule +---- + +##### 1. Initial preparation and migration (Community Bonding Period: has already started – May 25th) + + This phase involves improving my translator programming skills by gaining + hands-on experience in it and becoming well versed in it. I will also go + through the Hurd code to understand its architecture in depth and will read + documentations related to obtaining process related information in Hurd. + This phase also involves the migration of existing procfs to use libnetfs. + +##### 2. Analysis and Design (May 26th – June 11th ) + + This phase involves the analysis of previous migration. Also involves + interacting with the mentor, the Hurd community and other people involved + in development of ps. tools to draw the exact design of the proposed procfs + including the algorithms required for coding. + +##### 3. Coding Stage I (June 12th – June 22nd ) + + Finishing up the migration to libnetfs based on the finalized design and + making necessary changes to the existing procfs. Coding up to + /proc/<pid>/exe in the features list. + +##### 4. Coding Stage II (June 23rd – July 13th) + + Involves coding of the features from /proc/<pid>/environ, up to + /proc/<pid>/maps. These contain most of the information required for ps. + tools and hence form the heart of the project. Will be completed by + mid-term evaluation deadline. + +##### 5. Coding Stage III (July 14th – July 26th ) + + Coding the rest of the features in the list including any necessary + features that may be added in the analysis phase. + +##### 6. Final Testing and evaluation (July 27th – August 8th ) + + Closely interacting with the community and requesting them to help me + in overall testing and reviewing and making changes as per their + suggestions. Also involves testing with the ps. tools and consolidating + the documentation. + +##### 7. Packaging and Wrap-up (August 9th - August 18th ) + + Final phase of testing and fixing remaining bugs. Working with the + community to merge the project with the CVS HEAD of Hurd. Documentation + reviews, making necessary changes as per the suggestions and wrapping + up the documentation. + +------ + + Deliverables +---- + +1. /proc filesystem that uses libnetfs. Using this library makes it easier for implementing a large set of functionalities and hence makes the implementation robust. +2. The core GNU/Linux compatible /proc filesystem with functionalities to support and provide information for ps. tools like procps, psmisc etc. + +Non-code deliverables include an exhaustive Documentation. This documents the code of the Hurd's procfs which explains in detail the implementation of each of the functionalities of procfs implemented +during the course of this project. + +------ + + Code Repository +---- + +[http://github.com/madhusudancs/procfs/tree/master](http://github.com/madhusudancs/procfs/tree/master) + +Clone URL: [git://github.com/madhusudancs/procfs.git](git://github.com/madhusudancs/procfs.git) + +------ + + Progress +---- + +1. Packages Ported: [http://www.madhusudancs.info/parted-hurdi386 parted-1.7.1] +2. Packages Porting in progress: autogen_1:5.9.4-1. Error installing texlive-bin. Error tracked to some post installation scripts of texlive-bin. Problem seems to be in fmutil. Trying to debug. +3. Have to start coding libnetfs skeleton for procfs translator. + +**Target for next week** + + Task To be completed by Status Now + + 1. Finish Defining the necessary netfs call backs 25-05-2008 Completed + 2. Create Directories for each process with pid directory name 27-05-2008 Completed + 3. Create stat file for each process within this directory and<br/> + put atleast 1 information into it 31-05-2008 In Progress + +**Documentations Read/Reading** + +1. [Hurd Hacking Guide](http://www.gnu.org/software/hurd/hacking-guide/hhg.html) (Have Concentrated mainly on Translator part) +2. [Linux Kernel Implementation of procfs](http://users.sosdg.org/~qiyong/lxr/source/Documentation/filesystems/proc.txt) + +**Code Being Read** + +1. libps +2. libnetfs +3. [procfs implementation in Linux kernel](http://users.sosdg.org/~qiyong/lxr/source/fs/proc/) +4. ftpfs (In Hurd main) +5. cvsfs (In Hurd extras) +6. xmlfs (In Hurd extras) +7. httpfs (In Hurd extras) +8. gopherfs (In Hurd extras) +9. libfuse (In Hurd extras) +10. procfs (libtrivfs based, In Hurd extras) + +------ + + Post Mid-Term Road Map +---- + + +####Already Implemented + +#####File - /proc/<PID>/stat + +* pid + +* comm + +* state + +* ppid + +* pgrp + +* session + +* tty_nr + +* tpgid + +* minflt +> The number of minor faults the process has made which have not required loading a memory page +> from disk. + +* majflt +> The number of major faults the process has made which have required loading a memory page from +> disk. + +* utime +> The number of jiffies that this process has been scheduled in user mode. + +* stime +> The number of jiffies that this process has been scheduled in kernel mode. + +* priority +> The standard nice value, plus fifteen. The value is never negative in the kernel. + +* num_threads +> Number of threads in this process. + +* starttime +> The time in jiffies the process started after system boot. + +* vsize +> Virtual memory size in bytes. + +* rss +> Resident Set Size: number of pages the process has in real memory, minus 3 for administrative +> purposes. This is just the pages which count towards text, data, or stack space. This does not +> include pages which have not been demand-loaded in, or which are swapped out. + +* itrealvalue +> The time in jiffies before the next SIGALRM is sent to the process due to an interval timer. + +* nswap +> Number of pages swapped (not maintained). + +* cnswap +> Cumulative nswap for child processes (not maintained). + +* flags +> PF_* fields defined in (Not Linux compatible, but nearly says the something Linux says) + +* nice +> The nice value ranges from 19 to -19. + +* cutime +> The number of jiffies that this process’s waited-for children have been scheduled in user +> mode. + +* cstime +> The number of jiffies that this process’s waited-for children have been scheduled in kernel mode. + +#####File - /proc/<PID>/statm + +* size +> total program size + +* resident +> resident set size + +* lib +> library + +* dt +> dirty pages + +####I already know the where the information is exactly available. + +#####Other Per-PID Files + +#####* /proc/<PID>/exe + +#####* /proc/<PID>/environ + +#####Non Per-PID Files + +#####* /proc/version + + +####I know where the information is available roughly, but need to look in detail to extract the exact information. + +* cminflt +> The number of minor faults that the process’s waited-for children have made. + +* cmajflt +> The number of major faults that the process’s waited-for children have made. + +* signal +> The bitmap of pending signals. + +* blocked +> The bitmap of blocked signals. + +* sigignore +> The bitmap of ignored signals. + +* sigcatch +> The bitmap of caught signals. + +* policy +> Scheduling policy. + +#####File - /proc/<PID>/statm + +* text +> text (code) + +#####Other Per-PID Files + +#####* /proc/<PID>/cwd + +####The information may be available, but needs to be searched to know where it will be. + +#####File - /proc/<PID>/stat + +* rlim +> Current limit in bytes on the rss of the process (usually 4294967295 on i386). + +* startcode +> The address above which program text can run. + +* endcode +> The address below which program text can run. + +* startstack +> The address of the start of the stack. + +* kstkesp +> The current value of esp (stack pointer), as found in the kernel stack page for the process. + +* kstkeip +> The current EIP (instruction pointer). + +* exit_signal +> Signal to be sent to parent when we die. + +#####File - /proc/<PID>/statm + +* share +> shared pages + +* data +> data/stack + +#####Other Per-PID File + +#####* /proc/<PID>/root + +#####Non Per-PID Files + +#####* /proc/stat + +#####* /proc/meminfo + +####I fear information may not be available. + +#####File - /proc/<PID>/stat + +* wchan +> This is the "channel" in which the process is waiting. It is the address of a system call, and +> can be looked up in a namelist if you need a textual name. (If you have an up-to-date +> /etc/psdatabase, + +* processor +> CPU number last executed on. + +* rt_priority +> Real-time scheduling priority + +* delayacct_blkio_ticks +> Aggregated block I/O delays, measured in clock ticks (centiseconds). + + +###Newly added to Roadmap(but these were the original goals of the project) + +#### procps tools need to be ported so that they run on top of the procfs + +> ##### pgrep - Done +> ##### pkill - Done +> ##### killall - Done +> ##### pstree - Done +> ##### top - Mostly Done (except per-PID shared memory field, and non per-PID caches and buffers field) +> ##### free - Mostly Done (Ditto from above) +> ##### htop - Mostly Done (Ditto again) +> ##### watch - Done +> ##### tload - I think it is done. (Need someone to test it) +> ##### libgtop - In progress +> ##### gnome-system-moitor - In progress + + + +------ + + Code Updates +---- + +1. May, 14, 2008 +2. May, 18, 2008 +3. May, 28, 2008 +4. June, 1, 2008 +5. June, 2, 2008 +6. June, 4, 2008 +7. June, 5, 2008 (3 commits, 00:30 HRS, 02:30 HRS, 11:15HRS, all in IST) +8. June, 9, 2008 +9. June, 19, 2008 (Targets 1 and 2 successfully accomplished. Duration between the commits became inevitably longer because of the large amount of time spent on debugging the code.) + +------ + + Contact Details +---- + +Name : Madhusudan.C.S + +Email : [madhusudancs@gmail.com](mailto:madhusudancs@gmail.com) + +Blog : [http://www.madhusudancs.info](http://www.madhusudancs.info/) + +Detailed proposal: [http://www.madhusudancs.info/gnu-hurd-procfs-proposal](http://www.madhusudancs.info/gnu-hurd-procfs-proposal) + +Google Summer of Code Site Link: [Abstract](http://code.google.com/soc/2008/hurd/appinfo.html?csaid=D2E9266819D2EEF9) + + diff --git a/user/michaelbanck.mdwn b/user/michaelbanck.mdwn deleted file mode 100644 index 76e09c28..00000000 --- a/user/michaelbanck.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -* Name: Michael Banck -* Email: <mbanck@gmxNOSPAM.net> -* Country: Germany diff --git a/user/nowhere.man.mdwn b/user/nowhere.man.mdwn deleted file mode 100644 index 61d377d7..00000000 --- a/user/nowhere.man.mdwn +++ /dev/null @@ -1,4 +0,0 @@ -* Name: Pierre Thierry -* Email: <nowhere.man@levallois.euNOSPAM.org> -* Company Name: Thierry Technologies -* Country: France diff --git a/user/pietroferrari.mdwn b/user/pietroferrari.mdwn deleted file mode 100644 index 0bf63419..00000000 --- a/user/pietroferrari.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -* Name: Pietro Ferrari -* Email: <pietro@bastardiNOSPAM.net> -* Country: Brazil diff --git a/user/pochu.mdwn b/user/pochu.mdwn new file mode 100644 index 00000000..18e90de3 --- /dev/null +++ b/user/pochu.mdwn @@ -0,0 +1,136 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +# Emilio Pozuelo Monfort + +Email: pochu27@gmail.com + +--- + +# GSoC 2010: Hurd: Fix Compatibility Problems Exposed by Testsuites + +Mentor: Carl Fredrik Hammar + +## Abstract + +This project will consist of identifiying some projects' test suite +failures when executed on GNU/Hurd, debugging them, and if they are +truly GNU/Hurd issues (and not problems in the projects themselves), +fixing them. + +## Timeline +* July 18th: GLib finished. +* July 22nd: coreutils finished. +* July 25th: All Perl failures investigated. +* August 5th: Perl finished. +* August 8th: All Python failures investigated. +* August 16th: Python finished. +* August 16th: Firm 'pencils down' date + +## TODO +* Investigate why coreutils' nice test fails. +* Analyze Perl's testsuite failures. + +## Documentation +* [Towards a New Strategy of OS Design, an architectural overview by Thomas Bushnell, BSG](http://www.gnu.org/software/hurd/hurd-paper.html) +* [The Hurd, a presentation by Marcus Brinkmann](http://www.gnu.org/software/hurd/hurd-talk.html) +* [The Hurd Hacking Guide](http://www.gnu.org/software/hurd/hacking-guide/hhg.html) +* [MIG - The MACH Interface Generator](http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/mig.ps) + +## Log + +### July 26th - August 1st +* Tested /dev/fd/N patches and sent them for review. +* Finished SCM_RIGHTS patch. Created a minimal testcase without using + glibc to demonstrate the socket_send/recv failure with non-socket + fds. Sent the testcase and the patch for review. +* Investigated cp issues with O_NOFOLLOW & O_NOTRANS. Sent a mail to + bug-hurd explaining both issues and possible solutions. + +### July 19th - July 25th +* Initial SCM_RIGHTS implementation. Seems to work when sending pipes, but + fails miserably when sending fds from an open syscall. No idea why yet. +* Fixed memleaks in sendmsg() while implementing SCM_RIGHTS. Patch accepted + upstream. +* Had to build glibc thrice because the system crashed and the fs was totally + corrupted. I'll build stuff in a separate partition as suggested from now on. + Doesn't help. It turns out the issue seems to be with kvm, or at least it's + only reproducible for me there. I've switched to VirtualBox and there are no + filesystem issues there. +* Addressed comments in the /dev/fd/N patches. Need to test them (when I can + build glibc and Hurd without the system crashing). + +### July 14th - July 18th +* Catched up with email. +* Prepared a patch to implement getsockopt(fd, SOL_SOCKET, SO_TYPE, ...). + Patch committed to Hurd. +* Addressed comments in the /dev/fd/N patches and resent them. +* Investigated another glib's unix-fd failure: passing fds over a socket using + sendmsg() doesn't dup them. Created a minimal testcase. Prepared a preliminary + patch, needs testing and fixing. + +### May 26 - July 13th +* Copyright assignment on file. +* Studied a lot to finish my BSc. +* Got the linkat patch (Savannah #29655) committed upstream. + +### May 19 - May 26 +* Read [MIG - The MACH Interface Generator](http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/mig.ps) +* Worked on bug 28934. Send [patches](http://lists.gnu.org/archive/html/bug-hurd/2010-05/msg00108.html) for review. +* Requested GNU libc copyright papers to the FSF again since they didn't arrive the first time. + +### May 12 - May 19 +* Read http://www.gnu.org/software/hurd/hurd-talk.html +* Half read http://www.gnu.org/software/hurd/hacking-guide/hhg.html +* Read many Hurd interfaces (fs.defs, auth.defs, fsys.defs, io.defs, + password.defs). + +### May 5 - May 12 +* Read http://www.gnu.org/software/hurd/hurd-paper.html +* Improved the linkat() patch +* Fixed the issues mentioned in bug 28934, but after doing so I realized + that wouldn't work well. The only good solution is to pass file_name + from execve() to the exec server, so we need new RPCs. + +### April 28 - May 5 +* Submitted a talk proposal on Hurd with Michael Banck for DebConf +* Sent request to assign copyright to the FSF for Hurd/Mach/libc + +### Before April 28 +* Investigated the glib's gtester problem and tracked it down: + [bug 28934](https://savannah.gnu.org/bugs/?28934). Prepared a patch + but it's not good. +* [glib's garray test timeouts on Hurd](https://bugzilla.gnome.org/show_bug.cgi?id=568760). + The tests passes if the timeout is increased. The current upstream timeout + (10s) is quite small (it fails on many Debian builds for some Linux arches). + However on Hurd it needs a very big time it seems (like more than 100s). + Maybe do an allocation benchmarch? +* Investigated glib's unix-fd test failure: getsockopt() isn't implemented + on Hurd. Need to implement it in hurd/pflocal/socket.c. +* Investigated coreutils' ln EIEIO, with Samuel's help. linkat() is buggy. + Reported as [bug 29655](https://savannah.gnu.org/bugs/?29655). Prepared a + patch for it. +* Investigated coreutils' cp EACCES. Test case: 'mkfifo a && cp -R --copy-contents a b'. + Problem is that O_NOFOLLOW adds O_NOTRANS. + +## Midterm Evaluation +### Accomplished +* Assigned copyright to the FSF. +* Read many documentation and source code. +* /dev/fd/N bug fixed +* Prepared a patch for getsockopt() +* Fixed linkat() problems. +* Investigated bug with O_NOFOLLOW & O_NOTRANS (needs more work). +* Investigated a glib test failure (garray). Not a Hurd issue. +### Downtime +* Studied a lot to finish my BSc. Didn't work on Hurd for a month because of + that, so that's why I couldn't make a lot of progress (this was known in + advance, although in the end the downtime was a bit larger than expected). +* There's no expected downtime from now on. diff --git a/user/scolobb.mdwn b/user/scolobb.mdwn new file mode 100644 index 00000000..017936e5 --- /dev/null +++ b/user/scolobb.mdwn @@ -0,0 +1,364 @@ +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled +[[GNU Free Documentation License|/fdl]]."]]"""]] + + +Sergiu Ivanov + +Mail: <mailto:unlimitedscolobb@gmail.com> + +# Current Activity + +I am currently busy finishing the university semester, this is why I +am rather passive. + +## Roadmap + +* **Build `nsmux` under the Hurd tree** -- **antrik** has been urging + me to do this for a long time, so I definitely have to give it a + try. + +* **Try Thomas's `nsmux-notify` branch** -- To support his stance + against including `nsmux` in the Hurd source tree, Thomas added to + `nsmux` the ability to listen to port notification (as I understand + it). I have to try that, too. + +* **Make proxy nodes go away when the proxied translator goes away** + -- This should be done by listening to notifications on the ports to + the proxied translators. A similar functionality is already + implemented in `unionmount`, but it was decided that `nsmux` should + use standard notification interfaces, as opposed to the custom + demuxer and handler implemented in `unionmount`. + +* **Don't attach anonymous translators** -- There is no special point + in attaching anonymous (formerly known as dynamic) translators to + specific nodes. Keeping them orphan should simplify the design of + `nsmux` by eliminating the need for shadow nodes, whose main purpose + was to serve as virtual locations to attach translators to. + +* **Setup a list of nodes proxying static translators** -- This list + is needed when for the filter, which should also be able to go down + the static translator stack, not only the stack of anonymous + translators. + +* **Cleanup `nsmux`** -- When I was writing `nsmux` my acquaintance + with good coding and code formatting practices was very basic, which + resulted in messy and sometimes ugly code. + +* **Implement recursive propagation of translators down directories** + -- This task was planned long ago and is fascinating, but I won't be + working on it in the near future. + +--- + +# Google Summer of Code: 2009 Project + +**Unionmount**: The goal of this project is to make it possible to set +translators in unionmount mode, which means that the filesystem +published by the mounted translator will get merged with the directory +tree of the node the translator is mounted onto. + +For documentation, see [[hurd/translator/unionmount]]. + +At the Final Evaluation, this project was given a passing evaluation +by **antrik**. This means that the union-mount functionality is +working and has been tested normally to collaborate with +`eth-multiplexer`. + +--- + +## Roadmap + +### DONE + +(Dates in brackets show the completion date) + +* **Make `unionfs` build.** *(24 May)* For reasons unknown to me, + `unionfs` Makefile was configured to search for include files from + under `$(prefix)/include`, while `$(prefix)` was never + defined. Setting `$(prefix)` to `/usr` solved the problem. + +* **Change the command line parsing in `unionfs` to comply with the + requirements of `unionmount`.** *(25 May)* Although the core + functionality of `unionmount` heavily relies on `unionfs`, the + command line interface of these two programs is completely + different: `unionfs` operates on directories, the list of which is + explicitly specified, while `unionmount` *always* merges the + underlying filesystem and the filesystem published by the + mountee. Therefore, options like `--add`, `--remove`, `--underlying` + (specific to `unionfs`) make little sense in `unionmount` + context. These options have been removed. Also, `unionmount` must be + able to pass some switches to the mountee, which means that it + should stop parsing the command line arguments immediately after + having encountered the path to the mountee (very similar to how + `settrans` works). This functionality has also been implemented. + +* **Make `unionmount` capable of starting the mountee.** *(28 May)* + The idea behind implementation of this goal is that `unionmount` + should provide a proxy node on which to set the mountee. The main + issue about this goal was the fact that the mountee *cannot* be + started during the initialization of `unionmount`, because in this + phase `unionmount` is not capable of responding to RPCs, while many + translators try to `io_stat` their underlying node or do other + interesting things on startup. The solution to this problem is, + obviously, *lazy* startup, i.e. the mountee is started at the first + attempt to access (via `dir_lookup` or `dir_readdir`) the merged + filesystem published by `unionmount`. + +* **Include the filesystem published by the mountee in the list of + merged filesystems.** *(1 Jun)* `unionfs` operates on a list of + ports to the underlying filesystems, therefore, to finish the + unionmount functionality, I had to include the port to the mountee + in this list. + +* **Learn Texinfo.** *(Jun 4)* In order to produce canonical + documentation I had to learn the Texinfo documentation format. + +* **Write documentation for `unionmount`.** *(Jun 5)* The basic + unionmount functionality being finished, it has to be documented + properly, lest it should lag behind and remain unfinished + eventually. + +* **Write documentation for `unionfs`.** *(Jun 5)* `unionfs` is not + exactly well-documented at the moment, the only help being provided + by the comments in the sources. The goal is to write a more coherent + documentation. + +* **Start with a clean unionfs and implement the `--mount` argument** + *(11 Jun)* It was suggested to implement the union mount + functionality first, instead of doing some partial adaptation of + `unionfs` to `unionmount` and leaving the complete adaptation for + the future. + +* **Compile GNU/Hurd from source to be able to study + eth-multiplexer.** *(16 Jun)* On my way to getting a working + instance of eth-multiplexer I learnt how I could compile GNU/Hurd in + a Debian GNU/Hurd system. + +* **Setup the `devnode`--`eth-multiplexer`--`pfinet chain`.** *(30 + Jun)* Due to the fact that I was trying to build everything using + `gcc-4.3`, I got strange behaviour of pfinet and spend a week trying + to figure out the reason. + +* **Try to start the mountee during initialization of `unionfs`** *(4 + Jul)* Initially the mountee was started at the first lookup. Now it + is started immediately after initialization of `unionmount`. + +* **Fix the patches in `--mount` option series** *(5 Jul)* The patches + have been reviewed by **antrik**. I corrected them and posted them + to the ML for final reviews. + +* **Orphan the mountee after starting it** *(7 Jul)* Orphaning the + mountee after starting it up seems to be a nice work-around for the + necessity of keeping a proxy node in unionmount in simple + use-cases. It is possible that this functionality will provided as a + separate patch (without inclusion in master) should it turn out that + orphaning the mountee is a bad idea. + +* **Decide which RPCs should be forwarded to the mountee and how this + should happen** *(10 Jul)* This is the primary requirement in being + able to proxy the control port of `unionmount`. + +* **Fix the patches the have already been commented on** *(14 Jul)* + The new patches I have submitted have been reviewed; also, the older + patches have been reviewed again, which required correcting them. + +* **Add the `--no-mount` option** *(14 Jul)* Using the `--no-mount` + and `--mount` options, the user can decide whether unionmount should + be completely transparent (i.e. most control-port RPCs forwarded to + the mountee) or not. + +* **Make `unionmount` go away when the mountee goes away** *(14 Jul)* + `unionmount` makes sense only while the mountee is running, so it + has to go away as soon as the mountee has been shut down for some + reason. + +* **Proxy the control port of `unionmount`** *(14 Jul)* For + `unionmount` to become transparent, most of the RPCs invoked on the + its control port should be forwarded to the mountee. + +* **Fix adding filesystems to `unionmount`** *(16 Jul)* `settrans -a + foo unionfs -a <dir> -u -t <translator>` worked, but `settrans -a + foo unionfs -u -t <translator> -a <dir>` didn't. The problem was + that in a series of rebase operations I accidentally left the + "Orphan the mountee" commit out and the problem appeared when the + `start_mountee` function tried to attach the mountee. Of course, + this is not the definite solution, since I don't know why should the + attempt to attach the mountee work in the former case and fail in + the latter, but I will leave the investigation for some future time. + +* **Create the patch for supplying the mountee with a port to the + underlying node of unionfs** *(17 Jul)* Such functionality makes + `unionmount` even more transparent. + +* **Try to make `eth-multiplexer` work with static instances of + `devnode`** *(3 Aug)* A static `devnode` translator is a `devnode` + translator which is told to use the eth-multiplexer's pseudo master + device port via the "-M" option. Technically it looks like + `settrans -a <node> devnode -M <dir> <device-name>`, where `<dir>` + is the node on which eth-multiplexer is running. + + The problem was in the fact that the root node of `eth-multiplexer` + was not treated completely similarly as other nodes; specifically no + device port was created for it. Minor modifications to some + conditions solved the problem. + +* **Add the `MASTER` node to `eth-multiplexer`** *(5 Aug)* The + `MASTER` node, published by eth-multiplexer, allows creating any + number of virtual devices. This node is mainly accessed by static + instances of `devnode` to setup their corresponding virtual devices. + +* **Add support for priorities** *(6 Aug)* Now the mountee's + filesystem can be configured to "lie" beneath other filesystems. + +* **Use `unionmount` to merge the virtual filesystem of + `eth-multiplexer` with its underlying filesystem** *(7 Aug)* + `eth-multiplexer` can is unionmounted to "lie beneath" it's + underlying filesystem. If, for example, the multiplexer is + unionmounted on `veth/`, the user can both set (static) `devnode` + translator on the nodes shown in `veth/` and belonging to the + underlying filesystem and create normal virtual multiplexer devices + by accessing any node (not present in the underlying filesystem) and + opening a device using the port to the node as a pseudo device port. + +* **Rename the `MASTER` node into `.MASTER`** (7 Aug) This name seems + more natural for a special-purpose node. + +* **Set the stat information for `eth-multiplexer` nodes in + `netfs_validate_stat`** (9 Aug) In the initial version the stat + information was set up properly only at device creation. Before + that the stat information was copied from the underlying node, which + baffled `unionmount`. Now the stat information is setup in + `netfs_validate_stat`. + +* **Supply the mountee with the real root.** *(14 Aug)* Since the + mountee is *not attached* to its underlying node, it is okay to + supply it with the real root node of `unionfs`. The mountee's + filesystem will not obscure the `unionfs`'s one because the mountee + is *not attached* to the root node. + +--- + +# Google Summer of Code: 2008 Project: Namespace-based translator selection + +--- + +## Current Task + +Write the filesystem proxy for namespace-based translator selection (*nsmux*). + +The code is at <http://github.com/scolobb/nsmux/tree/master>. + +--- + +###Did this week + +* Modified the node cache so that it maintains shadow nodes alive. + +###Plans for the next week + +* Implement the shutting down of translator stacks when *nsmux* is asked to go away (in case **antrik** considers that necessary). + +* Make *nsmux* provide the access to the translator stack of the real node, in case a translator (mainly, a filter) should ask for its underlying node to be opened in O_NOTRANS mode. + +--- + +###Current Status + +####DONE: + +* The skeleton which mirrors the filesystem. + +* Provide proxy nodes (modify the standard version of netfs_S_dir_lookup). + +####TODO: + +* Create the generic filtering translator. + +* Create the translator '0' (providing the untranslated version of the + node). + +* Create the "recursive wrappers" for one-node translators. + +* Create special translators for the main proxy so that its functionality + should be complete. + +* Implement sharing of dynamic translator stacks where possible. + +* Make dynamic translators go away as soon as they are not required. + +* Refine the skeleton in several places so that it should become faster + and more reliable. + +* Kill bugs. + +* Integrate nsmux upstream. + +* Solve the libtrivfs stacking issue. + +* Patch libnetfs (it does not support file_get_translator_cntl, for + instance). + +--- + +###Progress + +####8: Fri Sep 19: + +> Modified the ncache so that it now maintains shadow nodes (and directory nodes too, it is a side effect at the moment) alive. + +####7: Sat Aug 30 - Fri Sep 5: + +> Added the code for shutting down dynamic translator stacks. + +####6: Mon Aug 4 - Fri Aug 29: + +> Implemented the proxy nodes. + +####5: Thu Jul 24 - Thu Jul 24: + +> Created a *libnetfs*-based one-node translator, working exactly like the *libtrivfs*-based translator I had written before; the former, however, can be included in a translator stack. + +####4: Tue Jul 22 - Thu Jul 24: + +> Attempted to make a *libtrivfs*-based translator to be able to be stacked upon itself (to be able to receive a translator on top of itself, more exactly); attempted to borrow some code from *libnetfs* but this didn't bring any results. + +####3: Sun Jul 20 - Tue Jul 22: + +> Implemented the possibility to propagate a translator on all files belonging to a directory 'dir' in the request of the type 'dir,,x/'. + +####2: Thu Jul 17 - Fri Jul 18: + +> Extended the lookup code in *nsmux* to allow for looking up nodes like 'file,,x' and added the possibility to escape the double-comma in the following way: ',,,'. + +####1: Mon Jul 12 - Tue Jul 13: + +> Implemented a simple *libtrivfs*-based translator to test the lookup code for *nsmux*. + +####0: Sat Jul 12 - Sat Jul 12: + +> Made small changes to the code of *filterfs* to fit the needs of *nsmux*. + +--- + +## Completed Tasks + +####2: Sat May 3 - Fri Jul 17: + +> Write a translator that should filter the contents of the directory it is set on according to some property. The property can be an arbitrary command. + +> The code is at <http://github.com/scolobb/filterfs/tree/master>. + +####1: Mon Apr 28 - Wed Apr 30: + +> Wrote a Python extension module in C for retreiving the uptime. The module is based on the code of *w*. + +####0: Sun Apr 27: + +> Followed the code of *dmesgd* (<http://www.bddebian.com/junk/dmesgd/>) kindly offered by **bddebian** and rewrote it from scratch as a tutorial. diff --git a/user/soerenschulze.mdwn b/user/soerenschulze.mdwn deleted file mode 100644 index 4dd22728..00000000 --- a/user/soerenschulze.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -* Name: Sören Schulze -* Email: <soeren.d.schulze@gmxNOSPAM.de> -* Country: Germany diff --git a/user/tombachmann.mdwn b/user/tombachmann.mdwn deleted file mode 100644 index 639df67d..00000000 --- a/user/tombachmann.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -* Name: Tom Bachmann -* Email: <e_mc_h2@webNOSPAM.de> -* Country: Germany diff --git a/user/tschwinge.mdwn b/user/tschwinge.mdwn index b72f26f5..eea5480c 100644 --- a/user/tschwinge.mdwn +++ b/user/tschwinge.mdwn @@ -1,17 +1,17 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2010 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled -[[GNU_Free_Documentation_License|/fdl]]."]]"""]] +[[GNU Free Documentation License|/fdl]]."]]"""]] -[[meta title="Thomas Schwinge"]] +[[!meta title="Thomas Schwinge"]] -<tschwinge@gnu.org> +<thomas@schwinge.name> Germany -<http://www.thomas.schwinge.homeip.net/> +<http://schwinge.homeip.net/~thomas/> diff --git a/user/vincentvikram.mdwn b/user/vincentvikram.mdwn index 847325e2..875b6311 100644 --- a/user/vincentvikram.mdwn +++ b/user/vincentvikram.mdwn @@ -1,12 +1,12 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled -[[GNU_Free_Documentation_License|/fdl]]."]]"""]] +[[GNU Free Documentation License|/fdl]]."]]"""]] * Name: Vikram Vincent * Email: vincentvikram@swatantra.org OR vincentvikram@gmail.com diff --git a/user/zhengda.mdwn b/user/zhengda.mdwn new file mode 100644 index 00000000..a7f57f35 --- /dev/null +++ b/user/zhengda.mdwn @@ -0,0 +1,132 @@ +# Zheng Da + +Email: zhengda1936 at gmail dot com + +--- + +#Project: Porting DDE to Hurd. + +##The goal: +porting DDE developed by DROPS to the Hurd, and it will still run in the user space. + +##Introduction +The introduction of DDE/DDEKit can be found in [here](http://wiki.tudos.org/DDE/DDEKit) and more information can be found [here](http://os.inf.tu-dresden.de/pipermail/l4-hackers/2009/004291.html). DDE/DDEKit is a library, and it should be compiled with the code of Linux or FreeBSD drivers. DDE Linux26 is still under development and it can now support network and block devices (but doesn't support SCSI). + +##The current status +Currently a few NIC cards work now. I tested pcnet32, e100, e1000, ne2k-pci and rtl8139 in VMWare and Qemu. But the DDE e100 driver cannot work for some e100 cards as currently DDE doesn't support firmware. Someone also reported sis900 cannot work, unfortunately, I cannot test it myself. I appreciate if someone can try some other NIC drivers and give me some feedbback. Please run DDE with GNUMach in the [master-user_level_drivers](http://git.savannah.gnu.org/cgit/hurd/gnumach.git/) branch. + +## My work +I separate DDE Linux26 to 2 parts: libddekit and libdde_linux26. I also provide a library called libmachdev on the top of the Linux code to provide the Mach device interface, so it is easy for the user to compile a Linux driver and run it in the Hurd. The latest code can be found in the dde branch of the incubator repository. + +There is a minor problem when we compile a Linux driver. Linux drivers use jiffies to measure time. Unfortunately, Mach doesn't provide it, so whenever we need it, we need to calculate it by ourselves. I decide to provide a macro to calculate it for the sake of performance and the cost is that the source code of Linux drivers has to include ddekit/timer.h. + +## Build and run DDE drivers + +To build a Linux driver with DDE Linux, we need libddekit, libdde_linux26, libmachdev and libhurd-slab. libddekit and libmachdev use the same Makefile system as other Hurd components but libdde_linux26 does not, so we have to build libdde_linux26 in its source file directory. DDE drivers use the same makefile system as libdde_linux26 and thus we need to build them in their source file directories as well. + +The repository has all DDE drivers I have tested, but in case you want to try other drivers, the easiest way is to use dde_pcnet32 as a template. The directory of dde_pcnet32 has Makefile, Makeconf.local, default.ld, pcnet32.c and main.c. If we need to build a new driver file, we only need to replace pcnet32.c with the new file and change Makefile accordingly. You also need to change DDEKITLIBDIR, DDEKITINCDIR, DDE26LIBDIR and OBJ_BASE in Makeconf.local to indicate the path to ddekit and dde_linux26. + +When all parts are ready, we can start to build DDE drivers now. In case someone hasn't installed libpciaccess, please install it first. We first build libddekit, libdde-slab, then libdde_linux26, then libmachdev and at last the DDE driver. It's better to install libddekit, libdde-slab and libmachdev to the system, so libdde_linux26 and the DDE driver find the library files and header files. + +To run a DDE NIC driver: It is better to disable the corresponding kernel drivers in GNU Mach. For example, if we use the pcnet card, we'd better disable lance and pcnet32 drivers in gnumach. DDE requires the pfinet with modification during my GSoC project in 2008 and that pfinet requires libpcap-dev (this pfinet is also in the dde branch). + +settrans -acfg pcnet32 hurd/dde_pcnet32/dde_pcnet32 + +settrans -acfg /dev/eth0 hurd/devnode/devnode eth0 -M pcnet32 + +settrans -acfg /servers/socket/2 hurd/pfinet/pfinet -i /dev/eth0 -a 172.16.172.10 -g 172.16.172.2 -m 255.255.255.0 + +--- + +#Project: Network virtualization for subhurds etc. + +The [code](http://www.assembla.com/spaces/VNetHurd/trac_subversion_tool). The [[howto]] shows the instructions of setting up the virtual network in hurd and subhurd. + + +## The design and the implementation + +### The requirements: +* to implement a mechanism which help pfinet servers communicate with each other. For example, if pfinet 1 has IP A and pfinet 2 has IP B, the packet sent by pfinet 1 with destination address IP B should be received by pfinet 2. +* Sub-hurd should be able to use this mechanism to communicate with each other. +* Meanwhile this mechanism should allow non-privileged the user to start his own pfinet. + + +### The possible approach is to use the multiplexer and the filter. +The multiplexer's roles are: + +1. to create some virtual network interface, so pfinet can send packets to it. +2. to receive the packet from pfinet, and forward the packet to other pfinets in hurd +3. or forward the packet to the real network device in the kernel and send it to the network. + +A filter translator is needed to enforce the policies between the interface and the pfinet server. For example, the filter can control which packets can be delivered to the pfinet server, and which packets can be sent to the network interface. The filter can also guard the network traffic and drop illegal packets (forged by some malicious users) from pfinet or some other programs. + + +### To create a virtual network interface: +* Implement the RPC interface defined in device.defs. +* The multiplexer works as a translator and other programs can get the port to it by calling file_name_port(). +* Other programs can use this port as a master device port to open the virtual interface. + + +### The routing inside the multiplexer: +* when the multiplexer gets a packet, it forwards it to every interface. +* BPF is ported to the multiplexer. BPF delivers the packet to the right pfinet (according to the filter set by the pfinet) just as the BPF in Mach does. +* All packets are forwarded to the interface which the multiplexer sits on. + + +### The implementation of the filter translator: +* The filter works as a proxy, forwarding the packet between the interface and the pfinet server. +* BPF is also ported to the filter translator. There are two filers in the translator, one for outgoing packets, the other for incoming packets. +* Only one pfinet can connect to the translator at a time. + +## TODO +### Coding + + - merge BPF rules from the filter translator and the multiplexer + +## Completed tasks + +### Coding + +The patch of glibc (pfinet server overriding) is [here](http://www.assembla.com/spaces/VNetHurd/documents/aJidqKp6ur3z-Nab7jnrAJ/download/A%20patch%20of%20glibc), commited to debian for 2.11.2-7 and later. + +The patch of pfinet (open the virtual network interface) is [here](http://www.assembla.com/spaces/VNetHurd/documents/aWqYwYATKr3BBOab7jnrAJ/download/patch%20of%20pfinet%201%20(to%20use%20the%20virtual%20interface)). + +The patch of pfinet (fix pfinet to use the proper filter rule) is [here](http://www.assembla.com/spaces/VNetHurd/documents/besb-qATKr3AIxab7jnrAJ/download/patch%20of%20pfinet%202%20(to%20add%20an%20IP%20filter)). + +The patch of pfinet (set the mach device in the promiscuous mode) is [here](http://www.assembla.com/spaces/VNetHurd/documents/bEovN6ATKr3B8uab7jnrAJ/download/patch%20of%20pfinet%203%20(to%20set%20the%20mach%20device%20into%20the%20promiscuous%20mode)), commited on 20100920. + +The patch of boot (open the virtual network interface) is [here](http://www.assembla.com/spaces/VNetHurd/documents/cWkeEixHar3AdKab7jnrAJ/download/A%20patch%20of%20boot), commited on 20100920. + +The patch of gnumach (set the network device into the promiscuous mode) is [here](http://www.assembla.com/spaces/VNetHurd/documents/b0eLzUxHmr3ymXab7jnrAJ/download/A%20patch%20of%20gnumach), commited on 20100920. + +the multiplexer: + +- Create multiple virtual network interfaces. +- Port BPF to the multiplexer. +- Finish the routing among the pfinet servers. + +the filter translator: + +- Forward the packet between the interface and the pfinet server. +- Filter the packet. + +the proxy of the proc server: + +- Forward all requests from the process to its proc server. +- The proxy doesn't do any real work except returning the host private port and the master device port of the proxy (shown as an example). + +the devnode translator: + +- Create a device file to help open the network device. + +### Documentation Read + + +- [A Programmer's Guide to the Mach System Calls](ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/machsys.doc) +- [Meet Mach](http://www.stepwise.com/Articles/Technical/MeetMach.html) by James Scott +- [A Programmer's Guide to the Mach User Environment](ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/machuse.doc), the MIG part +- Part of The GNU Mach Reference Manual and The GNU Hurd Reference Manual +- The Hurd, a presentation by Marcus Brinkmann +- Towards a New Strategy of OS Design, an architectural overview by Thomas Bushnell, BSG. +- GNU/Hurd User's Guide +- The Hurd Hacking Guide diff --git a/user/zhengda/howto.mdwn b/user/zhengda/howto.mdwn new file mode 100644 index 00000000..1258ffed --- /dev/null +++ b/user/zhengda/howto.mdwn @@ -0,0 +1,90 @@ +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled +[[GNU Free Documentation License|/fdl]]."]]"""]] + + +This document briefly introduces how to set up the virtual network and connect the subhurd with the main hurd. + + +### 1. Set up the virtual network. + +####1.1 Patch and install GNU Hurd, GNU Mach and the GNU C library. + +Step 1: Get the Hurd and compile it. + + cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd co -r zhengda-soc2008-virt-branch hurd + + +Step 2: apply the [patch](http://www.assembla.com/spaces/VNetHurd/documents/b0eLzUxHmr3ymXab7jnrAJ/download/A%20patch%20of%20gnumach) on the GNU Mach. + +In order to connect the virtual network created in hurd with the external network, we need this patch. It enables the Hurd to set the Mach device into the promiscuous mode, so the real device can accept the packet that goes to the virtual device in hurd. +(This step is optional if we are only interested in creating a internal virtual network.) + +Step 3: apply the [patch](http://www.assembla.com/spaces/VNetHurd/documents/aJidqKp6ur3z-Nab7jnrAJ/download/A%20patch%20of%20glibc) on glibc. + +This patch enables the user to override the default socket server by using the environment variables SOCK_SERV_DIR or SOCK_SERV_%d (%d is the domain of the socket server). + + +#### 1.2 Set up the Hurd components to build the virtual network. + +In this section, I show how to create two virtual interfaces and run three pfinet servers. I assume that the source code of Hurd is in /root/hurd. + +Step 4: create the network device file in /dev with devnode. +The network device file is used to help other translators open the device. + + # settrans -acfg /dev/eth0 /root/hurd/devnode/devnode eth0 + +Step 5: create the virtual network device with eth-multiplexer. + +eth-multiplexer is responsible to create the virtual network device and dispatch the packet to the right clients that connect to the virtual device. It also connects the virtual network and the external network. Eth-multiplexer of the current version is a netfs translator and can create virtual devices and the device files dynamically, according to the request from the client. + + # settrans -acfg /root/multiplexer /root/hurd/eth-multiplexer/eth-multiplexer -i /dev/eth0 + +Step 6: setup the filter translator eth-filter on the network device. This step is optional. + +eth-filter is used by the user to force the traffic policy on the network device. + + # settrans -acfg /dev/fveth0 /root/hurd/eth-filter/eth-filter -i /root/multiplexer/veth0 -S 192.168.8.0/24 -R 192.168.8.0/24 + # settrans -acfg /dev/fveth1 /root/hurd/eth-filter/eth-filter -i /root/multiplexer/veth1 -S 192.168.8.0/24 -R 192.168.8.0/24 + +Step 7: setup the pfinet server on the virtual network device. + + # settrans -afgc /root/socket0/2 /root/hurd/pfinet/pfinet -i /dev/fveth0 -a 192.168.8.10 -g 192.168.8.1 -m 255.255.255.0 + # settrans -afgc /root/socket1/2 /root/hurd/pfinet/pfinet -i /dev/fveth1 -a 192.168.8.11 -g 192.168.8.1 -m 255.255.255.0 + + +#### 1.3 Run the command with the customized pfinet server. + +Step 8: Set environment variables to use the customized pfinet server. + +The environment variable of SOCK_SERV_DIR is used to override all socket servers and SOCK_SERV_%d to override a specific socket server. %d after SOCK_SERV_ is the domain of the protocol that the socket server supports. The environment variable SOCK_SERV_%d has the higher priority than SOCK_SERV_DIR. + + # export SOCK_SERV_2=/root/socket1/2 + +If the modified glibc isn't installed as the system default C library, set LD_LIBRARY_PATH environment. + + # export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/the/path/of/glibc + +We can run any command now, for example, ping. + +A SHELL script is provided to run all translators I mentioned automatically: http://www.assembla.com/spaces/VNetHurd/documents/c2W71ABser3AIxab7jnrAJ/download/runmultiplexer. To use this script, the user must specify the source of the hurd tree (the default value is /root/hurd) and the path of the servers (the default value is /root) where they should be created. This script is only used to test all translators I mentioned above and shows all steps to set up the virtual network. + + +### 2. Connect the subhurd with the main hurd. + +In the main hurd, we still need to do Step 1-8. +We run subhurd, + + # /root/hurd/boot/boot -m eth0=/dev/fveth0 -m eth1=/dev/fveth1 servers.boot /dev/hd1s1 + +In the subhurd, we do Step 1, 4, 8. +Step 4: # settrans -acfg /dev/veth0 /root/hurd/devnode/devnode -d veth0 +Step 7: # settrans -afgc /servers/socket/2 /root/hurd/pfinet/pfinet -i /dev/veth0 -a 192.168.8.20 -g 192.168.8.1 -m 255.255.255.0 + +Now we can communicate from the subhurd with any pfinet server of the main Hurd that runs in the virtual network. |
