IRC.

5 files changed, 158 insertions, 6 deletions

diff --git a/hurd/translator/devfs.mdwn b/hurd/translator/devfs.mdwn
index 8784e998..a9cc307f 100644
--- a/hurd/translator/devfs.mdwn
+++ b/hurd/translator/devfs.mdwn
@@ -12,7 +12,7 @@ License|/fdl]]."]]"""]]
 in there in a dynamic fashion -- as compared to static passive translator
 settings as they're used now.
 
-`devfs` has not yet been written.
+`devfs` has not yet been written.  [[!tag open_issue_hurd]]
 
 ---
 
@@ -23,6 +23,8 @@ path is resident at all times.
 
 # IRC, freenode, #hurd, 2012-01-29
 
+[[!tag open_issue_documentation]]
+
     <pinotree> what would be an hurdish way to achieve something like the
       various system (udev, devfs, devd, etc) for populating devices files
       automatically according to the found system devices?
@@ -37,3 +39,35 @@ path is resident at all times.
       /dev directory with unique device names... probably need some
       unionfs-like translator that collects the individual driver nodes in an
       intelligent manner
+
+
+# IRC, freenode, #hurd, 2012-04-22
+
+    <antrik> braunr: I don't think it's a problem that translators are invoked
+      when listing /dev
+    <antrik> the problem is that they linger around although they are very
+      unlikely to be needed again any time soon
+    <youpi> for now it's not too much a problem because there aren't too many
+    <youpi> but that can become problematic
+    <pinotree> a devfs on /dev could also fill it with new devices
+    <youpi> but only with the ones that actually exist
+    <pinotree> yeah
+    <braunr> antrik: i mean, the hurd may lack a feature allowing the same
+      translator to be used for several nodes not hierarically related
+    <braunr> antrik: or rather, it's a special case that we should implement
+      differently
+    <braunr> (with e.g. a devfs that can route requests for different nodes to
+      a same translator
+    <braunr> )
+    <antrik> I agree BTW that some intermediary for /dev would be helpful --
+      but I don't think it should actually take over any RPC handling; rather,
+      only redirect the requests as appropriate (with the actual device nodes
+      in a hierarchical bus-centric layout)
+    <braunr> right
+    <antrik> braunr: actually, the Hurd *does* have a feature allowing the same
+      translator to be attached to several unrelated nodes
+    <braunr> i keep getting surprised :)
+    <antrik> though it's only used in very few places right now
+    <youpi> pfinet and ptys at least ?
+    <antrik> yeah, and console client IIRC
+
diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn
index fff2e74b..ad79c7b9 100644
--- a/hurd/translator/ext2fs.mdwn
+++ b/hurd/translator/ext2fs.mdwn
@@ -1,18 +1,23 @@
-[[!meta copyright="Copyright © 2007, 2008, 2010, 2011 Free Software Foundation,
-Inc."]]
+[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 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]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
 
 # Implementation
 
   * [[filetype]] option
 
+  * [[Hurd-specific_extensions]]
+
+  * [[Page_cache]]
+
 
 ## Large Stores
 
diff --git a/hurd/translator/ext2fs/hurd-specific_extensions.mdwn b/hurd/translator/ext2fs/hurd-specific_extensions.mdwn
new file mode 100644
index 00000000..774f1cf3
--- /dev/null
+++ b/hurd/translator/ext2fs/hurd-specific_extensions.mdwn
@@ -0,0 +1,23 @@
+[[!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]]."]]"""]]
+
+[[!tag open_issue_documentation]]
+
+
+# IRC, freenode, #hurd, 2012-04-20
+
+    <Tekk_> what are the extensions to ext2?
+    <Tekk_> that hurd uses
+    <braunr> tha ability to store passive translator command lines in the
+      inodes
+    <braunr> the*
+    <antrik> well, also a fourth set of permission bits, and an "author" field
+    <braunr> right
+    <antrik> both very obscure features that better never existed...
diff --git a/hurd/translator/ext2fs/page_cache.mdwn b/hurd/translator/ext2fs/page_cache.mdwn
new file mode 100644
index 00000000..e8a964ed
--- /dev/null
+++ b/hurd/translator/ext2fs/page_cache.mdwn
@@ -0,0 +1,31 @@
+[[!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]]."]]"""]]
+
+[[!tag open_issue_documentation]]
+
+This is not at all specific to ext2fs, so should be integrated elsewhere.
+
+
+# IRC, freenode, #hurd, 2012-04-22
+
+    <Tekk_> is there any particular reason ext2fs takes so much memory?
+    <Tekk_> it beats everything on my system hands down at 100 MB
+    <youpi> ext2fs contains the page cache
+    <youpi> so it's no wonder it takes memory
+    <youpi> it's all the mapped files
+    <Tekk_> any way I can cut down on that?
+    <Tekk_> my system only has 512 meg :/
+    <youpi> gnumach is supposed to automatically cut it down as needed
+    <youpi> what is the actual symptom that you see?
+    <Tekk_> youpi: 360 MB of memory usage when I'm doing nothing
+    <Tekk_> oh, is it just intelligent enough to cut down when I'm using more
+      memory?
+    <youpi> Tekk_: yes
+    <Tekk_> awesome. I was worried :)
diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn
index 339fab50..e7fdf46e 100644
--- a/hurd/translator/procfs/jkoenig/discussion.mdwn
+++ b/hurd/translator/procfs/jkoenig/discussion.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2010, 2011, 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
@@ -218,3 +219,61 @@ Needed by glibc's `pldd` tool (commit
 # `/proc/self/exe`
 
 [[!message-id "alpine.LFD.2.02.1110111111260.2016@akari"]]
