Merge branch 'master' of flubber:~hurd-web/hurd-web

5 files changed, 186 insertions, 9 deletions

diff --git a/microkernel/mach/gnumach/debugging.mdwn b/microkernel/mach/gnumach/debugging.mdwn
index 3a93c6ad..2f52adf8 100644
--- a/microkernel/mach/gnumach/debugging.mdwn
+++ b/microkernel/mach/gnumach/debugging.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]]."]]"""]]
 
 Mach has a built-in kernel debugger.
 [Manual](http://www.gnu.org/software/hurd/gnumach-doc/Kernel-Debugger.html).
@@ -67,3 +67,12 @@ The call of `halt_cpu` will -- as the name suggests -- halt the system
 afterwards.  This might be what you want or it might not, but it is needed at
 some place when running the kernel inside QEMU, as QEMU somehow decides not to
 update its display buffer anymore under certain conditions.
+
+
+IRC, freenode, #hurd, 2011-07-14:
+
+    <braunr> one ugly trick i use when printf isn't available is to halt the
+      cpu
+    <braunr> then use info registers to know where the cpu is halted
+    <braunr> and you'll know if you reached that code or not
+    <braunr> (info registers is a qemu command)
diff --git a/microkernel/mach/gnumach/memory_management.mdwn b/microkernel/mach/gnumach/memory_management.mdwn
index 17c7ad79..43b99d83 100644
--- a/microkernel/mach/gnumach/memory_management.mdwn
+++ b/microkernel/mach/gnumach/memory_management.mdwn
@@ -50,3 +50,33 @@ IRC, freenode, #hurd, 2011-02-16
     <braunr> antrik: but you're right, since mach uses a direct mapped kernel
       space, the true problem is the lack of linux-like highmem support
     <braunr> which isn't required if the kernel space is really virtual
+
+
+---
+
+IRC, freenode, #hurd, 2011-06-09
+
+    <braunr> btw, how can gnumach use 1 GiB of RAM ? did you lower the
+      user/kernel boundary address ?
+    <youpi> I did
+    <braunr> 2G ?
+    <youpi> yes
+    <braunr> ok
+    <youpi> it doesn't make so much sense to let processes have 3G addressing
+      space when there can't be more that 1G physical memory
+    <braunr> that's sad for an operating system which does most things by
+      mapping memory eh
+    <youpi> well, if a process wants to map crazy things, 3G may be tight
+      already
+    <youpi> e.g. ext2fs
+    <braunr> yes
+    <youpi> so there's little point in supporting them
+    <braunr> we need hurd/amd64
+    <youpi> and there's quite some benefit in shrinking them to 2G
+    <youpi> yes
+    <youpi> actually even 2G may become a bit tight
+    <youpi> webkit linking needs about 1.5-2GiB
+    <youpi> things become really crazy
+    <braunr> wow
+    <braunr> i remember the linux support for 4G/4G split when there was enough
+      RAM to fill the kernel space with struct page entries
diff --git a/microkernel/mach/gnumach/ports/xen.mdwn b/microkernel/mach/gnumach/ports/xen.mdwn
index bf26410a..af431c92 100644
--- a/microkernel/mach/gnumach/ports/xen.mdwn
+++ b/microkernel/mach/gnumach/ports/xen.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,11 +6,12 @@ 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]]."]]"""]]
 
 [[!toc]]
 
+
 # Xen dom0, hypervisor
 
 /!\ Now that GNU Mach handles PAE you can use a PAE-enabled hypervisor.
@@ -30,6 +31,7 @@ If you have a free partition, you can fdisk to type 0x83, create a filesystem us
 
 Replace /dev/sda4 with your partition. Install and use crosshurd to setup a GNU/Hurd system on this partition.
 
+
 # /etc/xen/hurd configuration
 
 Here is a sample /etc/xen/hurd configuration
@@ -49,6 +51,7 @@ Suggestions about [[networking_configuration]] are available.
 If you need stable MAC addresses, use a syntax like `vif = [
 'mac=00:16:3e:XX:XX:XX, bridge=br0' ]`.
 
+
 # Running Hurd with Xen
 
 To run Hurd with Xen, use:
