14 files changed, 287 insertions, 23 deletions
diff --git a/hurd/advantages.mdwn b/hurd/advantages.mdwn
index a181a942..ba3a134b 100644
--- a/hurd/advantages.mdwn
+++ b/hurd/advantages.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2001, 2002, 2008 Free Software Foundation,
+[[!meta copyright="Copyright © 2001, 2002, 2008, 2010 Free Software Foundation,
 Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -58,3 +58,11 @@ but it does have a number of enticing features:
     The Hurd is real software that works Right Now.  It is not a research
     project or a proposal.  You don't have to wait at all before you can start
     using and developing it.
+
+---
+
+One advantage of the Hurd's separation of kernel-like functionality into
+separate components ([[servers|translator]]) is that these can be constructed
+using different programming lanugages, a thing that is not easily possible in a
+monolithic kernel.  Essentially, only an interface from the programming
+environment to the RPC mechanism is required.
diff --git a/hurd/debugging/rpctrace.mdwn b/hurd/debugging/rpctrace.mdwn
index 46f40508..de46c08d 100644
--- a/hurd/debugging/rpctrace.mdwn
+++ b/hurd/debugging/rpctrace.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation,
+[[!meta copyright="Copyright © 2007, 2008, 2009, 2010 Free Software Foundation,
 Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -18,6 +18,8 @@ See `rpctrace --help` about how to use it.
 
 # Issues and Patches
 
+[[!tag open_issue_hurd]]
+
 * <http://savannah.gnu.org/patch/?2104> -- don't assert that local port names
   are valid
 * <http://savannah.gnu.org/bugs/?3939> -- `rpctrace`d program hangs when signal
@@ -26,10 +28,26 @@ See `rpctrace --help` about how to use it.
     programs hang
 * <http://savannah.gnu.org/patch/?5580> -- more readable output
 
+* IRC, unknown channel, unknown date
+
+        <youpi> how to rpctrace a translator ?
+        <youpi> ah, just settrans /usr/bin/rpctrace...
+        <youpi> hum, it hung, and killing it got a Mach panic (thread in unexpected
+          state) ...
+
+* IRC, unknown channel, unknown date
+
+        <antrik> hm... for a funny effect, try running rpctrace on
+          /servers/socket/1, and then use dpkg... ;-)
 
-# TODO
+* IRC, unknown channel, unknown date.
 
-    <youpi> how to rpctrace a translator ?
-    <youpi> ah, just settrans /usr/bin/rpctrace...
-    <youpi> hum, it hung, and killing it got a Mach panic (thread in unexpected
-      state) ...
+        <youpi> the problem of rpctrace is that it's a man in the middle :)
+        <youpi> so in principle, by design authentication stuff shouldn't work
+        <antrik> I don't think the Hurd auth mechanism in any way prevents or tries to prevent man-in-the-middle...
+        <youpi> maybe, but just try, you'll see all kinds of issue as soon as you have authentication stuff
+        <youpi> and the basic reason is that being a man in the middle needs special care
+        <youpi> which rpctrace doesn't completely do
+        <antrik> it's a while since I have dived into rpctrace; but AIUI, it should work just fine if the proxying is done properly
+        <antrik> note that there is a number of known bugs in rpctrace, for which zhengda has sent patches... though I haven't reviewed all of them I think
+        <antrik> there are some nasty Mach operations that are really hard to proxy -- but I don't think the auth mechanism needs any of these...
diff --git a/hurd/debugging/translator/capturing_stdout_and_stderr.mdwn b/hurd/debugging/translator/capturing_stdout_and_stderr.mdwn
index 1e8c4ef6..b7cfc3c9 100644
--- a/hurd/debugging/translator/capturing_stdout_and_stderr.mdwn
+++ b/hurd/debugging/translator/capturing_stdout_and_stderr.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]]
+[[!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
@@ -33,6 +34,4 @@ using the appropriate glibc magic (`setvbuf`).  Otherwise you'll see text in
 the output files only if either glibc herself decides to flush (after some KiB
 of text) the after translator exits.
 
-It is a [[!taglink open_issue_hurd]] to decide / implement / fix that
-(all?) running (passive?) translators' output should show up on the
-console / syslog.
+There is also a [[related open issue|open_issues/translator_stdout_stderr]].
diff --git a/hurd/libfshelp.mdwn b/hurd/libfshelp.mdwn
new file mode 100644
index 00000000..4eda91b6
--- /dev/null
+++ b/hurd/libfshelp.mdwn
@@ -0,0 +1,29 @@
+[[!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]]."]]"""]]
+
+TODO.
+
+
+# Open Issues
+
+[[!tag open_issue_hurd]]
+
+  * IRC, unknown channel, unknown date
+    
+        <flavioc> antrik, i had some problems with CLISP. it goes into an infinite loop when there's no stdin or stdout (fshelp closes them when a translator starts). At first I tried to patch it but CLISP has very intricate dependencies on them, so I just created a wraper program (run-lisp-trans) that opens /dev/null as stdin and stdout and then exec's clisp
+        <marcus> flavioc, antrik: I would suggest to modify libfshelp to start translators with stdin/stdout mapped to /dev/null.
+        <marcus> or is there a good reason not to?
+        <flavioc> marcus, the problem is in clisp :-), it should not expect that stdin/stdout are always open
+        <marcus> flavioc: I agree, but there is really no point in making it hard.  many programs will fail if stdin, stdout or stderr are not occupied.  historically, they expect them to be there, so IMO libfshelp should be changed
+        <marcus> flavioc: it's a simple solution, works everywhere and shouldn't do any harm :)
+        <flavioc> marcus, I see. should I propose that on the mailing list? :-)
+        <marcus> flavioc: it might be simpler to just crack the svn server and sneak it in :)
+        <marcus> if you submit a patch I will look at it and check it in if it is ok
+        <marcus> and see if Roland is still watching ... :D
diff --git a/hurd/libihash.mdwn b/hurd/libihash.mdwn
new file mode 100644
index 00000000..770770c7
--- /dev/null
+++ b/hurd/libihash.mdwn
@@ -0,0 +1,52 @@
+[[!meta copyright="Copyright © 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_hurd]]
+
+  * Hurd libihash
+
+      * old
+
+      * new
+
+  * hurd-l4 libhurd-ihash
+
+  * [[viengoos libhurd-ihash|microkernel/viengoos/projects/new_hash_function]]
+
+    IRC, unknown channel, unknown date
+
+        <neal> so, we need a new ihash implementation
+        <neal> marcusb: When 80% full, the collision rate is very high.
+        <neal> marcusb: I tested using 512mb / 4096 entries
+        <neal> marcusb: Changing the load factor to 30% resulted in my program running more than an order of magnitude faster.
+        <marcusb> yeah, it shouldn't get so full
+        <marcusb> don't we do an exponential back-off in the array size?
+        <marcusb> of course it's clear we can do much better
+        <marcusb> the ihash algo is very simple
+        <marcusb> I'm not even sure it makes much sense to have a generic library
+
+
+# Alternatives?
+
+  * glibc
+
+      * include/inline-hashtab.h
+
+      * locale/programs/simple-hash.h
+
+      * misc/hsearch_r.c
+
+      * NNS; cf. f46f0abfee5a2b34451708f2462a1c3b1701facd
+
+  * <http://cmph.sourceforge.net/>
+
+  * <http://libhashish.sourceforge.net/>
+
+  * <http://www.azillionmonkeys.com/qed/hash.html>
diff --git a/hurd/libnetfs.mdwn b/hurd/libnetfs.mdwn
index a2bf47ee..8625f8bc 100644
--- a/hurd/libnetfs.mdwn
+++ b/hurd/libnetfs.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2007, 2008, 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
@@ -33,7 +34,7 @@ which is, generally speaking, seriously different from *libnetfs*.
 All in all, *libnetfs* is the library you would choose when you want
 to write a translator which will show a file (or a directory) in a
 modified way (for example, if you'd like to show only *.sh* files or
-make an archive look unpacked). As different from *libtrivfs*, using
+make an archive look unpacked). As different from *[[libtrivfs]]*, using
 *libnetfs*, you can show to your clients not just a single file, but a
 whole directory tree.
 
@@ -229,7 +230,7 @@ performance or to solve specific problems.
 ##Synchronization is Crucial
 
 A *libnetfs* programmer shall always keep in mind that, as different
-from *libtrivfs*-based translators, *libnetfs*-based translators are
+from *[[libtrivfs]]*-based translators, *libnetfs*-based translators are
 always multithreaded. To guard data against damage each node
 incorporates a lock. Moreover, each light node usually contains a
 lock, too. This happens because *libnetfs* nodes and light nodes are
diff --git a/hurd/libports.mdwn b/hurd/libports.mdwn
index f9aa518f..28274338 100644
--- a/hurd/libports.mdwn
+++ b/hurd/libports.mdwn
@@ -14,3 +14,7 @@ ports|microkernel/mach/port]].  It is documented in the [[Reference_Manual]].
 *libports* is not (at least, not for now) a generalization / abstraction of
 Mach ports to the functionality the Hurd needs, that is, it is not meant to
 provide an interface independently of the underlying [[microkernel]].