+
+
+# `/proc/[PID]/fd/`
+
+## IRC, freenode, #hurd, 2012-04-24
+
+    <antrik> braunr: /proc/*/fd can be implemented in several ways. none of
+      them would require undue centralisation
+    <antrik> braunr: the easiest would be adding one more type of magic lookup
+      to the existing magic lookup mechanism
+    <antrik> wait, I mean /proc/self... for /proc/*/fd it's even more
+      straighforward -- we might even have a magic lookup for that already
+    <pinotree> i guess the ideal thing would be implement that fd logic in
+      libps
+    <antrik> pinotree: nope. it doesn't need to ask proc (or any other server)
+      at all. it's local information. that's what we have the magic lookups for
+    <antrik> one option we were considering at some point would be using the
+      object migration mechanism, so the actual handling would still happen
+      client-side, but the server could supply the code doing it. this would
+      allow servers to add arbitrary magic lookup methods without any global
+      modifications... but has other downsides :-)
+    <gnu_srs> youpi: How much info for /proc/*/fd is possible to get from
+      libps? Re: d-h@
+    <youpi> see my mail
+    <youpi> I don't think there is an interface for that
+    <youpi> processes handle fds themselves
+    <youpi> so libps would have to peek in there
+    <youpi> and I don't remember having seen any code like that
+    <gnu_srs> 10:17:17< antrik> wait, I mean /proc/self... for /proc/*/fd it's
+      even more straighforward -- we might even have a magic lookup for that
+      already
+    <gnu_srs> pinotree: For me that does not ring a bell on RPCs. Don't know
+      what magic means,,
+    <youpi> for /proc/self/fd we have a magic lookup
+    <youpi> for /proc/pid/fd, I don't think we have
+    <gnu_srs> magic lookup*
+    <gnu_srs> magic lookup == RPC?
+    <youpi> magic lookup is a kind of answer to the lookup RPC
+    <youpi> that basically says "it's somewhere else, see there"
+    <youpi> the magic FD lookup tells the process "it's your FD number x"
+    <youpi> which works for /proc/self/fd, but not /proc/pid/fd
+    <civodul> youpi, gnu_srs: regarding FDs, there the msg_get_fd RPC that
+      could be used
+    <civodul> `msgport' should have --get-fd, actually
+    <youpi> civodul: I assumed that the reason why msgport doesn't have it is
+      that it didn't exist
+    <youpi> so we can get a port on the fd
+    <youpi> but then how to know what it is?
+    <civodul> youpi: ah, you mean for the /proc/X/fd symlinks?
+    <civodul> good question
+    <civodul> it's not designed to be mapped back to names, indeed :-)
+    <antrik> youpi: yeah, I realized myself that only /proc/self/fd is trivial
+    <antrik> BTW, in Linux it's nor real symlinks. it's magic, with some very
+      strange (but useful in certain situations) semantics
+    <antrik> not real symlinks
+    <antrik> it's very weird for example for fd connected to files that have
+      been unlinked. it looks like a broken symlink, but when dereferencing
+      (e.g. with cp), you get the actual file contents...