IRC.

6 files changed, 209 insertions, 2 deletions

diff --git a/microkernel/mach/deficiencies.mdwn b/microkernel/mach/deficiencies.mdwn
index 9ba67219..b3e1758c 100644
--- a/microkernel/mach/deficiencies.mdwn
+++ b/microkernel/mach/deficiencies.mdwn
@@ -528,3 +528,90 @@ In context of [[open_issues/multithreading]] and later [[open_issues/select]].
       physical maps (cpu-specific page tables) for user tasks, and stack
       tracing (in addition to symbol resolution when symbols are available)
       were recently added
+
+
+### IRC, freenode, #hurd, 2013-01-15
+
+    <braunr> Anarchos: as a side note, i'm currently working on a hurd clone
+      with a microkernel that takes a lot from mach but also completely changes
+      the ipc interface (making it not mach at all in the end)
+    <braunr> it's something between mach and qnx neutrino
+    <zacts> braunr: do you have a git repo of your new clone?
+    <braunr> http://git.sceen.net/rbraun/x15.git/
+    <zacts> neat
+    <braunr> it's far from complete
+    <braunr> and hasn't reached a status where it can be publically announced
+    <zacts> ok
+    <braunr> but progress has been constant so far, the ideas i'm using have
+      proven applicable on other systems, i don't expect the kind of design
+      issues that blocked HurdNG
+    <braunr> (also, my attempt doesn't aim at the same goals as hurdng did)
+    <braunr> (e.g. denial of service remains completely possible)
+    <zacts> so x15 will use the current hurd translators? you are only
+      replacing gnumach?
+    <braunr> that was the plan some years ago, but now that i know the hurd
+      better, i think the main issues are in the hurd, so there isn't much
+      point rewriting mach
+    <braunr> so, if the hurd needs a revamp, it's better to also make the
+      underlying interface better if possible
+    <braunr> zacts: in other words: it's a completely different beast
+    <zacts> ok
+    <braunr> the main goal is to create a hurd-like system that overcomes the
+      current major defficiencies, most of them being caused by old design
+      decisions
+    <zacts> like async ipc?
+    <braunr> yes
+    <Anarchos> time for a persistent hurd ? :)
+    <braunr> no way
+    <braunr> i don't see a point to persistence for a general purpose system
+    <braunr> and it easily kills performance
+    <braunr> on the other hand, it would be nice to have a truely scalable,
+      performant, and free microkernel based system
+    <braunr> (and posix compatible)
+    <braunr> there is currently none
+    <braunr> zacts: the projects focuses mostly on performance and scalability,
+      while also being very easy to understand and maintain (something i think
+      the current hurd has failed at :/)
+    <braunr> project*
+    <zacts> very cool
+    <braunr> i think so, but we'll have to wait for an end result :)
+    <braunr> what's currently blocking me is the IDL
+    <braunr> earlier research has shown that an idl must be optmized the same
+      way compilers are for the best performances
+    <braunr> i'm not sure i can write something good enough :/
+    <braunr> the first version will probably be very similar to mig, small and
+      unoptimized
+
+
+### IRC, freenode, #hurd, 2013-01-18
+
+    <zacts> braunr: so how exactly do the goals of x15 differ from viengoos?
+    <braunr> zacts: viengoos is much more ambitious about the design
+    <braunr> tbh, i still don't clearly see how its half-sync ipc work
+    <braunr> x15 is much more mach-like, e.g. a hybrid microkernel with
+      scheduling and virtual memory in the kernel
+    <braunr> its goals are close to those of mach, adding increased scalability
+      and performance to the list
+    <zacts> that's neat
+    <braunr> that's different
+    <braunr> in a way, you could consider x15 is to mach what linux is to unix,
+      a clone with a "slightly" different interface
+    <zacts> ah, ok. cool!
+    <braunr> viengoos is rather a research project, with very interesting
+      goals, i think they're both neat :p
+
+
+### IRC, freenode, #hurd, 2013-01-19
+
+    <braunr> for now, it provides kernel memory allocation and basic threading
+    <braunr> it already supports both i386 and amd64 processors (from i586
+      onwards), and basic smp
+    <zacts> oh wow
+    <zacts> how easily can it be ported to other archs?
+    <braunr> the current focus is smp load balancing, so that thread migration
+      is enabled during development
+    <braunr> hard to say
+    <braunr> everything that is arch-specific is cleanly separated, the same
+      way it is in mach and netbsd
+    <braunr> but the arch-specific interfaces aren't well defined yet because
+      there is only one (and incomplete) arch
diff --git a/microkernel/mach/gnumach/interface.mdwn b/microkernel/mach/gnumach/interface.mdwn
new file mode 100644
index 00000000..b2451887
--- /dev/null
+++ b/microkernel/mach/gnumach/interface.mdwn
@@ -0,0 +1,16 @@
+[[!meta copyright="Copyright © 2013 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]]."]]"""]]
+
+[[!meta title="Interfaces"]]
+
+/!\ Incomplete.
+
+[[!map pages="microkernel/mach/gnumach/interface/*"
+show=title]]
diff --git a/microkernel/mach/gnumach/interface/syscall.mdwn b/microkernel/mach/gnumach/interface/syscall.mdwn
new file mode 100644
index 00000000..d5fc542b
--- /dev/null
+++ b/microkernel/mach/gnumach/interface/syscall.mdwn
@@ -0,0 +1,16 @@
+[[!meta copyright="Copyright © 2013 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]]."]]"""]]
+
+[[!meta title="System Calls"]]
+
+/!\ Incomplete.
+
+[[!map pages="microkernel/mach/gnumach/interface/syscall/* and !microkernel/mach/gnumach/interface/syscall/*/*"
+show=title]]
diff --git a/microkernel/mach/gnumach/interface/syscall/mach_print.mdwn b/microkernel/mach/gnumach/interface/syscall/mach_print.mdwn
new file mode 100644
index 00000000..c0b0d0b3
--- /dev/null
+++ b/microkernel/mach/gnumach/interface/syscall/mach_print.mdwn
@@ -0,0 +1,53 @@
+[[!meta copyright="Copyright © 2013 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]]."]]"""]]
+
+
+# IRC, freenode, #hurd, 2013-01-18
+
+    <braunr> youpi: what would you think of adding a debug-related syscall to
+      gnumach so that we have a printf-like tool even in situations where the
+      code can't perform an rpc (i.e. glibc)
+    <youpi> could be useful indeed
+    <youpi> I've found myself having a hard time making some printfs from odd
+      places of glibc :)
+    <braunr> i also suggest we make it unprivileged
+    <youpi> not enabled by default then
+    <youpi> otherwise it's an easy DoS
+    <braunr> well, for now, we don't care much about DoS, but we do care about
+      debugging
+    <braunr> at least until the very core issues we have are understood and
+      resolved
+    <youpi> I usually frown on debugging feature being too open
+    <braunr> me too
+    <youpi> you would always forget dropping one
+    <braunr> that's why i didn't suggest it earlier
+    <braunr> but i'm wasting too much time finding other decently effective
+      ways
+
+
+## IRC, freenode, #hurd, 2013-01-19
+
+    <braunr> youpi: how about we build this debugging system call in debugging
+      versions only ?
+    <braunr> i suppose you already use such versions for buildds anyway
+    <braunr> MACH_DEBUG is always enabled
+    <braunr> the debugging version only adds --enable-kdb if i'm right
+    <pinotree> check debian/rules
+    <braunr> that, and -fno-omit-frame-pointer
+
+
+## IRC, freenode, #hurd, 2013-01-21
+
+    <braunr> youpi: concerning gnumach, i've added a mach_print system call,
+      with one argument (a null terminated string) to -dbg kernels
+      (--enable-kbd)
+    <youpi> k
+    <braunr> if it's fine with you, i'll commit it too
+    <youpi> I'm fine
diff --git a/microkernel/mach/gnumach/memory_management.mdwn b/microkernel/mach/gnumach/memory_management.mdwn
index a1d9a99d..4e237269 100644
--- a/microkernel/mach/gnumach/memory_management.mdwn
+++ b/microkernel/mach/gnumach/memory_management.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2012, 2013 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
@@ -177,3 +178,13 @@ License|/fdl]]."]]"""]]
     <braunr> again, i was just wondering out loud
     <youpi> braunr: well, bach & mozart don't have > 1.2GiB mem anyway
     <youpi> so it doesn't pose problem
