manual merge

4 files changed, 201 insertions, 19 deletions

diff --git a/hurd/translator/discussion.mdwn b/hurd/translator/discussion.mdwn
new file mode 100644
index 00000000..e038ba84
--- /dev/null
+++ b/hurd/translator/discussion.mdwn
@@ -0,0 +1,25 @@
+[[!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_documentation open_issue_hurd]]
+
+IRC, freenode, #hurd, 2011-08-25:
+
+    < frhodes> how can I replace an existing running server with a new one
+      without rebooting?
+    < antrik> frhodes: depends. if other critical things depend on it, you
+      can't. there is no mechanism to serialize and pass on the open sessions
+    < antrik> in some situations, you can orphan the old translator while
+      starting a new one, so the previous clients will stay with the old one
+      while new one will get the new one
+    < antrik> obviously that only works for things that aren't exclusive by
+      nature
+    < antrik> in some cases, you might even be able simply to remove the old
+      translator... but obviously only for non-critical stuff :-)
diff --git a/hurd/translator/pfinet/dhcp.mdwn b/hurd/translator/pfinet/dhcp.mdwn
index 17776fa5..456d0c84 100644
--- a/hurd/translator/pfinet/dhcp.mdwn
+++ b/hurd/translator/pfinet/dhcp.mdwn
@@ -1,27 +1,33 @@
+[[!meta copyright="Copyright © 2002, 2003, 2005, 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_hurd]]
 
+[[Debian GNU/Hurd|running/debian]] has some script hackery to get
+[[running/debian/DHCP]] going.
+
+---
+
 According to the following thread, no port should be needed since all the patches that have been applied, including the one concerning the thread. In fact, the thread finishes without concluding whether the patch has been applied or not. You can grab it in the thread, anyway.
 
 [Link to thread](http://lists.gnu.org/archive/html/bug-hurd/2005-01/msg00025.html)
 
 The thread starts at Jan 4th 2005 until Jan 6th and is only retaken at April 14th in [this thread](http://lists.gnu.org/archive/html/bug-hurd/2005-01/msg00025.html).
 
--- [[Main/ThadeuCascardo]] - 29 Sep 2005
-
-No DHCP client has been ported to the Hurd yet.
-
 [This](http://mail.gnu.org/archive/html/help-hurd/2003-10/msg00016.html) thread on help-hurd has a little more info on what's still needed for DHCP.
 
--- [[Main/GregBuchholz]] - 09 Oct 2003
-
 Found this [message](http://mail.gnu.org/archive/html/bug-hurd/2003-08/msg00045.html) about DHCP capabilities in the Hurd encouraging.
 
--- [[Main/GregBuchholz]] - 03 Sep 2003
-
 * Tom Hart began a [discussion ](http://mail.gnu.org/pipermail/help-hurd/2002-October/006643.html) of 14 posts in Oct 2002.
 
--- [[Main/GrantBow]] - 20 Oct 2002
-
 The beginnings of a DHCP translator is available in the Hurd sources on Savannah: [hurd/trans/pump.c](http://savannah.gnu.org/cgi-bin/viewcvs/hurd/hurd/trans/pump.c?rev=1.3&content-type=text/vnd.viewcvs-markup)
 
 Unfortunately our current TCP/IP stack, the pfinet translator, lacks support for the AF\_PACKET interface as well as sending packets with an IP address of 0.0.0.0.
@@ -38,10 +44,3 @@ Neal Walfield on bug-hurd replies:
     > Anyone else know the status of getting these compiled and functional?
 
     We need to be able to send to the DHCP server with ip address 0.0.0.0.
-
--- [[Main/JoachimNilsson]] - 12 Nov 2002
-
----
-
-[[Debian GNU/Hurd|running/debian]] has some script hackery to get
-[[running/debian/DHCP]] going.
diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn
index b66af7de..135b4a88 100644
--- a/hurd/translator/procfs/jkoenig/discussion.mdwn
+++ b/hurd/translator/procfs/jkoenig/discussion.mdwn
@@ -166,3 +166,50 @@ IRC, freenode, #hurd, 2011-03-28
       mentoring the previous procfs implementation
     <antrik> (though I never got around to look at his buggy code...)
     <jkoenig> ok
+
+IRC, freenode, #hurd, 2011-07-22
+
+    <pinotree> hm, why /proc/$pid/stat is 600 instead of 644 of linux?
+    <jkoenig> pinotree, it reveals information which, while not that sensitive,
+      would not be available to users through the normal proc interface.
+    <jkoenig> (it's available through the ps command which is setuid root)
+    <jkoenig> we discussed at some point making it 644, IIRC.
+    <pinotree> hm, then why is it not a problem on eg linux?
+    <jkoenig> (btw you can change it with the -s option.)
+    <jkoenig> pinotree, it's not a problem because the information is not that
+      sensitive, but when rewriting procfs I preferred to play it self and
+      consider it's not procfs' job to decide what is sensitive or not.
+    <jkoenig> IIRC it's not sensitive but you need the task port to query it.
+    <jkoenig> like, thread times or something.
+    <pinotree> status is 644 though
+    <jkoenig> but status contains information which anyone can ask to the proc
+      server anyway, I think.
+
+
+# `/proc/mounts`, `/proc/$pid/mounts`
+
+IRC, freenode, #hurd, 2011-07-25
+
+    < pinotree> jkoenig: btw, what do you think about providing empty
+      /proc/mounts and /proc/$pid/mounts files?
+    < jkoenig> pinotree, I guess one would have to evaluate the consequences
+      wrt. existing use cases (in other words, "I have absolutely no clue
+      whatsoever about whether that would be desirable" :-)
+    < jkoenig> pinotree, the thing is, an error message like "/proc/mounts: No
+      such file or directory" is rather explicit, whereas errors which would be
+      caused by missing data in /proc/mounts would maybe be harder to track
+    < braunr> this seems reasonable though
+    < braunr> there already are many servers with e.g. grsecurity or chrooted
+      environments where mounts is empty
+    < pinotree> well, currently we also have an empty mtab
+    < braunr> pinotree: but what do you need that for ?
+    < braunr> pinotree: the init system ?
+    < pinotree> and the mnt C api already returns no entries (or it bails out,
+      i don't remember)
+    < pinotree> not a strict need
+
+
+# `/proc/[PID]/auxv`, `/proc/[PID]/exe`, `/proc/[PID]/mem`
+
+Needed by glibc's `pldd` tool (commit
+11988f8f9656042c3dfd9002ac85dff33173b9bd).
diff --git a/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn b/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn
index f0eb473c..ecebe662 100644
--- a/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn
+++ b/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn
@@ -8,9 +8,10 @@ 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]]
+[[!tag open_issue_gnumach open_issue_hurd]]
 
-\#hurd, freenode, 2010
+
+# IRC, freenode, #hurd, 2010
 
     <slpz> humm... why does tmpfs try to use the default pager? that's a bad
       idea, and probably will never work correctly...
@@ -120,3 +121,113 @@ License|/fdl]]."]]"""]]
       memory, gives them a reference to the default pager by calling
       vm_object_pager_create
     <slpz> this is not really important, but worth noting ;-)
+
+
+# IRC, freenode, #hurd, 2011-09-28
+
+    <slpz> mcsim: "Fix tmpfs" task should be called "Fix default pager" :-)
+    <slpz> mcsim: I've been thinking about modifying tmpfs to actually have
+      it's own storeio based backend, even if a tmpfs with storage sounds a bit
+      stupid.
+    <slpz> mcsim: but I don't like the idea of having translators messing up
+      with the default pager...
+    <antrik> slpz: messing up?...
+    <slpz> antrik: in the sense of creating a number of arbitrarily sized
+      objects
+    <antrik> slpz: well, it doesn't really matter much whether a process
+      indirectly eats up arbitrary amounts of swap through tmpfs, or directly
+      through vm_allocate()...
+    <antrik> though admittedly it's harder to implement resource limits with
+      tmpfs
+    <slpz> antrik: but I've talked about having its own storeio device as
+      backend. This way Mach can pageout memory to tmpfs if it's needed.
+    <mcsim> Do I understand correctly that the goal of tmpfs task is to create
+      tmpfs in RAM?
+    <slpz> mcsim: It is. But it also needs some kind of backend, just in case
+      it's ordered to page out data to free some system's memory.
+    <slpz> mcsim: Nowadays, this backend is another translator that acts as
+      default pager for the whole system
+    <antrik> slpz: pageout memory to tmpfs? not sure what you mean
+    <slpz> antrik: I mean tmpfs acting as its own pager
+    <antrik> slpz: you mean tmpfs not using the swap partition, but some other
+      backing store?
+    <slpz> antrik: Yes.
+
+See also: [[open_issues/resource_management_problems/pagers]].
+
+    <antrik> slpz: I don't think an extra backing store for tmpfs is a good
+      idea. the whole point of tmpfs is not having a backing store... TBH, I'd
+      even like to see a single backing store for anonymous memory and named
+      files
+    <slpz> antrik: But you need a backing store, even if it's the default pager
+      :-)
+    <slpz> antrik: The question is, Should users share the same backing store
+      (swap space) or provide their own?
+    <antrik> slpz: not sure what you mean by "users" in this context :-)
+    <slpz> antrik: Real users with the ability of setting tmpfs translators
+    <antrik> essentially, I'd like to have a single partition that contains
+      both swap space and the main filesystem (at least /tmp, but probably also
+      all of /run, and possibly even /home...)
+    <antrik> but that's a bit off-topic :-)
+    <antrik> well, ideally all storage should be accounted to a user,
+      regardless whether it's swapped out anonymous storage, temporary named
+      files, or permanent files
+    <slpz> antrik: you could use a file as backend for tmpfs
+    <antrik> slpz: what's the point of using tmpfs then? :-)
+    <pinotree> (and then store the file in another tmpfs)
+    <slpz> antrik: mach-defpager could be modified to use storeio instead of
+      Mach's device_* operations, but by the way things work right now, that
+      could be dangerous, IMHO
+    <antrik> pinotree: hehe
+    <pinotree> .. recursive tmpfs'es ;)
+    <antrik> slpz: hm, sounds interesting
+    <slpz> antrik: tmpfs would try to keep data in memory always it's possible
+      (not calling m_o_lock_request would do the trick), but if memory is
+      scarce an Mach starts paging out, it would write it to that
+      file/device/whatever
+    <antrik> ideally, all storage used by system tasks for swapped out
+      anonymous memory as well as temporary named files would end up on the
+      /run partition; while all storage used by users would end up in /home/*
+    <antrik> if users share a partition, some explicit storage accounting would
+      be useful too...
+    <antrik> slpz: is that any different from what "normal" filesystems do?...
+    <antrik> (and *should* it be different?...)
+    <slpz> antrik: Yes, as most FS try to synchronize to disk at a reasonable
+      rate, to prevent data losses.
+    <slpz> antrik: tmpfs would be a FS that wouldn't synchronize until it's
+      forced to do that (which, by the way, it's what's currently happening
+      with everyone that uses the default pager).
+    <antrik> slpz: hm, good point...
+    <slpz> antrik: Also, metadata in never written to disk, only kept in memory
+      (which saves a lot of I/O, too).
+    <slpz> antrik: In fact, we would be doing the same as every other kernel
+      does, but doing it explicitly :-)
+    <antrik> I see the use in separating precious data (in permanent named
+      files) from temporary state (anonymous memory and temporary named files)
+      -- but I'm not sure whether having a completely separate FS for the
+      temporary data is the right approach for that...
+    <slpz> antrik: And giving the user the option to specify its own storage,
+      so we don't limit him to the size established for swap by the super-user.
+    <antrik> either way, that would be a rather radical change... still would
+      be good to fix tmpfs as it is first if possible
+    <antrik> as for limited swap, that's precisely why I'd prefer not to have
+      an extra swap partition at all...
+    <slpz> antrik: It's not much o fa change, it's how it works right now, with
+      the exception of replacing the default pager with its own.
+    <slpz> antrik: I think it's just a matter of 10-20 hours, as
+      much. Including testing.
+    <slpz> antrik: It could be forked with another name, though :-)
+    <antrik> slpz: I don't mean radical change in the implementation... but a
+      radical change in the way it would be used
+    <slpz> antrik: I suggest "almosttmpfs" as the name for the forked one :-P
+    <antrik> hehe
+    <antrik> how about lazyfs?
+    <slpz> antrik: That sound good to me, but probably we should use a more
+      descriptive name :-)
+
+
+## 2011-09-29
+
+    <tschwinge> slpz, antrik: There is a defpager in the Hurd code.  It is not
+      currently being used, and likely incomplete.  It is backed by libstore.
+      I have never looked at it.