+
+*libports* does not itself depend on *[[libthreads]]*, but the appropriate
+threading hooks are used if present, that is if *[[libthreads]]* is used by
+another component.
diff --git a/hurd/libtrivfs.mdwn b/hurd/libtrivfs.mdwn
new file mode 100644
index 00000000..b15aeabe
--- /dev/null
+++ b/hurd/libtrivfs.mdwn
@@ -0,0 +1,31 @@
+[[!meta copyright="Copyright © 1994, 1996, 1998, 1999, 2000, 2001, 2002, 2003,
+2004, 2005, 2007, 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]]."]]"""]]
+
+Certain [[translator]]s do not need to be very complex, because they represent
+a single file rather than an entire directory hierarchy.  The *trivfs library*,
+which is declared in `<hurd/trivfs.h>`, does most of the work of implementing
+this kind of translator.  This library requires the [[iohelp|libiohelp]] and
+[[ports|libports]] libraries.
+
+Using `libtrivfs` is not the only way to implement such a single-file
+translator, but is a convenient abstraction: the library hides a lot of
+low-level stuff and you just have to provide a number of call-back functions
+and symbols in order to get a functioning (for file I/O, etc.) node in the file
+system.
+
+
+# Further Reading
+
+  * In the *[[The_GNU_Hurd_Reference_Manual|reference_manual]]*:
+    <http://www.gnu.org/software/hurd/doc/hurd_6.html#SEC48>.
+
+  * In the *[[Hurd_Hacking_Guide]]*:
+    <http://www.gnu.org/software/hurd/hacking-guide/hhg.html#An-Example-using-trivfs>.
diff --git a/hurd/running/arch_hurd.mdwn b/hurd/running/arch_hurd.mdwn
index 6635f415..cc2ad0f2 100644
--- a/hurd/running/arch_hurd.mdwn
+++ b/hurd/running/arch_hurd.mdwn
@@ -11,3 +11,13 @@ License|/fdl]]."]]"""]]
 [[!meta title="Arch Hurd"]]
 
 <http://www.archhurd.org/>