@@ -63,6 +66,7 @@ and gnumach should get started. Proceed with native-install.
 - If `xm` complains about networking (`vif could not be connected`), it's Xen scripts' fault, see Xen documentation for how to configure the network.  The simplest way is network-bridge with fixed IPs (note that you need the bridge-utils package for this).  You can also just disable networking by commenting the vif line in the config.
 - If `xm` complains `Error: (2, 'Invalid kernel', 'xc_dom_compat_check: guest type xen-3.0-x86_32 not supported by xen kernel, sorry\n')`, you most probably have a PAE-enabled hypervisor and a non-PAE gnumach. Either install and boot non-PAE hypervisor and kernel, or rebuilt gnumach in PAE mode.
 
+
 # Building from sources
 
 If you want to generate these images, first get the `gnumach-1-branch-Xen-branch` branch from gnumach CVS.
@@ -75,7 +79,6 @@ Then use
 The current `hurd-modules` was built from the debian packages `hurd 20070606-2` and `libc0.3 2.6.1-1`.
 /!\ This means that when using this image, your GNU/Hurd system also needs to be a glibc version 2.6 or later-based one!
 
----
 
 # Miscellaneous
 
@@ -83,7 +86,6 @@ The current `hurd-modules` was built from the debian packages `hurd 20070606-2`
 
 [[!GNU_Savannah_task 5468]], [[!GNU_Savannah_task 6584]].
 
----
 
 # `pv-grub`
 
@@ -91,3 +93,15 @@ From Xen 4.0 on you'll be able to run the GNU Hurd directly using `pv-grub`,
 without the need to [prepare a special bootstrap
 image](http://youpibouh.thefreecat.org/hurd-xen/build_hurd-modules) (like an
 initrd).
