IRC.

1 files changed, 49 insertions, 1 deletions

diff --git a/open_issues/robustness.mdwn b/open_issues/robustness.mdwn
index a6b0dbfb..4b0cdc9b 100644
--- a/open_issues/robustness.mdwn
+++ b/open_issues/robustness.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2011, 2013 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2013, 2014 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
@@ -12,6 +13,7 @@ License|/fdl]]."]]"""]]
 
 [[!toc]]
 
+
 # IRC, freenode, #hurd, 2011-11-18
 
     <nocturnal> I'm learning about GNU Hurd and was speculating with a friend
@@ -167,3 +169,49 @@ License|/fdl]]."]]"""]]
       http://darnassus.sceen.net/gitweb/teythoon/reincarnation.git/blame/HEAD:/reincarnation.defshttp://darnassus.sceen.net/gitweb/teythoon/reincarnation.git/blame/HEAD:/reincarnation.defs
     < teythoon> uh >,< sorry, pasted twice
     < braunr> oh ok
+
+
+## IRC, freenode, #hurd, 2014-02-01
+
+    <pere> btw, can hurd upgrade the kernel without reboot?
+    <teythoon> no
+    <teythoon> but since most functionality is not within the kernel, the more
+      interesting question is, what parts of the hurd can be replaced at
+      runtime
+    <pere> ok.  what is the answer to that question?
+    <teythoon> no hurd server can be restarted transparently, i.e. w/o its
+      clients noticing that
+    <teythoon> however, if a server is not in use, it can be easily restarted
+    <teythoon> transparently restarting servers would be nice
+    <teythoon> and i believe it is even possible on mach
+    <braunr> teythoon: how ?
+    <teythoon> one has to retain two things, client-related state and the port
+      right
+    <braunr> doesn't that require persistence ?
+    <teythoon> it does
+    <teythoon> but i see no reason why it should not be possible to implement
+      this on top of mach
+    <braunr> maybe
+    <teythoon> the most crucial thing is to preserve the receive port, and to
+      replace the server without race-conditions
+    <teythoon> receive rights can be transfered using the notification
+      mechanism
+
+    <antrik> braunr: restarting servers doesn't exactly require
+      persistance. you only need to pass the state from the old server to the
+      new one, rather than serialising it for on-disk storage. it's a slightly
+      easier requirement...
+    <antrik> (most notably, you don't need any magic to keep the capabilities
+      around -- just pass them over using normal IPC)
+    <teythoon> antrik: i agree, but then again, once this is in place, adding
+      persistence is only a little step
+    <antrik> teythoon: depends. if it's implemented with persistence in mind
+      from the beginning, it might be a fairly small step indeed; but
+      otherwise, it could be two entirely different things
+    <antrik> this also depends on the kind of persistence you want
+    <antrik> I must say that for the kind of persistence *I* would like, it is
+      indeed quite related
+    <teythoon> well, please elaborate a little :)
+    <teythoon> what do you have in mind ?
+    <antrik> busy right now... remind me some other time if I forget :-)
+    <teythoon> sure