+
+From the website: 
+
+*Welcome to the Arch Hurd website. Arch Hurd is a derivative work of Arch Linux porting it to the GNU Hurd system with packages optimised for the i686 architecture.*
+*…*
+*We are attempting to bring the spirit of Arch Linux to the Hurd, and if you'd like to help us achieve that, we'd love to hear from you.*
+
+Status as of 2010-07-31: 
+
+* LiveCD with [installation guide](http://wiki.archhurd.org/wiki/Installation_Guide). 
diff --git a/hurd/running/distrib.mdwn b/hurd/running/distrib.mdwn
index 92904d19..c197ad0e 100644
--- a/hurd/running/distrib.mdwn
+++ b/hurd/running/distrib.mdwn
@@ -4,6 +4,7 @@ Working distributions of GNU/Hurd:
 
 GNU/Hurd distributions in early stages of development: 
 
+* [[Arch|arch_hurd]] (features a LiveCD)
 * [[Gentoo]]
 * [[GNU]]
 
diff --git a/hurd/translator.mdwn b/hurd/translator.mdwn
index 44ba4dff..75020cb2 100644
--- a/hurd/translator.mdwn
+++ b/hurd/translator.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation,
+[[!meta copyright="Copyright © 2007, 2008, 2009, 2010 Free Software Foundation,
 Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -18,6 +18,12 @@ and [[pfinet]]) and thus translates object invocations
 into calls appropriate for the backing store
 (e.g., ext2 file system, nfs server, etc.).
 
+Another way of putting it is that it translates from one representation of a
+data structure into another representation, for example from the on-disk
+[[ext2|ext2fs]] data layout to a traditional file system hierarchy, or from a
+XML file to a virtual hierarchical manifestation.  This translation can be a
+bidirectional process, but it need not be.
+
 A translator is usually registered with a specific file system node by using
 the [[`settrans`|settrans]] command.
 
@@ -108,3 +114,28 @@ Read about translator [[short-circuiting]].
 
   * [[wishlist_1]]
   * [[wishlist_2]]
+
+
+# Internally
+
+## `*_demuxer` Functions
+
+  * IRC, unknown channel, unknown date
+
+        <jim-crow> what is a main idea of _demuxer functions in translators?
+        <neal> jim-crow: Think of a web server.
+        <neal> jim-crow: A typical web server must process many different requests.
+        <neal> jim-crow: There are different types of requests.
+        <neal> jim-crow: For instance, static pages and dynamically gnereated content.
+        <neal> the static pages are processed by one function
+        <neal> and the dynamic pages by another
+        <neal> the thing that makes the decision which of these functions to pass the request to is the demuxer.
+        <jim-crow> neal: ok, I see
+        <jim-crow> but what is actually it doing in trivfs_demuxer?
+        <neal> it looks at the message id and calls the right server stub
+        <jim-crow> for example it calls trivfs_io_server function, but I can't find its implementation
+        <jim-crow> that's my main question :-)
+        <neal> look at the files mig generates
+        <jim-crow> neal: ok, thanks
+        <jim-crow> neal: is this functions where actually stubs are called?
+        <neal> I think so.
diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn
index 441fb00f..69d035db 100644
--- a/hurd/translator/ext2fs.mdwn
+++ b/hurd/translator/ext2fs.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2007, 2008, 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
@@ -8,11 +9,20 @@ 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]]."]]"""]]
 
