IRC.

10 files changed, 194 insertions, 126 deletions

diff --git a/microkernel/discussion.mdwn b/microkernel/discussion.mdwn
index a5a73e18..f5626f6c 100644
--- a/microkernel/discussion.mdwn
+++ b/microkernel/discussion.mdwn
@@ -10,7 +10,7 @@ License|/fdl]]."]]"""]]
 
 [[!tag open_issue_documentation]]
 
-IRC, freenode, #hurd, 2011-07-26:
+# IRC, freenode, #hurd, 2011-07-26
 
     < antrik> Tekk_`: regarding microkernels: the basic idea, and really the
       *only* fundamental difference, is that they isolate things in separate
@@ -22,3 +22,41 @@ IRC, freenode, #hurd, 2011-07-26:
       these are secondary effects: such choices can also be implemented in a
       monolithic architecture -- and not necessarily harder. just less obvious
       in some cases...
+
+
+# IRC, freenode, #hurd, 2013-08-28
+
+    <Spyro> ok question
+    <Spyro> what is the big advantage of microkernels over monolithic kernels
+      as you guys see it?
+    <Spyro> is it entirely for the benefit of developers or are there actaully
+      practical advantages?
+    <kilobug> Spyro: there are many advantages, at least in theory, in terms of
+      modularity, flexibility, stability, scalability, security, ... which are
+      for everyone
+    <braunr> Spyro: of course some advantages are practical
+    <braunr> for me, the main advantage is system extensibility
+    <braunr> you can replace system services at runtime
+    <braunr> and on the hurd, you can do it as an unprivileged user
+    <braunr> (the direct side effect is far increased security)
+    <braunr> kilobug: i don't see the scalability advantages though
+    <kilobug> braunr: I would say it goes in par with the modularity, like, you
+      can have a full-weight IPv4/IPv6 stack for desktop, but a minimal stack
+      for embeded
+    <braunr> i see
+    <braunr> for me, it's in par with extensibility :)
+    <braunr> i see modularity only as an implementation of extensibility
+    <braunr> or a special case of it
+    <braunr> Spyro: basically, it's supposed to bring the same advantages as
+      fuse, but even more so (because it's not limited to file systems), and
+      better (because it's normally well integrated with the core of the
+      system)
+    <teythoon> also, fuse is kind of bolted on and Linux composes really badly
+    <teythoon> e.g. it is not possible to nfs export a fuse mounted filesystem
+      on Linux
+    <braunr> bolted ?
+    <teythoon> isn't that the term? as in being attached using screws?
+    <braunr> i'm not familiar with it :p
+    <azeem> "a posteriori design"
+    <teythoon> yes
+    <braunr> ok
diff --git a/microkernel/l4.mdwn b/microkernel/l4.mdwn
index de311497..ef39616b 100644
--- a/microkernel/l4.mdwn
+++ b/microkernel/l4.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2004, 2006, 2007, 2008, 2010, 2011, 2012 Free
-Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2004, 2006, 2007, 2008, 2010, 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
@@ -30,6 +30,14 @@ is now stalled.
       Genode and L4: http://www.youtube.com/user/drsartakov?feature=watch
 
 
+# IRC, freenode, #hurd, 2013-08-26
+
+    < Spyro> also
+    < Spyro> what's the basic difference between mach and L4?
+    < braunr> l4 is a nanokernel whereas mach is a hybrid with high level
+      messaging and virtual memory services
+
+
 [[!ymlfront data="""
 
 sel4:
diff --git a/microkernel/mach/concepts.mdwn b/microkernel/mach/concepts.mdwn
index 0f7cbf00..08bce3f5 100644
--- a/microkernel/mach/concepts.mdwn
+++ b/microkernel/mach/concepts.mdwn
@@ -31,3 +31,20 @@ text="*[[mach\_kernel\_principles|documentation]]*:
 In particular the [[!toggle id=mach_kernel_principles
 text="[mach\_kernel\_principles]"]] book further elaborates on Mach's concepts
 and principles.
+
+
+# IRC, freenode, #hurd, 2013-08-26
+
+    < stargater> then is mach not more microkernel 
+    < stargater> when it have driver inside 
+    < braunr> mach is a hybrid
+    < braunr> even without drivers
+    < stargater> in www i read mach is microkernel 
+    < stargater> not hybrid 
+    < braunr> the word microkernel usually includes hybrids
+    < braunr> true microkernels are also called nanokernels
+    < braunr> the word isn't that important, what matters is that mach does
+      more in kernel than what the microkernel principle implies
+    < braunr> e.g. high level async IPC and high level virtual memory
+      operations
+    < braunr> including physical memory management
diff --git a/microkernel/mach/deficiencies.mdwn b/microkernel/mach/deficiencies.mdwn
index 03e4a8b0..8f47f61f 100644
--- a/microkernel/mach/deficiencies.mdwn
+++ b/microkernel/mach/deficiencies.mdwn
@@ -2318,3 +2318,69 @@ In context of [[open_issues/multithreading]] and later [[open_issues/select]].
       about them
     <braunr> even with that, it should be scalable enough for a start
     <braunr> and improving those parts shouldn't be too difficult
+
+
+## IRC, freenode, #hurd, 2013-07-10
+
+    <nlightnfotis> braunr: From what I have understood you aim for x15 to be a
+      production ready μ-kernel for usage in the Hurd? Or is it unrelated to
+      the Hurd?
+    <braunr> nlightnfotis: it's for a hurd clone
+    <nlightnfotis> braunr: I see. Is it close to any of the existing
+      microkernels as far as its design is concerned (L4, Viengoos) or is it
+      new research? 
+    <braunr> it's close to mach
+    <braunr> and qnx
+
+
+## IRC, freenode, #hurd, 2013-07-29
+
+    <braunr> making progress on x15 pmap module
+    <braunr> factoring code for mapping creation/removal on current/kernel and
+      remote processes
+    <braunr> also started "swap emulation" by reserving some physical memory to
+      act as swap backing store
+    <braunr> which will allow creating memory pressure very early in the
+      development process
+
+
+## IRC, freenode, #hurd, 2013-08-23
+
+    < nlightnfotis> braunr: something a little bit irrelevant: how many things
+      are missing from mach to be considered a solid base for the Hurd? Is it
+      only SMP and x86_64 support?
+    < braunr> define "solid base for the hurd"
+    < nlightnfotis> solid enough to not look for a replacement for it
+    < braunr> then i'd say, from my very personal point of view, that you want
+      x15
+    < nlightnfotis> I didn't understand this. Are you planning for x15 to be a
+      better mach?
+    < braunr> with a different interface, so not compatible
+    < braunr> and thus, not mach
+    < nlightnfotis> is the source code for it available? Can I read it
+      somewhere?
+    < braunr> the implied answer being: no, mach isn't a solid base for the
+      hurd considering your definition
+    < braunr> http://git.sceen.net/rbraun/x15.git/
+    < nlightnfotis> thanks. for that. So it's definite that mach won't stay for
+      long as the Hurd's base, right?
+    < braunr> it will, for long
+    < braunr> my opinion is that it needs to be replaced
+    < nlightnfotis> is it possible that it (slowly) gets rearchitected into
+      what's being considered a second generation microkernel, or is it
+      hopeless?
+    < braunr> it would require a new interface
+    < braunr> you can consider x15 to be a modern mach, with that new interface
+    < braunr> from a high level view, it's very similar (it's a hybrid, with
+      both scheduling and virtual memory management in the kernel)
+    < braunr> ipc change a lot
+
+
+## IRC, freenode, #hurd, 2013-09-23
+
+    <braunr> for those of us interested in x15 and scalability in general:
+      http://darnassus.sceen.net/~rbraun/radixvm_scalable_address_spaces_for_multithreaded_applications.pdf
+    <braunr> finally an implementation allowing memory mapping to occur
+      concurrently
+    <braunr> (which is another contention issue when using mach-like ipc, which
+      often do need to allocate/release virtual memory)
diff --git a/microkernel/mach/documentation.mdwn b/microkernel/mach/documentation.mdwn
index cc880ab6..61e3469b 100644
--- a/microkernel/mach/documentation.mdwn
+++ b/microkernel/mach/documentation.mdwn
@@ -1,5 +1,5 @@
 [[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008,
-2010 Free Software Foundation, Inc."]]
+2010, 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
@@ -47,3 +47,14 @@ License|/fdl]]."]]"""]]
   - [An IO System for Mach](http://shakthimaan.com/downloads/hurd/An%20IO%20System%20for%20Mach.pdf)
 
   - [A Programmers' Guide to Mach System Call](http://shakthimaan.com/downloads/hurd/A.Programmers.Guide.to.the.Mach.System.Calls.pdf)
+
+
+# IRC, freenode, #hurd, 2013-09-15
+
+    <teythoon> braunr: btw, are there multiple kernel threads in gnumach?
+    <teythoon> and is it safe to do a synchronous rpc call to a userspace
+      server?
+    <braunr> teythoon: there are yes, but few
+    <braunr> teythoon: the main (perhaps only) kernel thread is the page daemon
+    <braunr> and no, it's not safe to do synchronous calls to userspace
+    <braunr> except to the default pager
diff --git a/microkernel/mach/gnumach/hardware_compatibility_list.mdwn b/microkernel/mach/gnumach/hardware_compatibility_list.mdwn
index 587178e9..32e712c9 100644
--- a/microkernel/mach/gnumach/hardware_compatibility_list.mdwn
+++ b/microkernel/mach/gnumach/hardware_compatibility_list.mdwn
@@ -105,6 +105,11 @@ These boards are known to work. Gnumach/Hurd has been installed and run on these
 * VIA EPIA-M Mini-ITX motherboard with VIA Nehemiah C3 1Ghz processor. Onboard NIC (VIA Rhine) works good.
 * Compaq Deskpro ENS, Pentium3 (666 MHz upgraded to 1 GHz), Intel i815 chipset, chipset integrated NIC (detected twice, but works fine with eth0; trying to access eth1 confuses the driver and makes the system unusable), Matrox Mystique 220 (PCI) graphics card. Also works with rtl8029 (NE2000 PCI) NIC when onboard NIC disabled in BIOS setup.
 * Abit BX6 Rev. 2.0 with Celeron 400, after disabling "memory hole at 15MB" option in BIOS setup. (Otherwise, Mach detects only 15MiB of RAM, making Hurd run *extremely* slow and instable.) Should also work with PentiumII or Pentium3.
+* IRC, freenode, #hurd, 2013-08-26:
+
+        < stargater> have anyone gnu/hurd running on real hw ? 
+        < youpi> my latitude e6420 laptop, for instance
+
 
 # User Failure Reports
 
diff --git a/microkernel/mach/message/msgh_id.mdwn b/microkernel/mach/message/msgh_id.mdwn
index ea52904a..799ed5cc 100644
--- a/microkernel/mach/message/msgh_id.mdwn
+++ b/microkernel/mach/message/msgh_id.mdwn
@@ -13,6 +13,8 @@ License|/fdl]]."]]"""]]
 Every [[message]] has an ID field, which is defined in the [[RPC]] `*.defs`
 files.
 
+[[!toc]]
+
 
 # IRC, freenode, #hurd, 2012-07-12
 
@@ -281,3 +283,25 @@ files.
     <youpi> then submit to the list for review
     <braunr> hm ok
     <braunr> youpi: ok, next time, i'll commit such changes directly
+
+
+# Subsystems
+
+## IRC, freenode, #hurd, 2013-09-03
+
+    <teythoon> anything I need to be aware of if I want to add a new subsystem?
+    <teythoon> is there a convention for choosing the subsystem id?
+    <braunr> a subsystem takes 200 IDs
+    <braunr> grep other subsystems in mach and the hurd to avoid collisions of
+      course
+    <teythoon> yes
+    <teythoon> i know that ;)
+    <braunr> :)
+    <teythoon> i've noticed the _notify subsystems being x+500, should I follow
+      that?
+    <pinotree> 100 for rpc + 100 for their replies?
+    <braunr> teythoon: yes
+    <braunr> pinotree: yes
+    <teythoon> ok
+    <teythoon> we should really work on mig...
+    <braunr> ... :)
diff --git a/microkernel/mach/mig.mdwn b/microkernel/mach/mig.mdwn
index d6340574..f8046cb2 100644
--- a/microkernel/mach/mig.mdwn
+++ b/microkernel/mach/mig.mdwn
@@ -24,7 +24,8 @@ them to the client program.  Similar actions are provided in the skeletons that
 are linked to server programs.
 MIG allows very precise semantics to be specified about what the arguments are
 and how to be passed.
-It has its problems with [[structured_data]], however.
+It has its problems with
+[[structured_data|open_issues/mig_portable_rpc_declarations]], however.
 
 
   * [[Documentation]]
diff --git a/microkernel/mach/mig/documentation.mdwn b/microkernel/mach/mig/documentation.mdwn
index 7d4f1eca..e6bd1bb9 100644
--- a/microkernel/mach/mig/documentation.mdwn
+++ b/microkernel/mach/mig/documentation.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2002, 2003, 2005, 2007, 2008, 2009, 2010 Free
-Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2002, 2003, 2005, 2007, 2008, 2009, 2010, 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
@@ -82,3 +82,20 @@ pp. 67--77."
       * [[ServerCopy]]
 
   * MIG *in action*: [[hurd/io_path]].
+
+
+## IRC, freenode, #hurd, 2013-09-04
+
+[[!tag open_issue_documentation open_issue_mig]]
+
+    <teythoon> btw, I just realized that mig mashes two very different things
+      together, namely the serialization/parsing and the message
+      sending/receiving
+    <braunr> yes
+    <teythoon> I'd prefer it if that were separated
+    <braunr> me too
+    <braunr> that's why i want x15 to have a bare messaging interface .. :)
+    <teythoon> \o/
+    <braunr> simple (but optimized) scatter-gather
+    <braunr> it makes sense for mig since mach messages do include
+      serialization metadata such as types
diff --git a/microkernel/mach/mig/structured_data.mdwn b/microkernel/mach/mig/structured_data.mdwn
deleted file mode 100644
index 1c8abe08..00000000
--- a/microkernel/mach/mig/structured_data.mdwn
+++ /dev/null
@@ -1,119 +0,0 @@
-[[!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]]."]]"""]]
-
-[[!tag open_issue_mig]]
-
-# IRC, freenode, #hurd, 2013-06-25
-
-    <teythoon> is there a nice way to get structured data through mig that I
-      haven't found yet?
-    <teythoon> say an array of string triples
-    <braunr> no
-    <teythoon> :/
-    <braunr> but you shouldn't need that
-    <teythoon> my use case is getting info about fs translators from init to
-      procfs
-
-[[community/gsoc/project_ideas/mtab]].
-
-    <teythoon> should I go for an iterator like interface instead?
-    <braunr> depends
-    <braunr> how many do you need ?
-    <braunr> you could go for a variable sized array too
-    <braunr> have a look at what already exists
-    <teythoon> records, maybe 10-15, depends on many fs translators are running
-    <braunr> a variable sized array is ok if the size isn't too big (and when i
-      say too big, i mean hundreds of MiB)
-    <braunr> an iterator is ok too if there aren't too many items
-    <braunr> you may want to combine both (i think that's what proc does)
-    <braunr> be aware that the maximum size of a message is limited to 512 MiB
-    <teythoon> yeah I saw the array[] of stuff stuff, but array[] of string_t
-      does not work, I guess b/c string_t is also an array
-    <teythoon> how would I send an array of variable length strings?
-    <braunr> i'm not sure you can
-    <braunr> or maybe out of line
-    <teythoon> somehow I expected mig to serialize arbitrary data structures,
-      maybe it's to old for that?
-    <teythoon> yeah, I read about uot of line, but that seems overkill
-    <braunr> it is old yes
-    <braunr> and not very user friendly in the end
-    <braunr> let me check
-    <teythoon> we could stuff json into mig...
-    <braunr> see proc_getallpids for example
-    <braunr> we could get rid of low level serialization altogether :p
-    <teythoon> hah, exactly what  I was looking at
-    <braunr> (which is what i'll do in x15)
-    <braunr> type pidarray_t = array[] of pid_t;
-    <teythoon> but that is trivial b/c its array[] of pid_t
-    <braunr> and always have the server writing guide near you
-    <teythoon> yes
-    <braunr> well, make one big string and an array of lengths :p
-    <teythoon> thought about that and said to myself, there must be a better
-      way that I haven't found yet
-    <braunr> or one big string filled with real null-terminated c strings that
-      you keep parsing until you ate all input bytes
-    <braunr> i'm almost certain there isn't
-    <braunr> type string_t = c_string[1024]; /* XXX */
-    <teythoon> yes
-    <braunr> even that isn't really variable sized
-    <teythoon> you think anyone would object to me putting a json encoder in
-      /hurd/init? it is probably better than me at serializing stuff...
-    <braunr> try with mig anyway
-    <braunr> the less dependencies we have for core stuff, the simpler it is
-    <braunr> but i agree, mig is painful
-    <teythoon> would it be too hacky if I abused the argz functions? they do
-      exactly what I'd need
-
-
-## IRC, freenode, #hurd, 2013-06-26
-
-    <teythoon> there is https://code.google.com/p/protobuf-c/ and it has a rpc
-      mechanism and I believe one could plug arbitrary transports easily
-    <braunr> please don't think about it
-    <braunr> we really don't want to add another layer of serialization
-    <braunr> it's better to completely redesign mach ipc anyway
-    <braunr> and there is a project for that :p
-    <teythoon> ive seen x15
-    <teythoon> just food for thought
-    <braunr> i've studied google protocol buffers
-    <braunr> and fyi, no, it wouldn't be easy to plug arbitrary transports on
-      top of mach
-    <braunr> there is a lot of knowledge about mach ports in mig
-
-[[community/gsoc/project_ideas/mtab]].
-
-    <teythoon> but again I face the challenge of serializing a arbitrary sized
-      list of arbitrary sized strings
-    <braunr> yes
-    <teythoon> list of ports is easier ;) but I think its worthwile
-    <teythoon> so what about abusing argz* for this? you think it's too bad a
-      hack?
-    <braunr> no since it's in glibc
-    <teythoon> awesome :)
-    <braunr> but i don't remember the details well and i'm not sure the way you
-      use it is safe
-    <teythoon> yeah, I might have got the details wrong, I hadn't had the
-      chance to test it ;)
-
-    <braunr> about this dynamic size problem
-    <braunr> a "simple" varying size array should do
-    <braunr> you can easily put all your strings in there
-    <teythoon> seperated by 0?
-    <braunr> yes
-    <teythoon> that's exactly what the argz stuff does
-    <braunr> you'll get the size of the array anyway, and consume it until
-      there is no byte left
-    <braunr> good
-    <braunr> but be careful with this too
-    <braunr> since translators can be run by users, they somtimes can't be
-      trusted
-    <braunr> and even a translator running as root may behave badly
-    <braunr> so careful with parsing
-    <teythoon> noted