+
+
+# IRC, freenode, #hurd, 2013-01-12
+
+    <sobhan> can hurd have more than 1GB of ram ?
+    <braunr> sobhan: not with the stock kernel, but yes with a simple patch
+    <braunr> sobhan: although you should be aware of the implications of this
+      patch
+    <braunr> (more kernel memory, thus more physical memory - up to 1.8 GiB -
+      but then, less user memory)
diff --git a/microkernel/mach/message/msgh_id.mdwn b/microkernel/mach/message/msgh_id.mdwn
index a7157a37..ea52904a 100644
--- a/microkernel/mach/message/msgh_id.mdwn
+++ b/microkernel/mach/message/msgh_id.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2012, 2013 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
@@ -257,3 +257,27 @@ files.
 ## IRC, freenode, #hurd, 2012-09-30
 
     <braunr> youpi: hey, didn't see you merged the page cache stats branch :)
+
+
+## IRC, freenode, #hurd, 2013-01-12
+
+    <braunr> youpi: the hurd master-vm_cache_stats branch (which makes vmstat
+      displays some vm cache properties) is ready to be pulled
+
+[[open_issues/mach_tasks_memory_usage]].
+
+    <braunr> tschwinge: i've updated the procfs server on darnassus, you can
+      now see the amount of physical memory used by the vm cache with top/htop
+      (not vmstat yet)
+
+
+### IRC, freenode, #hurd, 2013-01-13
+
+    <youpi> braunr: I'm not sure to understand what I'm supposed to do with the
+      page cache statistics branch
+    <braunr> youpi: apply it ?
+    <youpi> can't you already do that?
+    <braunr> well, i don't consider myself a maintainer
+    <youpi> then submit to the list for review
+    <braunr> hm ok
+    <braunr> youpi: ok, next time, i'll commit such changes directly