+# Issues
+
 The `ext2fs` translator from the upstream Hurd code base can only handle file
 systems with sizes of less than roughly 2 GiB.
 
+[[!tag open_issue_hurd]]
+
 A patch exists to lift this limitation (and is being used in the
 [[Debian_GNU/Hurd_distribution|running/debian]]), but it introduces another
 incompatibility: `ext2fs` then only supports block sizes of 4096 bytes.
 Smaller block sizes are commonly automatically selected by `mke2fs` when using
 small backend stores, like floppy devices.
+
+
+# Documentation
+
+<http://www.nongnu.org/ext2-doc/>
diff --git a/hurd/translator/pfinet/ipv6.mdwn b/hurd/translator/pfinet/ipv6.mdwn
index 996ffd6d..5afee0c6 100644
--- a/hurd/translator/pfinet/ipv6.mdwn
+++ b/hurd/translator/pfinet/ipv6.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2007, 2008, 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
@@ -51,10 +52,6 @@ Quite the same, but with static IPv6 address assignment:
       -A 2001:4b88:10e4:0:216:3eff:feff:4223/64 -G 2001:4b88:10e4::1
 
 
-# Binaries
+# Missing Functionality
 
-For your convenience -- this work is not yet available in the Debian packages
--- binaries of a patched (multicast reception) GNU Mach kernel (including
-default driver set and debugging support) and a stripped pfinet translator
-(named `pfinet6` here) are being provided at
-<http://brokenpipe.de/GnuHurd/pfinet6/>
+Amongst other things, support for [[IOCTL]]s is missing.
diff --git a/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn b/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn
new file mode 100644
index 00000000..ef041a23
--- /dev/null
+++ b/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn
@@ -0,0 +1,73 @@
+[[!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, freenode, 2010
+
+    <slpz> humm... why does tmpfs try to use the default pager? that's a bad idea, and probably will never work correctly...
+    * slpz is thinking about old issues
+    <slpz> tmpfs should create its own pagers, just like ext2fs, storeio...
+    <slpz> slopez@slp-hurd:~$ settrans -a tmp /hurd/tmpfs 10M
+    <slpz> slopez@slp-hurd:~$ echo "foo" > tmp/bar
+    <slpz> slopez@slp-hurd:~$ cat tmp/bar
+    <slpz> foo
+    <slpz> slopez@slp-hurd:~$ 
+    <slpz> :-)
+    <pochu> slpz: woo you fixed it?
+    <slpz> pochu: well, it's WIP, but reading/writing works...
+    <slpz> I've replaced the use of default pager for the standard pager creation mechanism
+    <antrik> slpz: err... how is it supposed to use swap space if not using the default pager?
+    <antrik> slpz: or do you mean that it should act as a proxy, just allocating anonymous memory (backed by the default pager) itself?
+    <youpi> antrik: the kernel uses the default pager if the application pager isn't responsive enough
+    <slpz> antrik: it will just create memory objects and provide zerofilled pages when requested by the kernel (after a page fault)
+    <antrik> youpi: that makes sense I guess... but how is that relevant to the question at hand?...
+    <slpz> antrik: memory objects will contain the data by themselves
+    <slpz> antrik: as youpi said, when memory is scarce, GNU Mach will start paging out data from memory objects to the default pager
+    <slpz> antrik: that's the way in which pages will get into swap space
+    <slpz> (if needed)
+    <youpi> the thing being that the tmpfs pager has a chance to select pages he doesn't care any more about
+    <antrik> slpz: well, the point is that instead of writing the pages to a backing store, tmpfs will just keep them in anonymous memory, and let the default pager write them out when there is pressure, right?
+    <antrik> youpi: no idea what you are talking about. apparently I still don't really understand this stuff :-(
+    <youpi> ah, but tmpfs doesn't have pages he doesn't care about, does it?
+    <slpz> antrik: yes, but the term "anonymous memory" could be a bit confusing.
+    <slpz> antrik: in GNU Mach, anonymous memory is backed by a memory object without a pager. In tmpfs, nodes will be allocated in memory objects, and the pager for those memory objects will be tmpfs itself
+    <antrik> slpz: hm... I thought anynymous memory is backed by memory objects created from the default pager?
+    <antrik> yes, I understand that tmpfs is supposed to be the pager for the objects it provides. they are obviously not anonymoust -- they have inodes in the tmpfs name space
+    <antrik> but my understanding so far was that when Mach returns pages to the pager, they end up in anonymous memory allocated to the pager process; and then this pager is responsible for writing them back to the actual backing store
+    <antrik> am I totally off there?...
+    <antrik> (i.e. in my understanding the returned pages do not reside in the actual memory object the pager provides, but in an anonymous memory object)
+    <slpz> antrik: you're right. The trick here is, when does Mach return the pages?
+    <slpz> antrik: if we set the attribute "can_persist" in a memory object, Mach will keep it until object cache is full or memory is scarce
+    <slpz> or we change the attributes so it can no longer persist, of course
+    <slpz> without a backing store, if Mach starts sending us pages to be written, we're in trouble
+    <slpz> so we must do something about it. One option, could be creating another pager and copying the contents between objects.
+    <antrik> another pager? not sure what you mean
+    <antrik> BTW, you didn't really say why we can't use the default pager for tmpfs objects :-)
+    <slpz> well, there're two problems when using the default pager as backing store for translators
+    <slpz> 1) Mach relies on it to do swapping tasks, so meddling with it is not a good idea
+    <slpz> 2) There're problems with seqnos when trying to work with the default pager from tasks other the kernel itself
+    <slpz> (probably, the latter could be fixed)
+    <slpz> antrik: pager's terminology is a bit confusing. One can also say creating another memory object (though the function in libpager is "pager_create")
+    <antrik> not sure why "meddling" with it would be a problem...
+    <antrik> and yeah, I was vaguely aware that there is some seqno problem with tmpfs... though so far I didn't really understand what it was about :-)
+    <antrik> makes sense now
+    <antrik> anyways, AIUI now you are trying to come up with a mechanism where the default pager is not used for tmpfs objects directly, but without making it inefficient?
+    <antrik> slpz: still don't understand what you mean by creating another memory object/pager...
+    <antrik> (and yeat, the terminology is pretty mixed up even in Mach itself)
+    <slpz> antrik: I meant creating another pager, in terms of calling again to libpager's pager_create
+    <antrik> slpz: well, I understand what "create another pager" means... I just don't understand what this other pager would be, when you would create it, and what for...
+    <slpz> antrik: oh, ok, sorry
+    <slpz> antrik: creating another pager it's just a trick to avoid losing information when Mach's objects cache is full, and it decides to purge one of our objects
+    <slpz> anyway, IMHO object caching mechanism is obsolete and should be replaced
+    <slpz> I'm writting a comment to bug #28730 which says something about this
+    <slpz> antrik: just one more thing :-) 
+    <slpz> if you look at the code, for most time of their lives, anonymous memory objects don't have a pager
+    <slpz> not even the default one
+    <slpz> only the pageout thread, when the system is running really low on memory, gives them a reference to the default pager by calling vm_object_pager_create
+    <slpz> this is not really important, but worth noting ;-)