summaryrefslogtreecommitdiff
path: root/open_issues/robustness.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'open_issues/robustness.mdwn')
-rw-r--r--open_issues/robustness.mdwn50
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