Move a bunch of IRC discussion logs to discussion subpages.

5 files changed, 168 insertions, 73 deletions

diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn
index 141ab2b1..73ef0479 100644
--- a/hurd/running/qemu.mdwn
+++ b/hurd/running/qemu.mdwn
@@ -1,3 +1,14 @@
+[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2009, 2010, 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]]."]]"""]]
+
 This page discusses things for [[Unix]] systems, there is a separate page for
 [[Microsoft_Windows]] systems.
 
@@ -184,31 +195,3 @@ system after installation.
 [[Image_for_L4]] -- a QEMU image for the Hurd/L4 project.
 
 <http://eyeside.net/hurd/Hurd-on-QEMU.html>
-
-
-# TODO
-
-[[IRC]], #hurd, 2007-07-04.
-
-    <azeem-uni> so, is there a way to use a Debian GNU/Hurd partition (/dev/hda6) with qemu directly?
-    <tschwinge> Don't dare to do that, please.
-    <tschwinge> It will lead to inconsistencies.
-    <tschwinge> Because the Linux kernel thinks that it has complete control over the disk, or something.
-    <tschwinge> In theory you could run something like ``-hda /dev/hda'', having GRUB installed on there to offer you to boot your Hurd system from hda6 and that will even work, but then don't get the idea to stop qemu, mount that partition on your Linux system and restart qemu.  That's where I got lots of inconsistencies then, afterwards.
-    <azeem-uni> it's probably the same problem as having that partition mounted, suspending to disk, booting into it in the Hurd, and resume Linux
-    <neal> right
-    <tschwinge> That's a different problem.
-    <tschwinge> Then the partitoon is still mounted.
-    <neal> no, I think it is basically the same problem
-    <tschwinge> The file system stuff is cached in the kernel.
-    <neal> you have data that has not been written to disk yet
-    <tschwinge> Right.
-    <neal> and neither is prepared for the resource to be shared
-    <tschwinge> In the azeem-uni scenarion the data is on the file system layer and in my scenarion it's some disk block caching inside the Linux kernel, I guess.
-    <azeem-uni> anyway, do you guys think if I use -hda /dev/hda and tell Grub to boot off /dev/hda6, that the rest of hda should be fine, right?
-    <azeem-uni> maybe adding -snapshot makes it totally safe
-    <neal> azeem: Should be fine.
-    <tschwinge> Yes.
-
-The problem is actually that the linux block cache doesn't make any consistency between /dev/hda and /dev/hda6, so if you give /dev/hda to qemu, qemu writings won't be consistent with mounting /dev/hda6 in linux. You can give /dev/hda6 directly to qemu and it will be fine.
-
diff --git a/hurd/running/qemu/discussion.mdwn b/hurd/running/qemu/discussion.mdwn
new file mode 100644
index 00000000..fd0df4c5
--- /dev/null
+++ b/hurd/running/qemu/discussion.mdwn
@@ -0,0 +1,52 @@
+[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2009, 2010, 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]]
+
+# Using Partitions
+
+[[IRC]], #hurd, 2007-07-04.
+
+    <azeem-uni> so, is there a way to use a Debian GNU/Hurd partition
+      (/dev/hda6) with qemu directly?
+    <tschwinge> Don't dare to do that, please.
+    <tschwinge> It will lead to inconsistencies.
+    <tschwinge> Because the Linux kernel thinks that it has complete control
+      over the disk, or something.
+    <tschwinge> In theory you could run something like ``-hda /dev/hda'',
+      having GRUB installed on there to offer you to boot your Hurd system from
+      hda6 and that will even work, but then don't get the idea to stop qemu,
+      mount that partition on your Linux system and restart qemu.  That's where
+      I got lots of inconsistencies then, afterwards.
+    <azeem-uni> it's probably the same problem as having that partition
+      mounted, suspending to disk, booting into it in the Hurd, and resume
+      Linux
+    <neal> right
+    <tschwinge> That's a different problem.
+    <tschwinge> Then the partitoon is still mounted.
+    <neal> no, I think it is basically the same problem
+    <tschwinge> The file system stuff is cached in the kernel.
+    <neal> you have data that has not been written to disk yet
+    <tschwinge> Right.
+    <neal> and neither is prepared for the resource to be shared
+    <tschwinge> In the azeem-uni scenarion the data is on the file system layer
+      and in my scenarion it's some disk block caching inside the Linux kernel,
+      I guess.
+    <azeem-uni> anyway, do you guys think if I use -hda /dev/hda and tell Grub
+      to boot off /dev/hda6, that the rest of hda should be fine, right?
+    <azeem-uni> maybe adding -snapshot makes it totally safe
+    <neal> azeem: Should be fine.
+    <tschwinge> Yes.
+
+The problem is actually that the linux block cache doesn't make any consistency
+between /dev/hda and /dev/hda6, so if you give /dev/hda to qemu, qemu writings
+won't be consistent with mounting /dev/hda6 in linux. You can give /dev/hda6
+directly to qemu and it will be fine.
diff --git a/hurd/translator/tmpfs.mdwn b/hurd/translator/tmpfs.mdwn
index 0179ad6c..d1476a92 100644
--- a/hurd/translator/tmpfs.mdwn
+++ b/hurd/translator/tmpfs.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation,
+[[!meta copyright="Copyright © 2007, 2008, 2009, 2011 Free Software Foundation,
 Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -6,8 +6,8 @@ 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]]."]]"""]]
 
 `tmpfs` is a file system server for temporary data storage without using a real
 (permanent) [[backing_store]].
@@ -21,9 +21,3 @@ with the additional block-level indirection layer that `ext2` (or any other
 disk-based file system) imposes.
 
 However, `tmpfs` is not working correctly at the moment:
-
-[[!inline
-pages="hurd/translator/tmpfs/*"
-show=0
-feeds=no
-actions=yes]]
diff --git a/hurd/translator/tmpfs/discussion.mdwn b/hurd/translator/tmpfs/discussion.mdwn
new file mode 100644
index 00000000..d7a08491
--- /dev/null
+++ b/hurd/translator/tmpfs/discussion.mdwn
@@ -0,0 +1,17 @@
+[[!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_hurd]]
+
+  * [[notes_bing]]
+
+  * [[notes_various]]
+
+  * [[tmpfs_vs_defpager]]
diff --git a/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn b/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn
index ef041a23..f0eb473c 100644
--- a/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn
+++ b/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2010, 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
@@ -8,9 +8,12 @@ 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, 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> 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
@@ -21,53 +24,99 @@ License|/fdl]]."]]"""]]
     <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> 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: 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> 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
+    <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
+    <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.
+    <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
+    <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")
+    <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> 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> 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: 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> 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> 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> 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 ;-)