Prepare toolchain/logs/master branch.

11 files changed, 0 insertions, 528 deletions

diff --git a/microkernel/viengoos/building.mdwn b/microkernel/viengoos/building.mdwn
deleted file mode 100644
index 45111c35..00000000
--- a/microkernel/viengoos/building.mdwn
+++ /dev/null
@@ -1,100 +0,0 @@
-[[!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]]."]]"""]]
-
-Check out Viengoos and switch to the viengoos-on-bare-metal branch
-(all development is currently done on this branch and it will
-eventually be merged into the master branch):
-
-    $ git clone git://git.savannah.gnu.org/hurd/viengoos.git
-    $ cd viengoos
-    $ git checkout -b viengoos-on-bare-metal origin/viengoos-on-bare-metal
-
-Generate the autoconf environment (note that --force is not specified
-as we have our own version of config.guess and config.sub):
-
-    $ autoreconf -i
-
-Configure a build directory:
-
-    $ mkdir build
-    $ cd build
-    $ ../configure --host=x86_64-pc-viengoos-gnu --with-newlib
-
-Now, build Viengoos.  Running make the first time will automatically
-fetch binutils and gcc from the Internet and build a cross compiler.
-Running make again will build the Viengoos proper.  Again, the build
-process with fetch several tarballs including Newlib, the Boehm GC and
-Sqlite.
-
-    $ make
-    ...
-    The cross compiler is now set-up.  Re-run `make' and proceed as usual.
-    make[2]: Leaving directory `.../viengoos/build'
-    make[1]: Leaving directory `.../viengoos/build'
-    $ make
-
-# Booting Using QEMU
-
-To boot Viengoos, use Grub 2.  You cannot use Grub Legacy: Viengoos is
-an ELF64 executable, which Grub Legacy does not support.
-
-First, check out Grub 2 from svn:
-
-    $ svn co svn://svn.savannah.gnu.org/grub/trunk/grub2
-    $ cd grub2
-
-Before building Grub 2, you should apply the following patch, which
-makes it easy to tell Grub to load a specific grub.cfg at start up
-([details](http://lists.gnu.org/archive/html/grub-devel/2009-01/msg00099.html)).
-
-    $ wget http://www.gnu.org/software/hurd/microkernel/viengoos/grub2-config.diff -O /dev/stdout | patch -p0
-
-Next, build Grub 2:
-
-    $ ./autogen.sh
-    $ mkdir build
-    $ cd build
-    $ ../configure --prefix=`pwd`/../install
-    $ make && make install
-
-Create the boot disk:
-
-    $ cd ../install
-    $ bin/grub-mkrescue boot.img  --configfile="(hd0,1)/grub.cfg" --image-type=floppy --modules='help reboot serial multiboot pc configfile normal boot fat'
-
-Now, create /viengoos and link viengoos and hieronymus into that
-directory:
-
-    $ mkdir /viengoos
-    $ cd /viengoos
-    $ ln -s ~/viengoos/build/viengoos/viengoos.stripped viengoos
-    $ ln -s ~/viengoos/build/hieronymus/hieronymus.stripped hieronymus
-
-Also, create a grub.cfg file in /viengoos/grub.cfg:
-
-    set timeout=1
-    set default=0
-    set root=hd0,1
-    
-    menuentry "Viengoos" {
-        multiboot /viengoos -D 3 -o serial
-        module /hieronymus
-    }
-
-NB: If you edit grub.cfg and a backup file called grub.cfg~ is
-created, qemu will use grub.cfg~ instead of grub.cfg!  Thus, after
-editing grub.cfg, be sure to delete any grub.cfg~ file!
-
-Finally, boot!
-
-    $ qemu-system-x86_64 -serial stdio -fda ~/grub2/install/boot.img -hda fat:/viengoos -boot a
-
-By default, Hieronymus is configured to load ruth, a test suite.  Ruth
-can take a long time to complete.
diff --git a/microkernel/viengoos/documentation.mdwn b/microkernel/viengoos/documentation.mdwn
deleted file mode 100644
index edcc79a7..00000000
--- a/microkernel/viengoos/documentation.mdwn
+++ /dev/null
@@ -1,62 +0,0 @@
-[[!meta copyright="Copyright © 2008, 2012 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]]."]]"""]]
-
-The most up-to-date documentation is in the source code itself, see in
-particular the header files in the hurd directory.
-
-There is a started but as-of-yet incomplete manual in the doc
-directory, which documents the Viengoos API and the Hurd API.  A
-version of that is available [[here|reference-guide.pdf]].  It is
-not, however, automatically regenerated, and thus may not be up to
-date.
-
-
-# Academic Papers
-
-  * [Viengoos: A Framework for Stakeholder-Directed Resource
-    Allocation](http://walfield.org/papers/2009-walfield-viengoos-a-framework-for-stakeholder-directed-resource-allocation.pdf).
-    By Neal H. Walfield.  Submitted to EuroSys 2009.
-
-    General-purpose operating systems not only fail to provide adaptive
-    applications the information they need to intelligently adapt, but
-    also schedule resources in such a way that were applications to
-    aggressively adapt, resources would be inappropriately scheduled.  The
-    problem is that these systems use demand as the primary indicator of
-    utility, which is a poor indicator of utility for adaptive
-    applications.
-
-    We present a resource management framework appropriate for traditional
-    as well as adaptive applications.  The primary difference from current
-    schedulers is the use of stakeholder preferences in addition to
-    demand.  We also show how to revoke memory, compute the amount of
-    memory available to each principal, and account shared
-    memory.  Finally, we introduce a prototype system, Viengoos, and
-    present some benchmarks that demonstrate that it can efficiently
-    support multiple aggressively adaptive applications simultaneously.
-
-  * [Improving Usability via Access Decomposition and Policy
-    Refinement](http://walfield.org/papers/20070104-walfield-access-decomposition-policy-refinement.pdf).
-    By Neal H. Walfield and Marcus Brinkmann.  Technical report
-    (submitted to HotOS 2007).
-
-    Commodity operating systems fail to meet the security, resource
-    management and integration expectations of users.  We propose a unified
-    solution based on a capability framework as it supports fine grained
-    objects, straightforward access propagation and virtualizable
-    interfaces and explore how to improve resource use via access
-    decomposition and policy refinement with minimum interposition.  We
-    argue that only a small static number of scheduling policies are
-    needed in practice and advocate hierarchical policy specification and
-    central realization.
-
-
-# Miscellaneous
-
-  * [[IRC_2012-02-23]]
diff --git a/microkernel/viengoos/documentation/irc_2012-02-23.mdwn b/microkernel/viengoos/documentation/irc_2012-02-23.mdwn
deleted file mode 100644
index a3229be9..00000000
--- a/microkernel/viengoos/documentation/irc_2012-02-23.mdwn
+++ /dev/null
@@ -1,159 +0,0 @@
-[[!meta copyright="Copyright © 2012 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="IRC, freenode, #hurd, 2012-02-23"]]
-
-[[!tag open_issue_documentation open_issue_viengoos]]
-
-    <braunr> neal: i've read a bit about current modern microkernel based
-      systems, and i'm wondering
-    <braunr> neal: can a capability be used for both request and replies, or
-      does messaging need something similar to reply ports ?
-    <neal> braunr: you want a reply port
-    <neal> think about a file server:
-    <neal> the file server publishes a capability to access something
-    <neal> and multiple entities use it
-    <neal> if you wanted just bidirectional caps
-    <braunr> that's the idea i had in mind, i just wondered if it was actually
-      still the case in practice
-    <neal> you'd need to create a new capability every time you delegated the
-      cap
-    <braunr> yes
-    <braunr> thanks
-    <braunr> what about send once rights ?
-    <neal> also, if you send on a cap and then start waiting on it you could
-      get your own reply :)
-    <neal> you can get around send-once rights by using a counter
-    <braunr> no i mean, is their behaviour still needed/useful ?
-    <neal> the counter is kernel implemented
-    <neal> yes
-    <neal> as an optimization
-    <braunr> so they're just a special case of capability
-    <neal> yes
-    <braunr> not a special capability type of their own
-    <neal> but they eliminate the constant create/destroy sequence
-    <braunr> (even if it was already the case at the implementation level in
-      mach, they were named separately which could confuse people)
-    <braunr> hm
-    <braunr> actually, send once rights were used for important notifications
-      such as dead port notifications
-    <braunr> is this still handled at the kernel level in modern ukernels ?
-    <neal> in viengoos, this is called the version field
-    <neal> see chapter 2
-    <neal>
-      http://www.gnu.org/software/hurd/microkernel/viengoos/documentation/reference-guide.pdf
-    <braunr> neal: btw, congratulations for viengoos, it really is a very
-      interesting project: )
-    <neal> thanks
-    <braunr> i don't see the point of rewriting a mach clone after reading
-      about it eh
-    <neal> I would definately do the messenger concept again
-    <neal> but I'd not do persistence
-    <braunr> i don't fully understand how messengers deal with blocking
-    <neal> did you read chapter 4?
-    <braunr> i read all of it but didn't understand everything :)
-    <braunr> it's quite abstract and i didn't make time to read some of the
-      source code
-    <neal> If you have specific questions, I can try to help
-    <braunr> i'll read those chapter again and formulate my questions after
-    <neal> I may have to read them as well :)
-    <braunr> i don't understand how you manage to separate IPC from threading
-      actually
-    <braunr> are messengers queues ?
-    <neal> messengers are super-buffers
-    <neal> they contain a reference to a thread object
-    <neal> to send a message, I use a messenger
-    <neal> I put the data in a buffer
-    <neal> and then I attach the messenger to the target messenger
-    <antrik> braunr: my stance is that we should try to incorporate the ideas
-      from Viengoos into Mach in an evolutionary process...
-    <neal> this causes an activation to be sent to the target messenger's
-      thread object
-    <braunr> neal: which activation ?
-    <neal> an activation is like a CPU interrupt
-    <braunr> neal: is it "allocated" at that moment, or taken from the sending
-      thread ?
-    <braunr> (i'm not sure my question really makes sense to you :/)
-    <antrik> braunr: not sure what you are asking exactly; but the basic idea
-      is that the receiving process preallocates message buffers
-    <braunr> antrik: maybe, i'm not sure
-    <antrik> when someone sends a message, it's stored in one of these buffers,
-      and the process gets a scheduler activation, so it can decide what to do
-      with it
-    <neal> antrik is right
-    <neal> the traget messenger designates a memory buffer
-    <braunr> i'm wondering about the details of this activation
-    <braunr> is it similar to thread migration ?
-    <neal> just before the activation, the data is copied to the messenger's
-      buffer
-    <neal> now someone needs to be notified
-    <neal> (that a message arrived)
-    <neal> that someone is the thread designated in the target messenger's
-      thread field
-    <neal> this is done by an activation
-    <neal> an activation is just an upcall
-    <neal> a thread is forced to a particular IP
-    <neal> an activation isn't a "what" it's a "how"
-    <neal> I never understood thread migration
-    <neal> as it's not really about threads
-    <neal> nor it is about migration
-    <antrik> neal: what happens if another message comes in before the
-      activation handling tread is done with the previous one?...
-    <neal> the messenger is enqueued on the thread object
-    <neal> it is delivered when the thread is in normal mode
-    <neal> part of delivering an activation is putting the thread is activation
-      mode
-    <neal> when in activation mode, it can't receive any activations
-    <braunr> i see
-    <braunr> but then, when a thread receives an activation, does it handle
-      several queued messengers at once (not to loose events/messages) ?
-    <neal> (unless it does a blocking receive on a particular messenger, which
-      is necessary to support memory allocation in activated mode)
-    <neal> it handles one at a time
-    <braunr> ah right
-    <neal> it can't lose events
-    <braunr> activations are sent per messengers/events
-    <neal> well, it can
-    <neal> but it is possible to prevent this
-    <braunr> neal: also, is message passing completely atomic ?
-    <neal> I'm not sure what you mean
-    <neal> which part
-    <braunr> well, all parts of a message :)
-    <braunr> in mach, a message can contain several parts
-    <braunr> data, rights, passing one of them may fail
-    <braunr> only the header is atomically processed
-    <neal> it's not atomic in the sense that a thread can observe the data copy
-    <braunr> that's not what i meant
-    <braunr> is a message completely transferred or not at all in case of
-      failure ?
-    <neal> it may be partially transferred
-    <braunr> or can it be partially transferred
-    <braunr> ok
-    <neal> for instance, if the target thread doesn't provide a memory buffer
-    <neal> then the data can't be copied
-    <neal> I don't recall off hand how I dealt with bad addresses
-    <neal> may be it is not possible
-    <neal> I don't remember
-    <neal> sorry
-    <braunr> but if i read the message structure correctly, there can be one
-      data block, and several capability addresses in a single message, right ?
-    <neal> yes
-    <braunr> ok
-    <braunr> have you considered passing only one object (either data or
-      capability) per message ?
-    <braunr> or is it too inefficient ?
-    <neal> you at least need a reply port
-    <neal> s/port/messenger/
-    <braunr> yes but can't it be passed separately ?
-    <neal> then you have server state
-    <neal> ik
-    <braunr> hm yes
-    <braunr> thanks for your answers: )
-    <neal> no problem
diff --git a/microkernel/viengoos/documentation/reference-guide.pdf b/microkernel/viengoos/documentation/reference-guide.pdf
deleted file mode 100644
index 6fbea23b..00000000
--- a/microkernel/viengoos/documentation/reference-guide.pdf
+++ /dev/null
diff --git a/microkernel/viengoos/grub2-config.diff b/microkernel/viengoos/grub2-config.diff
deleted file mode 100644
index e4b1ef40..00000000
--- a/microkernel/viengoos/grub2-config.diff
+++ /dev/null
@@ -1,47 +0,0 @@
-2009-01-17  Neal H. Walfield  <address@hidden>
-
-        * util/i386/pc/grub-mkrescue.in: Add new option --configfile.  If
-        not the set and not the empty string, load it from the generated
-        config file on boot.
-
-Index: util/i386/pc/grub-mkrescue.in
-===================================================================
---- util/i386/pc/grub-mkrescue.in	(revision 2148)
-+++ util/i386/pc/grub-mkrescue.in	(working copy)
-@@ -49,6 +49,7 @@
-   --image-type=TYPE       select floppy or cdrom (default)
-   --emulation=TYPE        select El Torito boot emulation type floppy
-                           or none (default) (cdrom only)
-+  --configfile=FILE       config file to load (default: none)
- 
- grub-mkimage generates a bootable rescue image of the specified type.
- 
-@@ -93,6 +94,9 @@
-             echo "Unknown emulation type \`$emulation'" 1>&2
-             exit 1 ;;
-         esac ;;
-+    --configfile=*)
-+       configfile=`echo "$option" | sed 's/--configfile=//'`
-+        ;;
-     -*)
- 	echo "Unrecognized option \`$option'" 1>&2
- 	usage
-@@ -121,9 +125,15 @@
-   ${aux_dir}/boot/grub/
- 
- modules="biosdisk `cat ${input_dir}/partmap.lst` ${modules}"
--for i in ${modules} ; do
--  echo "insmod $i"
--done > ${aux_dir}/boot/grub/grub.cfg
-+{
-+  for i in ${modules} ; do
-+    echo "insmod $i"
-+  done
-+  if test x$configfile != x
-+  then
-+    echo "configfile $configfile"
-+  fi
-+} > ${aux_dir}/boot/grub/grub.cfg
- 
- for d in ${overlay}; do
-   echo "Overlaying $d"
diff --git a/microkernel/viengoos/hardware.mdwn b/microkernel/viengoos/hardware.mdwn
deleted file mode 100644
index aff70604..00000000
--- a/microkernel/viengoos/hardware.mdwn
+++ /dev/null
@@ -1,50 +0,0 @@
-[[!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]]."]]"""]]
-
-I boot over the network using PXE.
-
-On my build machine, I have installed a tftpserver.  Specifically, I use
-the one built into dnscache.  In /tftpboot, I have symlinks to pistachio,
-sigma0, and the root of the build tree.
-
-My build machine boots using PXE.  It gets an IP address, contacts
-my build machine and loads [grub2pxe](http://grub.enbug.org/PXEBOOT).
-Note that there is no need to use pxelinux; grub2 is a valid PXE
-executable.  Further, grub2 uses the PXE interface for accessing the
-network, so if your hardware supports PXE, then you do not need to
-worry about a network driver.  Here is how I build grub2 and the
-grub2 image:
-
-    cd ~/src
-    svn co svn://svn.savannah.gnu.org/grub/trunk/grub2
-    cd grub2
-    mkdir build
-    cd build
-    ../configure --prefix=$HOME/src/grub2/install && make && make install
-    cd ~/src/grub2/install
-    bin/grub-mkimage --output=core.img --prefix="(pxe)" pxe pxecmd help reboot serial multiboot pc configfile normal boot
-    cat lib/grub/i386-pc/pxeboot.img core.img > grub2pxe
-
-Here is my /tftpboot/grub.cfg, which sends output to the first
-[[serial_port]]:
-
-    # Timeout for menu
-    set timeout=1
-    
-    # Set default boot entry as Entry 0
-    set default=0
-    
-    menuentry "Viengoos" {
-        multiboot /viengoos/laden/laden -o serial -D
-        module /pistachio
-        module /sigma0
-        module /viengoos/viengoos/viengoos.stripped -D 3 -o serial
-        module /viengoos/hieronymus/hieronymus.stripped
-    }
diff --git a/microkernel/viengoos/projects.mdwn b/microkernel/viengoos/projects.mdwn
deleted file mode 100644
index 971206bb..00000000
--- a/microkernel/viengoos/projects.mdwn
+++ /dev/null
@@ -1,17 +0,0 @@
-[[!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]]."]]"""]]
-
-Some projects:
-
-[[!inline
-pages="microkernel/viengoos/projects/* and !microkernel/viengoos/projects/*/*"
-show=0
-feeds=no
-actions=yes]]
diff --git a/microkernel/viengoos/projects/address_space_management.mdwn b/microkernel/viengoos/projects/address_space_management.mdwn
deleted file mode 100644
index 2d00e4f4..00000000
--- a/microkernel/viengoos/projects/address_space_management.mdwn
+++ /dev/null
@@ -1,40 +0,0 @@
-[[!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]]."]]"""]]
-
-[[!tag open_issue_viengoos]]
-
-In Viengoos, a process's address space is managed entirely in user
-space by the process itself.  This creates two interesting problems:
-dealing with circular dependencies resulting from having to manage the
-address space data structures and accessing and manipulating the
-address space data structures.
-
-First, managing the address space requires resources, which in turn
-may require address space (e.g., data structures require memory which
-require address space, etc.).  We currently break this circular
-dependency by trying to keep enough resources in reserve that
-allocating resources for managing the address space never requires
-more resources than are minimally in the reserve.  The reserve is
-currently chosen in an ad-hoc fashion.  It would be nice to determine
-it more systematically.  Moreover, it would be nice to reduce the
-cases in which a reserve is required.  This may be possible by
-restructuring some of the code.
-
-Second, the address space data structures are protected using a single
-lock.  This not only means that only a single thread can be updating
-the address space at a time, but that if a thread faults and the
-address space is locked, then the process dead locks!  It should be
-possible to at least walk the address space using lock-free
-techniques.  This requires updating the address space construction
-code such that all addresses remain valid during any given
-manipulation.  Second, to avoid the mentioned dead-lock problem, we
-try to ensure that accessing the data structures will never result in
-a fault.  This means protecting the stack.  An alternative approach is
-to use undo buffers.
diff --git a/microkernel/viengoos/projects/capability-aware_compiler.mdwn b/microkernel/viengoos/projects/capability-aware_compiler.mdwn
deleted file mode 100644
index b4e465d9..00000000
--- a/microkernel/viengoos/projects/capability-aware_compiler.mdwn
+++ /dev/null
@@ -1,16 +0,0 @@
-[[!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]]."]]"""]]
-
-[[!tag open_issue_viengoos]]
-
-Modify, e.g., gcc to understand capability semantics and teach gcc how
-to optimize it, e.g., how to batch and combine calls.
-
-This project is deemed suitable for a thesis.
diff --git a/microkernel/viengoos/projects/new_hash_function.mdwn b/microkernel/viengoos/projects/new_hash_function.mdwn
deleted file mode 100644
index d0374720..00000000
--- a/microkernel/viengoos/projects/new_hash_function.mdwn
+++ /dev/null
@@ -1,22 +0,0 @@
-[[!meta copyright="Copyright © 2008, 2009, 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]]."]]"""]]
-
-[[!tag open_issue_viengoos]]
-
-The current hash function in libhurd-ihash results in a lot of
-collisions when the hash table is 80% full.  To overcome this, we keep
-hash tables at most 30% full.  This represents a fair amount of
-overhead.  Find a better algorithm.  There can either be one that is
-appropriate in the general case or one that works well in a relevant,
-specific case, e.g., viengoos/object.c uses a hash to find the object
-corresponding to a frame, which is keyed on its physical address.
-
-Note that this applies to the Hurd's [[hurd/libihash]], too.
diff --git a/microkernel/viengoos/serial_port.mdwn b/microkernel/viengoos/serial_port.mdwn
deleted file mode 100644
index 14efcb9f..00000000
--- a/microkernel/viengoos/serial_port.mdwn
+++ /dev/null
@@ -1,15 +0,0 @@
-[[!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]]."]]"""]]
-
-Viengoos can be configured to send output to the serial port (in fact,
-this is the only configuration that I use).  To talk to the serial
-port, I use ser2net, which provides a telnet interface to the serial
-port.  Be sure to edit /etc/ser2net.conf to use 115200 bps, which
-Viengoos uses by default.