+
+
+# Host-side Writeback Caching
+
+Optimization possible as it is with [[QEMU|hurd/running/qemu/discussion]],
+*Host-side Writeback Caching*?
+
+IRC, freenode, #hurd, 2011-06-08
+
+    <braunr> youpi: does xen provide disk caching options ?
+    <youpi> through a blktap, probably
+    <braunr> ok
diff --git a/microkernel/mach/rpc.mdwn b/microkernel/mach/rpc.mdwn
index 60275a86..422e0441 100644
--- a/microkernel/mach/rpc.mdwn
+++ b/microkernel/mach/rpc.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2002, 2003, 2007, 2008, 2010 Free Software
+[[!meta copyright="Copyright © 2002, 2003, 2007, 2008, 2010, 2011 Free Software
 Foundation, Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -19,3 +19,10 @@ implementation in the kernel possible, too, which is called *NORMA*, but is not
 avilable in [[GNU Mach|gnumach]].
 
 The RPC stub code generated by [[MIG]].
+
+
+# Tracing
+
+  * [[hurd/debugging/rpctrace]]
+
+  * [[open_issues/librpci]]
diff --git a/microkernel/mach/rpc/discussion.mdwn b/microkernel/mach/rpc/discussion.mdwn
new file mode 100644
index 00000000..00e4a012
--- /dev/null
+++ b/microkernel/mach/rpc/discussion.mdwn
@@ -0,0 +1,117 @@
+[[!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]]
+
+
+# IRC, freenode, #hurd, 2011-06-11
+
+    <antrik> I don't think we have a precendence case of Mach initiating RPCs
+      to userspace tasks
+    <braunr> well mach regularly sends RPCs to external pagers
+    <antrik> hm, right
+    <antrik> anyways, the ds_ in device.defs is for use *inside* Mach, not for
+      the userspace interface
+    <braunr> what makes you think so ?
+    <antrik> several things
+    <antrik> not least the fact that without zhengda's modifications, the
+      device handling never calls out to userspace for all I know
+    <braunr> hm, it does
+    <braunr> for async I/O
+    <braunr> when the kernel has finished its I/O, it calls
+      ds_device_read_reply/ds_device_write_reply
+    <antrik> I see
+    <antrik> I never quite understood the _reply stuff
+    <braunr> although i wonder how mig is supposed to forge those names
+    <antrik> braunr: it isn't
+    <antrik> braunr: there is a separate device_reply.defs
+    <antrik> braunr: and it sets a *userprefix* of ds_
+    <antrik> rather than a serverprefix
+    <braunr> i saw, yes
+    <braunr> ah right
+    <antrik> so ds still refers to the in-Mach device server, not anything
+      userspace
+    <braunr> so this is where the patch is supposed to introduce the
+      device_intr_notify RPC
+    <antrik> or at least that's my understanding...
+    <braunr> no, it doesn't refer to in-mach servers
+    <braunr> it really forges the right rpcs to be called by mach
+    <antrik> the definition of "RPC" is rather unclear here
+    <braunr> why ?
+    <braunr> mach has its own mach_msg() call for kernel-to-user messaging
+    <antrik> yes, but this is used only to send the reply message for the RPC
+      earlier initiated by userspace AIUI
+    <antrik> it doesn't look like there is any special RPC for async I/O
+    <braunr> yes, because this is the only use case they had
+    <braunr> hence the name "reply"
+    <braunr> intr_notify isn't a reply, but it uses the same mechanism
+    <braunr> these are declared as simpleroutine
+    <antrik> sure. but the fact that it isn't a reply message, but rather
+      initiates a new RPC, changes things from MiG point of view I believe
+    <antrik> right, as there is no reply to the reply :-)
+    <braunr> :)
+    <braunr> a simpleroutine is how to turn an rpc into a simple ipc
+    <antrik> I know
+    <antrik> so in _reply, we pretend that the reply is actually a new RPC,
+      with server and client roles reversed, and no reply
+    <antrik> (this is actually rather kludgy... apparently MIG has no real
+      notion of async replies)
+    <braunr> i don't understand what you mean
+    <braunr> simpleroutine is the explicit solution for async replies
+    <braunr> as stated in
+      http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/mig.ps
+    <braunr> it's not a new rpc with roles reversed
+    <braunr> it's not a reply either
+    <antrik> it might be an explicit solution for that, but it still seems
+      kludgy :-)
+    <braunr> i don't see why :/
+    <braunr> would you have expected something like an option to create both
+      sync and async versions ?
+    <antrik> because it requires an extra .defs file
+    <antrik> yes
+    <braunr> ok
+    <braunr> well this seems cumbersome to me :)
+    <braunr> i prefer the simpleroutine approach
+    <braunr> but i agree this seems odd since mach has a high level ipc api
+    <antrik> anyways, my point is that the ds_ in device_reply.defs still
+      refers to the Mach side of things
+    <braunr> npnth: which package fails to build ?
+    <antrik> though a userspace process that actually handles the replies in an
+      async fashion will of course need some kind of device server too, just
+      like the DDE stuff...
+    <antrik> though naming it ds_ is confusing IMHO, because of the name clash
+      with the device server in Mach
+    <braunr> hm again, i fail to see why
+    <braunr> ds_ just means device_server
+    <braunr> and as most things in mach, it can be in kernel or not
+    <braunr> i mean, this is an interface prefix, i don't refer to an actual
+      single instance of a "device server" out there
+    <antrik> oh, right... DDE implements the Mach device protocol, so it *does*
+      do the ds_ part... but that makes the interrupt notification stuff even
+      more confusing
+    <braunr> hm
+    <braunr> because it provides a ds_device_intr_notify() which will never be
+      used, just to completely implement the interface ?
+    <antrik> yeah, that's what I suspect...
+    <braunr> sounds likely
+    <antrik> the device interface actually has two parts: one for "generic"
+      RPCs on the master device port, and one for device-specific RPCs. DDE
+      implements the latter, and uses the former...
+    <antrik> they live in separate places though I think: the individual device
+      RPCs are implemented in libmachdev, while the intr_ stuff is used in
+      libddekit probably
+    <braunr> it would be hairy to build otherwise
+    <antrik> so we *really* need to know what component npnth gets the error
+      with
+    <antrik> braunr: nah, not really. that's why we always have a separate
+      prefix for the server routines in Hurd RPCs
+    <braunr> right, i really need to read about mig again
+    <antrik> it's pretty normal for a translator to both implement and use an
+      interface